Re: RFC 3280bis and URI schemes without hostname

["David A. Cooper" <[e-mail]>]

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:

   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.

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

Stephen Farrell wrote:
> Sam Hartman wrote:
>   
>> 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.
>>     
>
> Good catch.
>   
>> 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 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.





Received: from proxy.fiberhost.ru (101.92.95.77.fiberhost.ru [77.95.92.101] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAUMubgP098450 for <[e-mail]>; Fri, 30 Nov 2007 15:56:38 -0700 (MST) (envelope-from [e-mail])
Date: Fri, 30 Nov 2007 15:56:37 -0700 (MST)
Received: from $FROM_NAME $FROM_NAME (10.12.15.18) by proxy.fiberhost.ru (PowerMTA(TM) v3.2r4) id hfp79o96d41j79 for <[e-mail]>; Sat, 1 Dec 2007 01:56:39 +0300
Message-Id: <[e-mail]>
To: <[e-mail]>
Subject: November 72% OFF
From: VIAGRA ® Official Site <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 071130-0, 30.11.2007), Outbound message
X-Antivirus-Status: Clean

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUMakhP097069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 15:36:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAUMakG1097068; Fri, 30 Nov 2007 15:36:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUMaikG097061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 30 Nov 2007 15:36:46 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (emailha2.nist.gov [129.6.16.198]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id lAUMacXH031987 for <[e-mail]>; Fri, 30 Nov 2007 17:36:39 -0500
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id lAUMbBdg027813 for <[e-mail]>; Fri, 30 Nov 2007 17:37:12 -0500
Message-ID: <[e-mail]>
Date: Fri, 30 Nov 2007 17:36:17 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20070914)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: RFC 3280bis and URI schemes without hostname
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information: 
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:

   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.

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

Stephen Farrell wrote:
> Sam Hartman wrote:
>   
>> 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.
>>     
>
> Good catch.
>   
>> 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 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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUKhYP3089746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 13:43:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAUKhYB6089745; Fri, 30 Nov 2007 13:43:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUKhP3T089731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 13:43:26 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624080fc376260282a0@[10.20.30.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <p0624080ac3760b62452f@[10.20.30.108]> <[e-mail]>
Date: Fri, 30 Nov 2007 12:43:24 -0800
To: Sam Hartman <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: RFC 3280bis and URI schemes without hostname
Cc: Stephen Farrell <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:15 PM -0500 11/30/07, Sam Hartman wrote:
>  >>>>> "Paul" == Paul Hoffman <[e-mail]> 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:[e-mail] 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/[e-mail].  Note that as far as 3280 and the
>URI specs are concerned, the first form (xmpp:[e-mail])
>has no host name.

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

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUKFBNE087722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 13:15:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAUKFBcP087721; Fri, 30 Nov 2007 13:15:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (dhcp-18-188-10-61.dyn.mit.edu [18.188.10.61]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUKF963087706 for <[e-mail]>; Fri, 30 Nov 2007 13:15:10 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EF49C4815; Fri, 30 Nov 2007 15:15:08 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: Paul Hoffman <[e-mail]>
Cc: Stephen Farrell <[e-mail]>, [e-mail]
Subject: Re: RFC 3280bis and URI schemes without hostname
References: <[e-mail]> <[e-mail]> <p0624080ac3760b62452f@[10.20.30.108]>
Date: Fri, 30 Nov 2007 15:15:08 -0500
In-Reply-To: <p0624080ac3760b62452f@[10.20.30.108]> (Paul Hoffman's message of "Fri, 30 Nov 2007 10:49:07 -0800")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Paul" == Paul Hoffman <[e-mail]> 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:[e-mail] 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/[e-mail].  Note that as far as 3280 and the
URI specs are concerned, the first form (xmpp:[e-mail])
has no host name.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUInHJ1080044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 11:49:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAUInH0A080043; Fri, 30 Nov 2007 11:49:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUIn9Bg080021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 11:49:10 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624080ac3760b62452f@[10.20.30.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 30 Nov 2007 10:49:07 -0800
To: Stephen Farrell <[e-mail]>, Sam Hartman <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: RFC 3280bis and URI schemes without hostname
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUGYDEp069379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 09:34:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAUGYDnB069378; Fri, 30 Nov 2007 09:34:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUGYCUX069372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 30 Nov 2007 09:34:12 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id C56732ACCA; Fri, 30 Nov 2007 16:34:11 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iy8od-0007Y7-If; Fri, 30 Nov 2007 11:34:11 -0500
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
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: [e-mail]
Cc: <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 30 Nov 2007 11:34:11 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
[e-mail] mailing lists by 2007-12-14. Exceptionally, 
comments may be sent to [e-mail] 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUBCEWF029162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 04:12:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAUBCEM2029161; Fri, 30 Nov 2007 04:12:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUBCDEm029154 for <[e-mail]>; Fri, 30 Nov 2007 04:12:13 -0700 (MST) (envelope-from [e-mail])
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 5A30768033; Fri, 30 Nov 2007 11:12:12 +0000 (GMT)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A034EF4EDE5; Fri, 30 Nov 2007 11:12:12 +0000
Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 3F6CC68033; Fri, 30 Nov 2007 11:12:12 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Fri, 30 Nov 2007 11:12:14 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Sam Hartman <[e-mail]>
Cc: [e-mail]
Subject: Re: RFC 3280bis and URI schemes without hostname
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A134EF4EDE5
X-AntiVirus-Status: Host: imx2.tcd.ie
X-AntiVirus-Status: Action Taken: 
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.57.6 VDF=9.115.14)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman wrote:
> 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.

Good catch.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUB7dRK028455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 04:07:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAUB7dqL028453; Fri, 30 Nov 2007 04:07:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from a.mx.secunet.com (a.mx.secunet.com [213.68.205.161]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAUB7aKv028423 for <[e-mail]>; Fri, 30 Nov 2007 04:07:38 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (alg3 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 82A0620C09C; Fri, 30 Nov 2007 12:07:34 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 3894620C078; Fri, 30 Nov 2007 12:07:34 +0100 (CET)
Received: from [10.208.1.212] ([10.208.1.212]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Nov 2007 12:07:34 +0100
Message-ID: <[e-mail]>
Date: Fri, 30 Nov 2007 12:07:33 +0100
From: Johannes Merkle <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Rescorla <[e-mail]>
CC: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Nov 2007 11:07:34.0185 (UTC) FILETIME=[35665990:01C83341]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAU4BKWK002314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2007 21:11:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAU4BJCk002313; Thu, 29 Nov 2007 21:11:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAU4BHuo002306 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 29 Nov 2007 21:11:18 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Fri, 30 Nov 2007 04:11:16 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 30 Nov 2007 04:11:16 +0000
From: Stefan Santesson <[e-mail]>
To: Eric Rescorla <[e-mail]>
CC: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Fri, 30 Nov 2007 04:11:07 +0000
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Thread-Topic: [TLS] DSA/SHA-1, and OIDs
Thread-Index: AcgwPgz3EhyIY9lRRxCldMBYJtAaWgCxqybQ
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAU4BJun002308
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> Sent: den 26 november 2007 16:02
> To: Stefan Santesson
> Cc: Eric Rescorla; [e-mail]; [e-mail]
> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lATLAptY077676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2007 14:10:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lATLApn6077675; Thu, 29 Nov 2007 14:10:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lATLAoS1077668 for <[e-mail]>; Thu, 29 Nov 2007 14:10:50 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 97DE04815; Thu, 29 Nov 2007 16:10:45 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: [e-mail]
Subject: RFC 3280bis and URI schemes without hostname
Date: Thu, 29 Nov 2007 14:39:39 -0500
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from port-87-193-30-127.static.qsc.de (port-87-193-30-127.static.qsc.de [87.193.30.127] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lASKeLmc070585 for <[e-mail]>; Wed, 28 Nov 2007 13:40:24 -0700 (MST) (envelope-from [e-mail])
Received: from jens ([119.117.18.66] helo=jens) by port-87-193-30-127.static.qsc.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1oZqJW-000DPM-MG for [e-mail]; Wed, 28 Nov 2007 21:40:54 +0100
Message-ID: <000401c831fe$e6c67880$7f1ec157@jens>
From: "Magnus Heinritz" <[e-mail]>
To: <[e-mail]>
Subject: nisirap
Date: Wed, 28 Nov 2007 21:40:24 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C83207.488AE080"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lARDoNX9043885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2007 06:50:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lARDoNdR043884; Tue, 27 Nov 2007 06:50:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lARDoHmp043871 for <[e-mail]>; Tue, 27 Nov 2007 06:50:20 -0700 (MST) (envelope-from [e-mail])
Received: from morten (0x503ff099.albnxx10.adsl-dhcp.tele.dk [80.63.240.153]) by pfepb.post.tele.dk (Postfix) with ESMTP id BE8CBA50041; Tue, 27 Nov 2007 14:50:12 +0100 (CET)
From: "Erik Andersen" <[e-mail]>
To: "Directory list" <[e-mail]>, "PKIX" <[e-mail]>
Subject: Removal of Upper Bounds (X.509, X.520, etc.)
Date: Tue, 27 Nov 2007 14:51:32 +0100
Message-ID: <000801c830fc$9f9a71d0$0100a8c0@morten>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C83105.015ED9D0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6822
Importance: Normal
Thread-Index: Acgw/J4HFQj70N4sTtSXYGqdRiuseA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [phone]

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

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: [phone]</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:[e-mail]"><font size=3D2 face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial'>[e-mail]</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--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQKKSCt076231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 13:20:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAQKKSim076230; Mon, 26 Nov 2007 13:20:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQKKQN6076224 for <[e-mail]>; Mon, 26 Nov 2007 13:20:27 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id lAQKKQbw010288 for <[e-mail]>; Mon, 26 Nov 2007 15:20:26 -0500 (EST)
X-AuditID: 90333308-00000f3c000007e0-41-474b2a8a5bc0
Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 15:20:26 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 15:20:25 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Date: Mon, 26 Nov 2007 15:20:24 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [TLS] DSA/SHA-1, and OIDs
Thread-Index: AcgwW+k3qeWXBTuqTTS918LjTfjKYgAA6JYg
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 26 Nov 2007 20:20:25.0946 (UTC) FILETIME=[C7A863A0:01C83069]
X-Brightmail-Tracker: AAAAAA==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAQKKRN6076225
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Original Message-----
> From: Eric Rescorla [mailto:[e-mail]] 
> 
> 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"?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQIf0ah067263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 11:41:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAQIf02f067260; Mon, 26 Nov 2007 11:41:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (news.meritdirect.com [209.213.211.195] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQIf0Gl067250 for <[e-mail]>; Mon, 26 Nov 2007 11:41:00 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 9327033C21; Mon, 26 Nov 2007 10:35:59 -0800 (PST)
Date: Mon, 26 Nov 2007 10:35:58 -0800
From: Eric Rescorla <[e-mail]>
To: "Kemp, David P." <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQIb7Gt066969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 11:37:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAQIb7pP066968; Mon, 26 Nov 2007 11:37:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQIb6XJ066956 for <[e-mail]>; Mon, 26 Nov 2007 11:37:06 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id lAQIb1r7029220 for <[e-mail]>; Mon, 26 Nov 2007 13:37:01 -0500 (EST)
X-AuditID: 90333308-00000f2c000007e0-4d-474b124d7bb2
Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 13:37:01 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 13:37:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Date: Mon, 26 Nov 2007 13:36:45 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [TLS] DSA/SHA-1, and OIDs
Thread-Index: Acgq2OmrK/CPwedORjuYCnyihrUTXgAQSaBAAF1tZzAA7y+UIA==
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 26 Nov 2007 18:37:00.0992 (UTC) FILETIME=[55378C00:01C8305B]
X-Brightmail-Tracker: AAAAAA==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAQIb7XJ066962
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Original Message-----
> From: Manger, James H [mailto:[e-mail]]
>
> 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.)





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQF6tvO046299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 08:06:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAQF6t35046298; Mon, 26 Nov 2007 08:06:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQF6rrm046291 for <[e-mail]>; Mon, 26 Nov 2007 08:06:53 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5DA3133C21; Mon, 26 Nov 2007 07:01:53 -0800 (PST)
Date: Mon, 26 Nov 2007 07:01:53 -0800
From: Eric Rescorla <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQCRqOh031200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 05:27:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAQCRqot031199; Mon, 26 Nov 2007 05:27:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQCRomx031193 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 26 Nov 2007 05:27:51 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 26 Nov 2007 12:27:49 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([2002:4135:d55c::4135:d55c]) with mapi; Mon, 26 Nov 2007 12:27:49 +0000
From: Stefan Santesson <[e-mail]>
To: Eric Rescorla <[e-mail]>
CC: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Mon, 26 Nov 2007 12:27:23 +0000
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Thread-Topic: [TLS] DSA/SHA-1, and OIDs
Thread-Index: AcgsT7BNG6z5NU/ETZqOP4ktS7jcHgD1jWzQ
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAQCRpmw031194
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQ9VkkX017935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 02:31:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAQ9Vk2a017934; Mon, 26 Nov 2007 02:31:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1relay.itmaster.local (host48-104-static.43-193-b.business.telecomitalia.it [193.43.104.48] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAQ9Vh77017896; Mon, 26 Nov 2007 02:31:44 -0700 (MST) (envelope-from [e-mail])
Received: from POSTA02.itmaster.local ([193.43.104.10]) by mail1relay.itmaster.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 10:31:24 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: R: R: TimeStampedData draft updated - please comment
Date: Mon, 26 Nov 2007 10:31:23 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: TimeStampedData draft updated - please comment
Thread-Index: AcguJXpgV1zMMyMPS7OomtFFcupLmgB5qdCA
References: <[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Santoni Adriano" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 26 Nov 2007 09:31:24.0258 (UTC) FILETIME=[1C9A5C20:01C8300F]
X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.0.1023-15568.003
X-TM-AS-Result: No--22.151800-0.000000-2
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAQ9Vj78017924
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]] Per conto di Russ Housley
Inviato: venerdì 23 novembre 2007 20.41
A: Santoni Adriano
Cc: [e-mail]; [e-mail]
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: [e-mail]
>[mailto:[e-mail]] Per conto di Russ Housley
>Inviato: martedì 20 novembre 2007 22.53
>A: [e-mail]; [e-mail]
>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: [e-mail]
> > [mailto:[e-mail]] Per conto di Santoni Adriano
> > >Inviato: lunedì 3 settembre 2007 10.42
> > >A: [e-mail]
> > >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:[e-mail]]
> > >Inviato: venerdì 31 agosto 2007 17.48
> > >A: Santoni Adriano
> > >Cc: [e-mail]
> > >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: [e-mail]
> > >> [mailto:[e-mail]]
> > >> Per conto di Julien Stern
> > >> Inviato: venerdì 31 agosto 2007 13.43
> > >> A: [e-mail]
> > >> 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:[e-mail]]
> > >>>> Inviato: giovedì 30 agosto 2007 23.05
> > >>>> A: Young H Etheridge
> > >>>> Cc: Santoni Adriano; [e-mail]
> > >>>> 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




Received: from aleksandr ([79.120.96.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAOMwgKj062951 for <[e-mail]>; Sat, 24 Nov 2007 15:58:44 -0700 (MST) (envelope-from [e-mail])
Received: from [79.120.96.139] by bmx.bluffcountryoutfitters.com.redcondor.net; , 25 Nov 2007 01:58:32 +0300
Date: 	, 25 Nov 2007 01:58:32 +0300
From: "Janine Stanley" <[e-mail]>
X-Mailer: The Bat! (v3.81.14 Beta) Professional
Reply-To: [e-mail]
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Check our values below to inquire how much you can save.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------8DABB4F219576E0"

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

R0lGODlhjgHuAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/
/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBm
AABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/
MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNm
ZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/
mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZm
zGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb/
/5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZ
AJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwA
M8wAZswAmcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZ
ZsyZmcyZzMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8A
mf8AzP8A//8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+Z
zP+Z///MAP/MM//MZv/Mmf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAACOAe4A
AAj/AP8J/Odv2sCDCBMqFJhNoTaE/hYqbChRoL97/wxWPKhxo8ePIEOKHEnSYsSSA0/6w3cSJcSP
LV26LCizYsyaMFF2RPgQ50aDO30KHSrTH7WVN10GHWmU6MGkCqE6nVqyJ1WCC/ttpOhQqFSOVyVO
67cUp9Ww/7SWNIgPZUyMRL9u9KeNLt2zXf/hRQv2416Q0+Rijeryr9jDfP/BTbzxVeJ70lC2Fbzw
ZtuBZZni5CqRc+awGu1uNCwR32eElxEuHkm6skTKQlfjTM26omybEm8Dhv0xdGvGv/sODD7UIG+B
v/0p73dcIO2M0GsP740Y5PHmpxM+F7l3GsbsTyt6/3e5nWRowGqnEhf/ujjjvAljsuQMcu/6+IFh
NqQmsjl92zKdpZFuEv0W2Uw1RQQbWXw15xN4CEGYEkj/wRffP6ZFx91CpGVGYELTNISRg4LFBOGH
5gkkIXJ8TVNeSCFSl9hJK4LEX0KuXKXgSwqtaJiDGxLmEmdA5jRQhQJVs42S1CzpJJNPOtmkktUk
pBWKQoa1I10oaYPkSDFGSFJ61qWonkVRWXUeTlhOtdOXZU5lYkLbGGLIFneKwYUhe/apJ5+AcvHn
nmLYCUs1ZL7n3E+L1tRWjQtNIylHcPKI4UeJzqXhUNoQlw1Neinq5pE4FSmmpQoZIsYNONzABauu
Tv/T6quzwkqrq7beEEuVG71YKm79faaclhCuqamoPYK61ZwewQnpXL7yJI1GlX7UpkdLfQXLFlzE
0CoO3t4wTQw3kGvuDayemy66NxgCUrQiBdWWbs9mlGFfw/oV2DT3eXQtQyGZGhI12X0n2D37YlRp
clMhLKdHdX2Z30GZCgTLqq9qMw2tG+Pw6se4gvyxx+2GBC/EezFHW11OCYxslzP6q+CNHzmbUTZh
JkTzy0Lti9DOwgGcECxctKpNuN1Os66rSJO7NLg4bAFjgP8gKanPBwpVsVtX1TthSUd5x8w0zNwz
totoX/rRyQdV2lJEXvabUENVbvOP3TyPBuzXB8H/YkjI6d76cQwi5wqyIXjLKBODqA0mkDQutwz0
biDdw7aFElVT0D3LvLNMPZ1/Hrrnni9jeujTXpQUUPEyOh1J2zQp+zbTxG577bPnntjlWyFE9Kvo
thr8uTEoXe7x4YJ7vNSt45S1QPS+d21B/e70b8uSdq7MMsrUs/3pp38PfunbE7MMMcqYX7ZGBmFk
2sklylQlrwed9VDiAtldZSzb8E9V5OEZiN8A96ot4IpgSjNg4bp1uLxVji8sMU6vjlWdBnlHdJ4D
nT1Ct0HQ1eMdoHuHMjI4utORTnulWwbC8GG54kzOI7K72z/oVzdt8CdxOPxHk+42pVjAYlexkxvF
/7xWEcZVgwu0cprwxPWK4aGrW8Nr1RbIxTwZaqkkDtLN5qRhtg1ukBnLsIc0wDg2ZkhDjAibxgtR
1aORbC030yBhCkUYQvCNTnzmA58yIMO9PpbvfMsAhTK4SMQL3esj9KsI/hRSNxkmTkmwsN0axfJG
pZCJGn+rFciUNrhOAg5cr0LcFRVyPcpoRC0suQdkvFhCOe4xdP6wIxhXOSLXAChOHknlBuUoOtPV
UYQiDB8wR2i6ERpzGd6Jo+mIQT7ITAMUyygGS5AVO4Xwh2b8qdLOljSQbdhOm978ZjWmEYvZgbM9
TlnKNv4ARVg90VzKIx7y5lnF/wmEZgPyCc6gJ/82MtrxhCm0ozL60blimO6E4GPG2Bz0vCLCEB/a
WwY1vHdQE5qwe8fcHhiXQZY+EkMafwwpIM1HDHuQFJCgYIaouMmTkXhThtW4h91mOkOY+gOST/KI
y3YilWqogluAUyABh1o4d+kITSoKYOPixMIwMqODooMqQEPnwWXAox8BteMGTQcP0zEjXx5JlFRO
4w97eLAe9vBHVdcaRqq2sq1cZY4yQUq+uhYzfH08nUoTE8P86ZAiBsnhQ6oU2GpqMzpSil01InnN
bfzwULBw3VqspE6gKs+dTCsXFAnntCmWa4pRq2nV/DpJG3FkKbIxjaSwhDNWem6XbX3t6UAnUED/
LsMoKM2tQXcbyGWEYlpcO9VCOKdB0cXyoNtL7vgiGlEw5hGQfzzpSaMLXdsGspBrwx/etJG4srTF
bgZp5Pxo99L53dRJ/INkLNYbC4XQFEEIicynDuJTfm3McIQjKtOKirdqBQl6uRkI2y6CD2kUl5UI
DkxbYRtQ87EEfAbVYzRPZ77tpZRA8euNNN5hVg2+I5Z1/CAv7cq9d2yYmcUsHedSvEwK97EY5HMx
KAAoEcb+LBuHJew0mDRDfFxTh7aLLHcJljt/RPLIPkwyIxphCEYwYpE4WYqkGjpDPpFLVvJElzy9
5TR6msa//cFMhHZ2vS6Gzo4WPd20vGM+aIbC/8XU6G2bAflmaNo5kMUARZ7zPLaB8IdlBykPlszs
Pahu9cyfwyNe/7gMaUh3pMjEx6MnLefcEoMYoLiK/6xIkK/gA4f+0N/d+pfYmFapLkrin6pvUQ32
MiIWjWgEI6QXFCMDlQv3LZw/9Asygl2GPjmMlIMqWRF72OOpYayHsu3B4XecELZiRLMwpYFXaBr0
zS1+s7Z7q+2yQUcqw+YwWpUtOg+CEIPl7ty5f9k5A4cOjMP03EWAicJ6V/R8pQNFKLCrkEPZ7Yai
xdBNRftNx1YjdwaH7GJjIY1YcPexC//hqxsRC0NUnMmy1mFN50eVSQ2ET+nCwTQ8m9kYUMNcnv89
l6SouCkZAnw0K4pMaeNzOoSxlbaItiO1eWtQNy/DuXi2cyigedI76/voQ4dcQbZWI6gWN4V1PGiF
IU3pqVN3usiEdM9dvMeiB5IZvPvIphcZ7FFznEqkVnX/1nsL9jp8vWuXeCxe/WqL1x3WGcdigriV
X1x70u9E3Vh+RWnL3pgSqTBBtj0Cw+E7kgWhxETo6bJn0O1R23TFGHrmi3GKrfrczXn2bSDBupDL
rbLZrkW3B4nJvRBG/sysj+gI80hb1k+XxHtMbuYxTZRIcvyenP63JIGs8Mf6kBrGJ6fFl1/x5jN/
yYaQdSPEwAgxNGIajUjku3BiiKPNE8vfR57/8vh1rnq2USgEy1JCEFbR1navcyGSNqRbLCmj5zkU
zNizHQz6DlCAghj1QHTLoAlDF0hDN3T6VhG8Mw1t5XqSF0zMFUzMNHXQdHXcc2kjVTqPJlKPxoCY
pmd2AAphJx5QdhAlmF5pdwu+FwuBsV6vBmvktF4UF2sTJ2t4t2TQh3H40Ah1IUQ6FS3bsmsLREC5
1ncxoDFHY1TolBB1cRS4pH4WwTmL50XZ8A744EXUgGBnVmewpQ2cA02cQ1LEYFDURoDgo2+fU2d4
Ng2ZV4BvJmjHgVVmNYdh1Hhs5UtuNVVzdGa0p0IjdG7vgD4A6DnKJT6gUDoMGE1HR2O4E0RJ/1JT
TeJNU5JwEZdkP/QK1ICD0scI91B3THZxS2Z90SeK01d910cXsgZl14MSIOd9MQBaJZdy84RyLEdB
oLF+YZRW5eYit5WI7xBhQRd6ZqRCDOhm+/Zm93BnzDB0Aah/EXZ0xSANmncKBxgKt3EtPRFL9hAN
dFhVJFRi4qNczzV1FVYQeWVi91CI53NpdCSA4+hRmFYMmuB/+BdlNbVd9AVTM5R2jtV2SsaCOjQN
dDd3c4cPAxl9OZiQ07eQYoAPpFiCIzgS1aAnuAJKuaZfmvWKGkl4e9MPVKZUOnUQZPZUxrZgHPVg
AAWM1mY6G3R5DBgKedYP1rhbmgdNplNnQ/9nDyv5kgUojdBULy1xD2bFD2iViyH2OaXjgG9FYvAX
SyZWVYFEiINYYmn2XLuVZ5g2dKsYKZGVJEHUWE1ifGKZZHbXCK5wfdNgCAKJcdYnBtNgfQLZlhgX
fXRZfWgAl2KQl08GhU5hZRmJLuPCLlk2i8uzN0KzhGH1GsyAVmJUD2cURspUW9DIW2EUDSgVCpoQ
Tf5gB6fzZmZogPpmB9h2dM8EmtJwdPfAH7yjJmJkbKzEbuDoRx7FddV1UtJgGsVwTBUYld0jgAJY
jOcTeno2j/43YBLRD43kV9zVSKv2Qy7oav7wauR0fXSXDZqoidgXa9a3XrDAlt45itKnfVj/wRtH
QXobMZELdJGFM0UFhCtTpIS/8oQQMRb20A/GhlbSQFC/REyZJ3phVAx5Zmwm9g6euUGc4w+hUDqh
kJNbB5Oa0FWZJ5MFqGe/pW97hUXGZp/2yWxayG6kowwj5KElRJUdZUKH+H4V9UE4xz3HBT7EcA/a
VgzE4DgVRF9d6XI1VTuwgITkZHxOBgsCqQ2MYJDSJw1zmZYMuZCjmJegmKRN1pZ5OX2LxBs54y99
8zewmDQaSZjmslmFKRT38RnSkA32sErGNi18eDpIB00T1XPIiHnIFApHQQ33J3SiaTpHZ4B4WpMH
qG8VmlZq0x9nxEUlaWizpQzFEGeJNkxU/zdhRNcP5kNt0oU+wFRhdPRHP5lbdgYZSUeePcJS9yhD
2pBkzzmQ0ulwTIYP0Yd9dDl32QCXBJmDckmKszp9aWB9r8ZGlQFmSrUNSNR3scJAQcVZmrVfMQCf
RTE1w8UPZOqaYtQPyIZcBDqAyNRBEOVmAmo6Lwma1LqnCWp03RpNmgeTboYPYOgW8MAP90mUUnhH
waRW55aOHvSOKTZCiZiOwtQ5PYhm9cCA4pOIwrln3sE7SQEL1IB2B8tYldidrUqX1+ed2IerDFko
klJxaACeYjAGohil1QelefmxeRcSY/qR2OJnhgBPW8alhIku9cRvpZFMvmI2HqkNZwpGX//kopgJ
TRDVR6FpUFvFhnoGjXeKZ/uniHkGCp+5phN6jLelE65JqMQVRt/TVcRADcN0D5Z6V7tJjv3wf4VY
qbMZUlibPoGED2AUtH0KTZrRTUtyEszZPyoIawU5kDQYndIXay4CnqGoMbEglznoA7GGcdrJkBqb
Da8QN7waZRGxDbfmnu75ijcgVFNkQOzJNEpIbDUxMcVGFgjTmoW6YJlnk5Kigb61oGaVdRLmpxCI
mWrKrWpIoaK3sy2EofZZVveAVo0nW6ZDF56TjuSzVduzbih0D994iM62TBTFTMTUrxAYbTeJaXpa
E9VkELPjo7H6sKKoDbPKCKOoKqbxsMz/4JYCaYoYy7HS15YaG6UfqzHnVz9gqkMna7iz6FkwgDxT
FAPyVL/M47KZa2wIs0qxlW0HuGBzFprqZn9CR3R5dpqj6X/FsH8GRYDDWZPmClwoAbWD6nShU7X+
oFzUFlL10IfweKKm4Q+g4LsWlpvBWT7es2IfZVBtJo/+h2lbiRDV0EjhBbduZ6qqOpd225Z9a4PR
dw8Pq5ajanfXK7GMcKsMycRiwMSxsDqYE1z/oAragCv4O7nU0C34i783AAP3C8b4K8aIQ2wCcxxC
aZ/aUDafe1Bb12i9ZD44Ccf5Jno+B6dgpAnPaICqpErAiYDSZEa6yiKqYWy2e0a4y2yx/2QXEbVh
d9VLycWoFehBgXEPHQw6MgqVo0O8yuB5vgW9+qYJ73CYImFYAaleP9SwCxmXC0kNSUp9osgIPqCx
b1mKDgu4S7q9H6u+bsm9FoFNZbEepRUTdrIFxrwFMODFJ9fFX9zFyTzGzayWtri2iYdG0/CaOYeG
Kwau/gcKnqy0nDmGSMcMoLB/R+d/oPlMfVqA3qY4KZHBj/l4TemvpIt1/tpbh9hmwXuIcYS1yqsM
u6lokYrPAZuni/EsaLdqseCPE0eQdRuKgasNm7iQmigGnchkTByKaQC4g7vEbenETryDt4Acb8Mh
8bkQN6wnybzFwDo4yfzShUAdmiufG/+hSvVZpq4plDjXf2/mmmh2Z/KnhgKMtrCrhkZNEL5lUOkh
F2VxDxp603MoVyuGlCI6b2kKV700DfUQhsfbPSBUOgN6V1NdwHkGDyvRNiJRvYvlWASJkEkasaUo
inPHloVCuMo3fRp7cR/btxo7fWIwy7PML7A8BthHM/OVEZEzVh5RDQZEi9/CLsgMAzBgJ+L5FAWh
LAEzEpYMGZz9VGcUrUenULRlf3faf45qgEmLz+usbz0nnHwaESqUGouRFBWSoWdUn+5mD/CwzVAp
tuTYWyh6oucDoukIorJJDNPwR0AXqTUZj5qgDO2D1iHxUpMocdLXKT04ff4wimmwxID/W4N6m6R0
1wgc3cRyyd1P7MpPnLEu0l4gAkBQkRlnUQ0nWzRigAOrYjQXqQqZHSDZYRBlWlY4bVbSAA/Hxm0/
58lqOI8J2mIWJq7f2lsNGnpGvaB2XLqhoB0dcRMzDT1pLJT3WaYhxEzkxm4o7FEgWqmXyj2qtNPL
1A/KZTofDEjAmacHchP3gWSQlWQS65YbG7Edu778Eoq8vN5OxmR/fat52ddioL1Fvst/DZCHhXgJ
4r7sYTGwwC638tg4gIkbc6OIKRPgERFms9m3LVXinODLNA1FF3qYGnShEM4ArXnKYK59Wqd1mrag
sNURQiQ0YhE74ZFP60XNoIGYRm+1/zmbxBAKlsrCIwRNzLBHATibHjibZxuMQneht+Ffaqdq1xtr
aunWYkANYlBxTny+rzzXFS3eIB2xGsvksrbRFEdjIdEa2pBqjYBE+L3r993rvO4D7s0XneIP2dAp
CMEVGMFFqnQRZUqSW4Vtp/s9yV3PXyfjF27Up4MPbshtFl7hYfQimDtN/3DTT+1FJf5WtfehMfY9
FPV6GWTJxkRiWIftNukTQZbEDFnLpPiWRP7EGKvXTCrqr4zXeLneRU7eTtZelhyoXnEhC0E7fbvR
tVIr9y04r4DfvFKCVdFGhhEm3lGmn31sUGWAxVCS45jceJbmbfZMR6vHQQuaJrza1f9YkwFqDzQq
ZiEhlCBekt44PqTrm4EEvZG8PXEkjhDoD++YUYEE0PEYysSgUhGpM0sSq3NNimdpCGMA0RKrKkqc
xOo78LOqsdpLuOu9kOulILQOkmq/dus9Bj6ADxrL6zfQ63PP64K9aSQxLGC1Oux7nJWcxs4KD8UV
eiXpYnC6db5ZmuTaunOGkwhs4d5s81duLU+t83a4TM7W29KK+YmGXFvdekmPVy12+PiMZ00rXCJh
iWS5kIB7lnmJy0q+fH4t+21pioXysapyl0v+sUr+lryP+3oZ7C9zEq5sCBt9/D6w0dPgAxXPKvgN
K/lNMhpjCDeKTZMlHCHyGd4xqO3/ilCaYD6wpamujaeh55OrDZpIK/N5GtqRAUCS0poZjNXk43qJ
7oF5NtrBRPSKnuiPlplBi84AoQnUMn//DB6cdlDhQoYGY22rFqtRLEYSGxkaI+ZiI0ZjKjZqpJFR
yDRiKMbSmDIkx5WGVopcOe3lzJFixjTyl7DhTp49e0YEKSbNmKFjiKZJ88NfSRximj4VM83p1KbZ
/FHb5lPrQW1bd967Z6+fvbD2zC57B6rYMrP2li1T9u7t3GUDicldFqruXL16B4YqBvjtwLd9l0nL
u6xYvXteFRZkCPneWMpn7dWrxzbuO7nv8HVei3bau7vv6t1Vljnzsntw8c7tN5ru/9u1a4ntHcgM
ssJsjhlWgxUr+MiaGcWIgVWT5XGYx126VCmGUcrjIaeHrN7sunQxhphjj0rN9/ifwhv5SINefXqb
6dNT8+HjBheoN6bh4HLDaU4cTcVUq4anrhRKSKeFDByvLGnMumfBZZgBJRRQ7Fkwm738qqsYVySc
ayC1POQQxAg/DFHCUE5EbKBp8NnNsRYX8scsaeo56y3V0EKtnrju8UeZudYChZjUBtNmGn/sWmaa
ZW7zcMlipulHSGKm+fBJUEhcpiEEyXsoFoqW28gmkwyJRZuXSvpSJeJIWjO6maBrhJqN2swoFvHI
w3MhiZBCj6g+hwKUKEFLosqp+/8K1Q8qMfwJkKGuXiywpxd9Kmussi4b7K1+ltHmrdv0AvKwt9y6
cK9QMUS1GLUwLKYYacaa1Ct8erqMHxqZccutzPCSRq5dCcJnycyErIcztI71R5se34nLR0/nUia2
w1qt60hiBpLmnxd748kfFnsSLlw4U5quOjKn0SalksAzF7yW1pWpO6G+EwOfeatjTritBsyzITl/
cA9gH8ZYT6iBfRAD4YMTFuMGHF5pGAf9HG7K4flu0AaWyAy6EyF+tfTNH7bMwpWtwa5si5hO92JS
1WmYwc3ECKeRUFVVZS6RxBFx7YfA8WbdaUEZc10mM1LvmjE1H328TRliUIMr6tv/jFRy6aiRxJpK
m6chRpNQmAHZoFi3qmab4CZacySQMPqII3+UE+mfWZ9jqc1GZHIlG7rXlLO5kOzsN/B/tmkEKcMF
NSpQQv80HNBpxqAmDRwIlpzgqRCmxhBYstqKmo9h9ArKacK6lGhV2Wqtnk6VbFKvZbLB8K9qZf/r
dLJgbtUw1hrzuactfYoRVpLtMa1oT+uZ0fi3SBMWr9dyygkvZ/d6Vsi/7vlQmdHs8VZwnhgx+0s4
xzU3lnGv8oe7lmaSzpAi37RuUY2gY8Qljb3P05CA3VvPz4QpPxj/0lCEaaDHcwpjz8LQM42SVEM8
/DLSeHr2j475bhrTYJA04MGW/wixpVdvgZKI+JKNKo3oSTUb0dfsAbMRZWhVDRrP7yjVFu45iFTH
ElbSlrQ8q93Ghzv8oZSW5A8mKaOExWCGzUBxjwjibyfbeMhwWEK3vYGJilPE4hUN4Y8q0k1OZnJJ
RSrIExniLxZbSIri0GOTPxWhcYZjnOF+oI03DvCNA/sP57jiDz6GDmifgxEflzGWXMFjNYTZlYoU
kxi0+Ih2iQGFP1CVoRPJTnc8iiGemMEPs7zDH/DIVfFuVKxdbaaUeGlakqRGxL2IDGssc6FnnOgT
84krTGHaDvvYl8v5vYQaboqOvdK3kvttJVuzPIghuIDA9axHYGlEzzOdKcBopv9HGwL7n34MoUeu
+AZoBilQkR6DEBse6zTUixoIlyQXVV3pZpqw1sxkVpcQnS6FbCljT3iXIBkh74aroYvSSMMsZgHR
oLeRRiiExDojKrGdIrqWPfKJzH9EJIpQPIlE2hbGu72NJSBR25w2MhGXyCSkInnfSOQ0kkZ5ZYIU
/Yd38Ki4Ota0pkepqTYoNzmE4aCYW9mntnaym2wUqUX4uExS2SIXwrilMwQpWmh22JfAHCkxhvkQ
JV34oJeGrF+tactSdWW8Xz0VlU+VGl6g5CMlMclTAzmVpkI3S+EA5yQVEYn5sMgIasjkimLQhudg
Ap3M3U0qd9PGFeU0RqDCdHD/ypxmM6EpQGm6x42SRZhUKiYxzTkmqIBUCGMfw4xi5cosrCtGKnHo
oSPZM0RWTWELTfihFX7TsTuhBtGINqpjkYppBv3tDx1pROzZU4kovBIxdPMPbmlloloJKkUwijaO
3PVLawpjmUQKp4pglyP48GvdQsKojfnkuWJTSFB5so3uHOwfOHVjHQGGFJzOV40Mw4E2EHYxQ4j2
K+P0CWgP8sl64Ip7GHyWOTWzDBY9MquhsOok/3KivJhlbN57blhoRCOThVIuTm1WQRspvbncZjDU
+tC1ILmX81I0qNNAiXC2UZHhXPduddNreMlExfqtb1wvmU4seKLesPGEsURu/0g1tmAIhel3f9WE
8mSf+QOCjeEpEtOGfS54QcfYdiHZaPFCWvMOIxmPoCbukCqXKKKbfai1s8WZcsPcr+eS9VgknstA
g7vDPf/QQw4d0T3sICFm+Pe2Oxmdl6aBUY119yToQpt2GeGPSEc6bdWtCEeJw82GXDhwSG6IIZjs
Dx+8F1A2bRxOh4IenjYsPzjYAixa6iKtWKW5W+lHbsVK1iEB9EL9eCRgiirhvKgYV552oqfLTLzL
jNLMeY7Lnd/SLCASYy2AUYv18hKKaawF2YdGtDTEPY3u/oPGX4JFSrXBiHVvZMcX0etI6Nac7lQU
3F79DRcKaM1nXtaOUVbPVP8o1rAb3EBzZbs36HiCVOO55R84nLbUcFPcERUpZ20+nTS6d9sWIVmc
/wCryYwW0BJL3K0tK+G1lKjy3Mgt4Z4d3aKDM79/gNRLLEHXpFeKaRsTR68c1YiQA5QVoptXUvcA
sz9ATcYnSqVP6aOvfYWCFCorsGGuvoEqVLENTr8cvQtfoT1AmaXi7fBZrQN2Xk5HbNeBxeuSgpFl
3jHW5UnbNXmOuFtjFyJtgMKTbx/PMQ2CD++ICd7MmGK74+XjW5LrO4bWiuB5AmavQC9SDIHxDeKT
EcryTwyowIFUKCaxG8SAC1tQRYCwgvCsCBimz9X1jf6BtB1iTYlUcmcJTaT/F2asCPA7Ae09mAEz
UuFDR2e+mskNGqTZKlEbysDk7/vlj6yMRCpRgYm8PeoSfFzEo90NE5ownKdvd1pbW0jY4eiLFJtI
Qxvp6ml+uCAGVYjWQHMev0/6Yaxf9Z6gzzKMACwV1xkd6cOTy8gGtxAZtDCrYuiMaGOePYMraXm/
pTPALtOJe6AGlLgcQpGfG0uJdHmJ45iGbXIi/AMwWgMn/cCsqfCcRHG1Etwm/9onQEJBisIH0kow
7Kk9evqz2JKZ4buHWSk/wSlChTOIV0mNYKmec3IkqQG0rQG2J9m4t3M9PCEyKGqELbCyqICcy7Ec
hUkYGLtAhri18fAH9Fuj/yp7Cn/Aj4sJPVnTCsi4tZwow/RyKtrYFJaxNhdKLSPaC90YmyMkD0IE
p8fAIGUQmeOjtupRM9xgsWU4BX84Q68zRPwJDnIjk+NAmHkRjmmAPK/rikr0jb7SvIGxmIihhtK7
gSWDBS9jun/glyuUPl1bEu2BRN1bsxOBIeAJxTy5wa4aECacnqZ5GqepCxLyQZmBh1+8Q2TikTCz
QK+jhoKgRbJJQ/qgivzwB4PbHKHyLOZ6RuAZHRDqhxRRu6w6hX6YRoaARfxxxm5Jr3uIiyBCpVZR
Rg8ZwnH0nVmKOd9goju0w0P0HvAquP5wmC3gAmpwoIOIxsrzjTm7wRR8DP9pYKLhk4ZQYQ2d6Cp+
9MeEykV6egW9kIaJlL52vMBqpBqO6x0nioX5WzLNGaPouy2r8IprnLyeyAYWSYh39Mh7ywnhAwsm
Qrrbio3X+8mkxB/gaEjM+weT9A3Kc6484RdYhMqDwAf7U8qt/EfvgYyr3MqwhDuPxEnz80knYhHb
ukTHWkuxZIiO0QmwdMu5JJC27ImyPBA8kcsDQTa7lBS8xMq9nCtLbEm6xDfDRELv6cjx0AaULMSb
3Iqz9Mou88v/EpDdAEw82Y149DpSJA/BlL7KPIhsyczCTDZ5fMxwhCnO/Mzy0obe+Li3E038SRb8
MZBqLM23oxroOUHyM83/iCyvoUKIhiAySixCx/wZiPSJVKCG5gRH9SLCp8zN/KOoI2wi/AEL8EJM
x9KJj9mNMtrL35mUjsmKAAmQhJg1oGFNhzTA3dRMgnxKWfy9ghjIOQRMQpzOIdvOKkSmMuIjT8tP
gvTLLVGW6ZzNkDGS/ASkPjK/25oGz3xLf5C8rXgu0HSUAwUn5PQm1LytauRQvYxPsNQJO9RQhZBM
+EzKBy3MaqiCF3iBvtpOhfgDLQBHRKNLaniBVMCHEg1LRnDRVIhP4MmTxjivVNCCFyiEBg1SiioE
F60gx+S6IePPwLmwbXDRaXjRJf3JiUqFF9CYsbHQQ4MBHnWiAF0IWICB/zR9gT8Qx0M7ryN1URoN
Ti31yhdIUxhg0/Q6URAdy39QBS81iN6IlWqAAVgwEC0ovwvqRaDsCVUoVAoC1Ds0SS2QU22Q05cz
UwJBUqyE0MD5U0PVikK41H/QAlVITIrKUZ/YU/K4tW1ozuAw1YNw1ADxtBlFkGlI0uoMHGpIhT9A
gRcYVYP40wDp0lmTvnyCBVF9ARQA0oXYVH9QAaOa09NkCCNdVi1oVq2gVBNtUwHZCSP9VS3IVWGF
gfOqBmZVCBgY16/jiWr4g2VFUmMdqm2Frv7sCg080lh11HUNVJ9Q1+ZazCIzJnZNL61gTub0h0g1
CCLN0w8Ft3yiVFOl1//QytIBUxaOgcqAlc+GoNT7EdetuAUYyFaxSQVapMTQilhy5detKNbACdk8
bVJ5bQg0Hdl/KASZ9UeDKBIYCFYtgAVCXIUXAMyLdYyJKlJENYhyFTMsDUXGwlCKVAifNYgm/SmD
+IN1vQr0usrrPAj/itmDKISa3Yl3rSCa7VatqAZgXQgtMATymFg8iQV1PQhC9QqyjdpRrdDhxDWD
MNRg/Yc/EA/rzAbOHJ1OZYigqk+yudQmVYWOm4ZY7VPm+rYurVohnZQ/yFaeZQhVCNZHMQiN1YpY
2Fau7QnNldXKbYg0XYgmvROcJFS/Bdzx2Aa5BTk8+dqD8NudgIEYyFD/QuXXfBqQk93bp9QCVGCs
hlVbhWjSH5XFB71UWMhXWYXTVDCQskSyOSuEcdUCFAhchAAbXEWBYC0E7k1VpeOYIw1fjnnXVOhS
LWiUJv3VmiXdF6nYP+VXHBUP6M3RFoHfVFUIR03TZu3SFyBVdL0HQ3VRFDAyF1XeluLcX0UQakhf
g4DTX81SwyXVipXRqX0BG1jdO83WP41VfHBRyP3bcB1b7u3ahvXTF8BSE8ZROUVTaUAFaUheFNXb
tUwFVCijatjeG6aGPyDWF0VPFdAJR3VSvk0BANECsPlNxxLVg1Bd9CoEqoHTS3XXACFhDzWIVMhV
zfXidxXVjhHiioKB/47J2k7bjUe12ReA3IRw339YBRhgYBlVPQ3+24Lo0oryWZ792KmdINPV3S2Q
2RlNQhgIEDt10UUWj9fdCshIhTTm2Di1Yzk+Y7CFgYVlZNxl05ZliCZdWatFVELN5LRd5EUG0tvN
SwBryyMtwLdkU//1YdwlYGF1YYMABP3F5Lvs2n7IVIZA00a5YT8tkCBO22ad5cGrZWHNVRxN5QzG
4kvVgkwmWBsl1VylWgK5H8A90q6VZmqm4PjsZubEUZEF22Y1BP/diSaNY+WVU1xV5yOtIEc1YeGk
oIT1L1gAXFmW5mUmVTltBl3mGHXmCTpe2SqGjCbNVnm+27tEl6vMCf9gnRVQ8+R2pgZmGNeYNRBB
7lKxhZEMnFCK2jKlM9LVrdh29t2uBedhleJLpuBGSWnfIFoObimkTVdpvp+YttlcnQaOvmHoxWSc
PYh3HVVnBttNTdqexeMGxYe0zV3lfYFGkdqKQmpIXVdB/gesxq3dHdm+ylZQlmIa5RYcDeU8wQef
pN6BRDJ6LWlwggHI7WZZfeuoXeoyhAEP/oc9XttaVgW8bmHI/YOG3V6Vbti29lMUqOcAExtIjmoK
bs6OEeEuvlRVQFeqvhMsXWgU+Dhsxd2nRtkbHl+Xa+NYRdMwWAit9peDaF+fYOvJRmxZVWfKNmFH
9Wsjo+NsxdKWYlz/jkGBJIUMU03sz5VIrGyIP5CGZkhchaiGFMhVG2jY3DYIQq0CqJ41apjinRDU
l9tWw55b2tWChn3XRsFRyPVpuAbvxlZB9PpUUt3Yo5bq824UQ7bljoGBY6KaO0nbsoaRI12Far7d
Lu3vua1qe7baAf8N74ZvO1TlQkDkhRBjrfjTb4Zq2I7VgpjmoSLN8kO2FZHMyCbrlobt/i4E8Xhb
Ww7uAQvTnZhm7qZwM25mO4XtRolsCkbvmLZucPaKSoQFNxYwev1wqgZnQb5wjnGFjF7mFQ+dNZWb
6/5nWp41lk5m1jZnGOGdyLZxFy4IOKbRakjSEodjHOeJI20UJp/Y/2lulITg2a5gXwIxkG+bqHvQ
AnzwaPeehtWGXp6lBi2ghpiN4pSm1Dwl1Dk/CKl85Nw80qeOWVVY7TzHcz0Pbwp26ay+1Bjm40aP
x/EM4CTbVD3X3DvXc2xV8hbWAt55Ydy9ZEqN6vrTir6CjDRtlB1vKa0O747eCiSnoIXgyahmX7X1
9DzvK3X14VTw85LViSatdfR2dY5p8KQOLTytBktF438I6cgVM5vFB/0m1TPW84TFc0Wm0Wn2cZHF
XHqd5l9Mbi3Jz3cNc23/0xQAVgm2Uxpd339Gb2pQgXFNWxgIX+t299yVIUAa750IdMy98X2HVz1P
3z+FASf+B1SIdP8bcFEYaIZscFEVgAXIXupiFQ9f3XIV6Bjr5tdp7uB4BGscznZqsIEBTgFOVwG1
xdLo3fFeLdnXhgXm3muGoOOhVttq/PgXMO2D2PEXSIE/8E6Y+lN/7uJm1QIVaNYXZdMYjtV5t2U9
p6AjXXmt9JkUVwhBz2ClV3Ko7+J45/JlnnFIf3qePfEj1O/2vZMjfXpgjdVpNucxPeRgfQHw8odp
HlegKXmOyQY5tXA6ZuG8dmOTxnaGCFoanaCEUHRIV3oYAARILdWDePep95y/jXhjJdRpmDUG5yaR
B4QnR++wFmqKil6g9+yHhVq3DOJmVffKfFqv6NXopl3s9k/aZ+P/9m0uQxty7ymSW019KHbhhGB0
1O1aU39GUhZgv4197I5RsB3VCwfLC3NMSfaJPIdc6xb0snx2dMHT1h1R3T18x/j15df65XRlXH3k
pB3/hBt7uCdwcPvltyuE2pZ0uVS2PV3VpB3ZP2WsOQMIf9O0/Sto8OC0gwpVvaCm8CFEfxD/USuE
4oWWVAUTTuwosSPHjiJHMnQ48iTKlCMThlTp8iXMmCe1FDpY6EWqjzJ3KtR5kmE1g9VgaHnYj+fE
lkIzwvSZUilKpwqhIi2oRVXVrCLxGcxG9aVArlp5DvyKctqfF7AKpv0zlqfYlNSIFkylBUZQhGMJ
PrwL4wUMrGDf/yqMW1AgyKx+X7wQTPhf2apxs2n9OG2a4ccivfrLRvmgVJHatDHG6FjzTrMGYWkB
jNNo1nv/+D5M++JPXsgpO6M+nFl2b9t/TPaOXfBz1OLK/yFfCRq1apFhDUY/WV3lZZfARyJ+vH1j
5oLhl5OFKG3n993kZaaf2Dxxe83XPXJluf6xxNDKx3u8j/Q9Qkc15Z9y183Xz3xVCQhXfQTKRNtU
iXkHE3/K6ZfUSfHJdKGDT+GzyUkARqShQcYQVxWHIk0jEHIkdugRgBwm+KKFPEFII47/iHUPJZQw
Y1KPlIgykTEg/hNkj/io9mGPRuq4iVPNIEmJQ5v0OGRXMbE4Tf82H54n04knmYgUl4VJ+NKHcLk0
JmopSmcQPpSMFeZDv9C5nE8JfeQPJc1swuM/RerY50NSSoPgJs2c9NEmohgjpaJWUkKilP/EQwk+
cSqq0I0daeOTMUGaJOmKPonSpEFBbipSNZI6+aExhTJzzyZinUqJkwa5uOBhI6kjakFS4pqZsLVS
pCpKrhYU6rAKFSuWpFhO5OZEfDFLZUHRPqTtP8IS2ulBTOJa0K2bhEmNpJtuMo2QMIWUUFxSfoiZ
QpvEWu8mRjKTXX8F9TlmXFB2ZO8/BAeaq0HaRBcmpPbKKaimB8lbcKwEVzpSo48Syi14zCgqCogT
G5zSlxuN1HD/qMd+nCs1hIJMcbdyYuwopCJLq3LBIEJMaL8xofwwiBEbJK+mEU8sUsY1YxqozKkO
Wam87K6qkj/dHdQyyB/dw1XLUwfqqJG49ug1dQbla269/FWDrcEXQzSQSvIGXe+9wRopiij4SCMW
zx3961DA9wqkTctcQX33zWeJd5LcOh5MZK5x8k22Qn87LpafBwkaM93cydR4ZiPDfLBhfU9keaYG
FT5009neuyJM2zlVzanMlByqsXBi+kvYikpJTZhKFdlstvrxTi6mcc4oEtYIDzr12tRo2jJHPJeM
L9oHjSyRNonCHKf0pju3UXXNm+1q6fkmuXrBlB+Ea/b/MFr3/+ODEtc1ali3Lp7pbbcu+UiYYaUT
ycZtTAOW/6hlkBR9iE/f2cQvtKcodTjvF834iLDaY4wPSetPE8HFqiT1i+Ux71T4WBXuCkWJXzxN
TkexYEF4pZAi4SJ3o7vaCpsmJdGhxDBVO8mtuJKvbOUqX1zhndts2JHh/QIfErkUtgxyKUWFyiQp
fAjsegITatwKhcRblpyYpL3E9UQ2w7Mhj6YWqnj841RME6KcFNjDWlEpJG6L05Tq1Yw7zZCLTuJh
sPa3EefBJVGpg12+dJI5irVskJuqWpAe8qhGmY1+xzJcyIwESBU9xGoQ+ZDc7mVA/zUyW6vyliT9
JAriGPCAVv8yzBATlpD2yDFciVra+erVJJl9CGHemsZ3RKHKYN3Da5sDX8F2ORIXzdBctyzYl2LZ
TJwBUCT/8lMILZktaUGsmG/5UJx0IpAHbkpeuJSGolJkImPcY37TtJ/3OOcSqlTtUwsUDx39GMiD
iIIZgYxTqtzXx5fp7k4XE5DbaCOVWsIpn6AR5LKCRgltigcqJnoZpIjFyyhGtJO6esmtsBUnZjRL
dJvzlqLANTRlVfKfOMNnj/ypFd6hq1IA/cc9gGkQkAkRRIRqRhb91gwE9SObzsIWu3rJlXFRh6gJ
sudUqvjM393wH6jA1kTl5zuIVq4ZGmvGxFLGuqVWjBKXsVL/QSCkFIYerGtyYiouOxqxrHakdM2w
YKLw95CIvWxnlPtIhepKyIhQjUh8fFFIAccns3LlHrESV+6QJZ1sCISprttnoKSRxmw1KbBkSmwg
mWovfGwtU2JZ29hOEg+WlsshEysXTClxqN6AFrJCfKy2vJXava4UVSHtETUm1jJcwUtSFE2JwlT6
FOz0KkcnSVOETMa8NR32INezzli4Al1OTsSzfVyPd7ubK4UdJqhv6q7mqpuUFCmQrVpUz2ycOxt/
fEq5ImHmY9QLEfwWFiXXlS+K7MspAT9nK1m5kBz1KxIZjo85AH7Jl4AzIxExNyYk5Ml/3zaNDD/4
IAS+p0vc//uWWl6IwVgMsXM/rKKjsJXCKAqsiV+U0364GCG86fBYRPyWGLtEGtep5YUjEmSKVOUe
HE7MkCdCDWolGUMWdvB9S2ZeHBc2vOtpsm6qQg0UUCMVKPjHH6bwlimrBKrlQQmC8GPlgvBXJTUm
rHSndY82o6mdHiaPjqmskCPLxMtgFnNH6FwZ5Wx5Gn72A6DJ5JQ8l01xzKMvRSzjD2lw2c9TADTs
BI0Up5D3MUfecpe/jGg9k+fQifYojhgtElM7GSV3WjN3R/Jmz/mD1ViOCW2W/MlNb4TH/2A1qRXi
5SmgAAUa+QexUTAFalRD2cY2yKWLLWZQA1vPt55ItU+8E/9V85kwhhb1qf2DHLNoWtvH4XC2aVQd
L2vEy9QIc0EQvWU/KOTSBJmCH6j9ZXgXx9eyNsiwi33sZC97y8Q+NrIJTpFKg1tF5V7cf1bt7Gcj
W9rMdjbCo61sikwj1H9+kZu2c6OAG/veFm/2NCiecGkv3OOjdu66v1wQYxe75lxWeUGmoJFpyLvS
qJAGvzXj4zP/+tnu9oPMkT7vei8b2flm+D9eHussL0p+vWF30anx8p7T+yDKdggK8t3xdN+HwFzR
BoCwnoqOXzrey0aBTKG9bIE83eXh3o1Os9Ltusj8HzRH+MIBj+xjT+PtHpfG0B9zbb4bhOY2vzng
/aFzthj/nuweUTCbrT7mj/h55l5+vN8FP/moT8HIRSd9sD9Flc5rw/E237IM5456qEs9JXaG7zJR
ovaG8/ztop/2FDpO+7i/Ze8v6Xzocb5lwBd+Uz23u1H+C+SEVaYlyP/7QZot+mP/SN+o13ONOy8Q
rKsO54N3u/drTxj+zofkJkH6PZaNcqazPP3VMTN5wrP77/f891vTefrdHUvIzm54EoqQ2f7xW/8x
XaSlQrNB304QlYOwW62hwGhwxAIeRNtRg849oOVlBYsxk2oAU0Ign0J8h1OM3oMs3nI9hPsVRBVY
XOv9XrHNWQA+xHZsWFM4UVboCUS8YNRZ3PKFy8QlhPe1/x2bzRkLooa7FZtJ/EGxvQLwmJ/GTRvt
3d20pARpTQWs4ZQnmWCv5Em9CV6wQZwL9t1D4J8GpsJ2tBmNaYaKUR+2oWEPnV91qFqATIO/Dciv
8VGNTQEeHgZ7/RB5fEZL4GEcPgZ/gCF1XIjOdSFkzNrVoEQiEllHMKKBnZ96hYZT1NghaoZOYGJI
6Fq94ceQfcqbidNmQIQkhgjIaQYkHodKxOJJENgejkRgjQeECJiAECJhUEsl8uFIgItP1FeFyQ9U
5JRK+BgzpkQrEgasJcjDQVlydEiTmUWFmIQk3sMzKp4C3Y8wbgZU5JlPkKLmVSNMdCONqGM6liHV
9UQ9Of9aOFbFEjaXljCUL06d4/BEejBUMMqhaGgFjxEYZelZIOZeTHwH5ikEgDSZ8aXhhpyEOarE
QuoFT+SZi7EXqrlEeJnFe/DHQXoO7gHYidwimvRgoPFHMMoRpKHYhMjHtNwhnJ0JnLhitfCWVgjY
nchRPV6krizh4vHZnGUGQynJM/pDRT6FNPYGJ1LFWs1jTcqEiNDiRnbETo4kgUgFcZAZr7mjQaRZ
1blEIkqESZ4je7ikU4LGfAgER1AFVaLXgfWXWYqkVtDZOJpMSLZXb2BeWfoDrMWhfWjhph1kP9ai
VPBLuEBjXE5iFoLYYCCFXSrEYb3lL75ET/LgS9CGfYn/xVL6pFY0SKNVywgmSFJmHj1G1zv6hDSw
1a1tzVxSh1fwlzKe5ouUyVjQC5m02n2EJC3RJiW65HIElUTMJlRuSH5sBlhORD9AInE65ov8I0SY
BCfKJUpum1f2Rk+2GjVoyJLRYrntSYVEB1caxHXlHUQEI0dMI10eI2GxZPFl53WeV2NemT3WVT7u
VQ6qZ1S+RDth5kM8ZJbME2Qwk4h9mFOYxZ7ER+oUh36mhjuq4Yt4BWV6GGZEBmTGhJK8o0UKKNVA
hYdGJPN86FmY2IKaZnzS5H0A6INxSNXcp6cYINEtl1iERlkWGDqipnOKpXyam0DGVwzp4YnGmX+o
6F7G/1pIQgd7+uhBmF7PKN5MAqdlmmhuXoZ5BqmQ4lpMEGmb3Ndr6iOe3RlS9AOfHSkOPmlwxhBE
ugt0VmdxKJB9/VCYaOlUJJdSkKaXQgZibuh6LFpu7iiSmil5UEVp/oOc3iaerKe7gMaE1id31Bd9
2ReQLtiDQGWe7SGZamE7bU2DciinLGpvAIIzFAcpPMET5AYystldupoekCoWjYdXxA5UqAKpmqrq
INdJFCq1ICWj1ipqrOlYZEOo0ohsLKF7noQVkAKPPgQgPIE2qEIqWIFIWAGtTuJxvpdIOAO0FoQe
AIKboZ1K3MON6EFeOEOpJsVpAGqy2ir4rYhnjBlMaP/DsT7EoCbklWort9IIUlLDClRDKjyBYyRE
NZDCCpAqstorZNwrYxaEKtDBtECotU6EHpyrwhZsb6hCtsqjp9Ajn2aFr4qbS1CDHuyrrP6rQvzB
E6yAxFbFeVwb4eChL+5BNTgraIAsVvRrXjRDubqJFUisSk3nRFTDE8zDQwBtsM7nTmwrdTZpjjbs
eVqpZjATzKqCYzhESFgBt5aCHkwLO6bmpnVsR1jBqjoGZcjsPwBC1rLFvQqqUDxB0d7oTzwBRMhq
YugXhwBtytbVTsSFp9YmlvbpRICtv8qSQZDCxb6NjrUER1TDzgrovDIOIKzI2UKGwpxt4BZE5foD
2Br/hMX+Q7n26689AcIqRDWs6hPoAT6MbLeU6z9Uw7KCbkGYbV34K9CSqr+qgh5kK7ZCxkeMrriu
asC6rj8obulqLu0GxejCbewG7rKGajVg7j+M6r0er7RShBWUbl4Ah0QYhtf6x6VirEI4A7eObn1S
Q+VKJukGhcWSKlYgbdme6/LKaqn6g8WqArL2q2O0rpLk7zRUA3xmGWUozKseBLmS6sCWqzNMw+L+
mif8w+aC2T1IawIvBMNyLv1OA9s+b7aOblBU7uI66wX/QwLjRrwCrcmALAtsqyqsACDYLfXya7aS
Arc+6+rC8NkCArfSAQqvwOr+AR1YbTWgLEWwQDWQ/2tQRCzRfpT8SE+9asXW8uO7Tt9vHkQKTyu2
7i8L7Ky42nDqFizZsoWsrrDd4kP1rrAHB6sRL64QOwM19K/VpUgyXOwfZDDQCm0z3KseFCw+wC3Q
Tiv/BssTtCjsJPD0EjFFXDC/Ii/5Ci3AIW/kMjC5IisgXME/kGtBWIE2vHFQrEK27kH4gjBWKG72
/cEe/BrQZq0qQEFQAEIgzC/a7hecdO9XFmcdModergcgjPJDXAFHBIK/OmDnqq4qFG01DLO0EgTb
dlzlem7Zhu4fJIMqNKtyHMWsWa1BUHNdZOviHnEeY8XmDjCrAgJfyPA/IC35hmoq3CvsMjDyjjMX
r/+zQbCtM5yrzXpy2Zpy6RJHAlcuIbNvQUiDPpcr7M4uxVLvQA8jatToAiUiZ8IkUkSw5jZDXujB
2d5uQSyZ8bqFQiCt/GYrRRssBa8tswaqmxBy6joG0hKy3E4yIwNCMF+NPzAvNbPwsgasIAvGH2Rt
1j4BlWZHS2sr/dJqQF/wzsIw8jZDMJerrAYsA2er64IZTqmuOO+sBxsvIMDw6qquhc1YkiH0AinQ
pv7bTiT1QUSsBedF5VK0RJSq+D7EBcOrYJQvZtwDuQoGS5cr63ZSLW3h21DYymqD4lLsPFfy/JZq
v74wUwPC9MqSKhwvN5eqFYDtCj8BskKBv/auRDP/m7/SwV+rQujacOFW8gLLrd16wkxbbMyK7BOw
gNT+QxVELCCsQNYSLqGyLU5Dq91GrOxKK+ymMPjub1giRBMzZHGwcVLkVHMO7WPDMCkUsbMCcRxT
BzXA8CM38tDsa9lCQUE4g3Vfte1W6D9AgQcvtrQCbcHmZWKUwh+b4x6QKlM/wSrrNGffqzVbL6dU
bymgtOsidjXgg8kCwio8weI+tkOQa4BbwSoI2xMcePYleD1fNbfCr2AA7c4itmCs9wova8RuROli
BYOTa/gSrPFWL4Pjwyu4LWFwtdNCxH/TLouHL+mehj+Iq2BPBPw29VJLEYCL9/BetWSb9d3+aZ6O
/0Q14MZAhC6qBVUD46SSqQRnW+lxp/gsWiXI5bVK8HOKa9aMnLNB3HFHBHCkeXS47O0KB+lXQ3l0
ZiU+ukT5pjgJbTcLYwi/cMSaayi6ToRRm/l6kEiQW6PZoQhPXsaTK6kAYzWeq/knXwF1g+lzoPeP
J6RfkhY+FHSKoUSZU/quCm5X52qOdSX3Kqs7u6OIaapYpK9k++nqkq/6JumJLatDT0Slj49Xg9c+
qshl8GRlKq2QoakZLgfp2niNFqpB7xqUWufDtuB7DWSgEXdqZkOn7RckzsiOFPql4/W7eJtLmCRw
SBhhiMg3huSnnIdPsBWESER0eLmOaoURrrHtwf8Ekb76bigXrj6FGI4FndVoQnxJYOlXp0Dn3lrX
pSpQcOPh7d36EuM6jrTEhKbq0oapiWeIbkSHm3RKcKdhPQ68XFijfNHTnl15Yu6XHLm7976FMiJi
muZkSxoHLG96jnzFYTrtgniWX7qJD67HZ9xYiLnoAg1rTqYEqPZGM4qEKjTDvmZG+hq5oK/H9vqt
gxB3SOwtR0ykQTzuW6iVJPKvBQf74n1YvD5GNnQbV4irUwbCOzd6TAZiJTZuR6B4Vky8Ox7r4o1b
SoDyohD6i46nShzvIUvs77L4rFb5tLo0SLSt0SIEC14Y2sMGf4XkrfWssg+t76LuQ3A27co41mP/
9ElkuISkvEiI62qLbrw+t7bu6E03LZhzyqfrZptqya+mZ7hIxaubfWH8u9+nAhny7ieP8+lDJAKr
AgMdsYq4bEyc8JyDcF5EcOgirkK0OjX+8N1OQ6I/qVLQgdF/62LKxE5ff3qYVsFLpcqfaYacUNh6
PlYsK1aQ9EiUc0uASx6fPxPHhDOIPch+772WMwPnxqgi8GG07iq0rj+4M1/UOEBU+/evmp4nev5l
s6JqIKAn8wo+eWLlX6o9/v6pkqhqmj89gFRVI/WE4T89JQemVJkS40qXL1/egzlT5bSZNme2pJlT
506fP4EGXYmPpj+ZzgIRRKiSVMlmTwT+AZTy/49EZ0olVrsi8aDMfy0jWhEIiKjDkhHxEa2250lK
jU9WDXyL8mU2oT9VTa3Ite3Akybt/nNGERBCjdpUBiY1VRVFwWIb/9P25CrItgurQVXqL69JkA5f
TQupcSxdmjjvviSauidMaTdTr+wYuydqldRi086d0vE/h4AKp/xLMuPUhb6XYkRMUKwzyv+s6MGX
+ergav6siP1Daulik4anfrzZb5rX3SozC9Sz9M/APwyniR6YPiWg5QOXq1ouHroqUmIz6quaPxCC
6glSBmomJJKCU8WZaQIb6DhArjrvrtVyynAn2yzskCWV/GnNw6BEDGpA3hiLLqOF9EBwRZWOG//I
n+ViHIiaiV7sDyOHBDouspQyy2spmO4bcSXigGThH9FWUCkVAKHD6B7bFkKMOI1YQC24gZB0rqT2
qvpLrvgiTIUOk3abBsOgmvHJKJjWdOkefMzLraM7S4RpSpj8sS1PIwFVSQ+BgmwIKhaeAESgJf2p
YinqUsLpqUXl0gwKxlZYFAqEnMnUpN7+GUnMoFD7Eyj6qNrDPVUza2gqavy5qr2O7nlKxrYWe6JP
BfurJhDnFgXWtx71CkkybbTJpiVg9dqNTqHinAkfU1fyJ1oLcUtttphkBCrCn/oJ9KXIqrkTOrGg
KGkPVajB7bhV2srWLc2qYWiVpdIFTrN/0s3/6IqvnkimIeiKpdRNoKj1DVSFQ03UMobWy4iagugi
TSNqVMnriWlSaUagRBdKhTKEMgNuURyBS9C0kp3JzEVxYY75JXlHxIlabTj8KZvXZJ7vuHLjK5li
kbOp5rg/pkHMYIdaHhQ6BJ1bTCOGpGpID38cQggQBFFudkmfrq3W1Lc2mndQiRCs6iCBNPJ6vomE
RCyVaYibJjOnNZKvP5UcipFug7mkqNCeSST8LppdIi+3PM2189tAHeJLUQnX9qsjvRx6Fj20bSTO
uakiQtKkRAeE29AaU8qmSDlpkmYangEN0c6UcH4p57s8hfl2oHY3fCbEXSqvdw1rGuhx32Me/x55
IpXnU9yEZ6pTxtubn8lXmaG3fXmhgB+xNYyozX556UEEKuztf+rpeN3Oy7l2I90Ovv3cuseveprW
Rz8lWGWXraiv9Je03d1PWsirH/t8QkA7iS825HNJNhTooQiyBnrhis20zucha8VmgjJanfac9Q/Y
9YyBO/kgt0iVGwdGSoX3U5z+cpNBEJ1QJSNEmAyN9KaarHAgHZRMCmGzId9lD4f5U4kFCxcoI+6k
J5OzXQlh6BIcAmVP88PeavrkEyTCcIksjCJMmqc8AsKqh0byIQ9B5MMvVuuAOlNj8WLzwv9R8R9T
nJ3/etinhNlwjQNBYwKDQhQMvbF8udniS/8Oib4/VgtmNLyjUBIJQJdkb04dGh4WIxUu8UVykumr
mUu04Q9YOfIfi/zQSlwHRnw0j5Q6C16E3neelkzrJqhxYP2gCC0zjiiWQjFlGcEIyH+QEZhA4aMU
XQI8Tqrwi6ghjw6Rh0R/KEt+CATRn6bRDwf+KZdJ7GNdeha2+62pf8L8ye2K1M1vCpGLX8EJIQt5
oZfkqY0jihY813kaPTHRi3f5Je/yCah6Eq412uxQLkukTg9Fa5niauUcLzjPOhJvIHbMhgXxWUwL
KeMdHOXoMjoa0o+KNKQg9WhJOzqNk5o0pSPlqDTeMY13sHSl0jipS0lKU5TedKYkxaky4tP/U57q
9KcdnZJPZ4qPoSIVpNTIKVM72o+VQnWpS5XpSlX6VI4yY6chdSpRhSpSbYCVrCKValinWtWY7vQe
ylAqWkN6Va3m9KzKaOtM75rWuepVrmUFKkyLytF6vIOwhX3HYAsr08MatrCIZWw9FGtYxEZ2sdlw
amMNK417LJaxnH1sZz0rWdA61h+Y7axjRcvYe1gLH4UtLWpNa1h8wJawtH1HaU87Wt12FreGnYZt
EQvT2P4jtqklrDZqu9vP5pa5y/1sa437js2Gtrjv6AdnI/tb5Ua3usllbHl2C13CcnS8heWoXMub
3pCmN6jqFe56O5oN9b4UvuStr3nxO9/8/943vXfV73/521E6+cO+Bd6vgQGM4AArmMEHXmuDAYvf
0ir4vedd8H4j2+AEO/gdb/0vgTm83rMStsIh1vCF3Wvi3oI2sSx2MWOv21nygPa9mX3xd2+cYxf7
o8Y61vGKb2yUEPmYyIWNcZENO+Qb91gmLO7xO5DrY3tMF8lEFi+RoyxjGBP5yFX2MnQNzNK+3pel
5QWpYrMq5q6SOKxmJvN671rmNc8Zp7elb5jfjGc941fOdd7p6+jcZra6ec+EtlaguaoMbXYVsNIw
6XT9XGd7KLrPQhVupAWN6UrLGVabzjOf4xpoTxc60IbtspdNbWRUV/nJq/ZtYVvtalkTlv/K75DG
qYlcayTf2scdcfFmYyxTyt7YHva4bY5jzdtZM1YyyybssJ2tY7tumNqhJm9Wq31ibZv4wPKFb4Zt
jWJxb5vak+Z2tUucbcLuTLEKBvd87QHY6/r3wonmdoQ3vFlyj/vc45bvPdLNb3WnOtq6jnbBtazj
ZM8a2i82trOJew+JH/zVOaZsaXHd2Yf7eOGylS7FKe5tizvbrno1eVdX2g/NnjywcJWpX/eK8rOa
NBssD2uEYW5zmtYcri3POcpLyuO89pzoP/c5VIW9UwgC/ehqnWpHdE7VmDd96kVv6cylntasCna7
3aWuxIHbde9eOezNTW2tM152XnvXucb/7e2MCHvksrf9uHMnLHHt7nXUanbtdGc7d/8e297mPfC1
VbLeQQvkwlN38WkH7XQpS/jFAnnfGqa35bWN28pzG70C97yGV5lYbeD784XNsob/sfmBo7i9F+48
g8Hc78xXG9yvl31+QUx6Csv08uadUu/nK1PiglzHBk+8FFCAginQ2uLJtwONAT6N5IfC1W9XvJcb
TuRm5xj5yl/2lPpx6uSjgPrfzfgyxg/SPhE5+7PGrR3G31loZ1nWiuWxwgleWPAj+bqk9jNMRw3U
yCvO1isUxg8FmEAKZAr+nu+8UIAYMm2mpAEFioHQzCv5lsH/IlDYNC8CA9ACQXDNUs8D/zvq/VCg
AQUwBS1wzDgq+UAhrFgQv5JPGbxN06yNBMkL+XAQ1EDB+1oQBaZN1D7NzECMzZZh6UIQANdLGpRQ
A9XMvmTrykCr/VCNGBCw/EBhClAApAyw/GIKBW5MATsOA2VNClkMBe6A+Axr+CqOsAxwGaKsC6Pt
+u4ADJFMCpjg+qINDb0M/dKQsPDQDA1LCqQApIpsxbos45AN1XRt3wJO9daLCZgAv0CBCSAQ/iBw
vGKMwZIv3PSrB6Xg3O6Bq1aPo0Dx9koxv3iOsJgADEEs+TKx9NJrxOALBULR88gvFXWR3yrx+bKt
EyGRvGgREh+x36rM+FwN+ZaB7wBuGf9uUQcZSw9nig89sbPkkMimzMuuUQ1ZjLLu4BZLCxqXreF6
kApBCxSk4AWXjU4Org6LDP28kBvlEb+iruRusB5zygCl4OTIbxkM0Pterg/GLxRM8QQ7qg7tQKeQ
jxjgDwX66h+VTxn+kQnsgRk6EaQa0iBZShMO0CAlcvzsYKkyEgxBiiHHrxhMCiKnwKSyqiMd8h3I
jyMRUK5M0geFqvsgEKRs8RJR4AU/sh8aMiTDLSNv7argLwM7CiJDQbP0rRhacQuDEqSY4B4osBLJ
ryHvwMIy8vnOTPoQsKcQ8CNtUia/UhmeMvkm0emYzurUkupsjvDugbbiUuwYrxXVMbX/0FEd66EV
m0oZ3wEaBZKw6rAn2U4L++CwqGEL3VAx35AVbTEUEpD6mGAKKvAo2Q4aBwv5KtAA/9CwerAyc7EY
puAWp2AS30EOGxO1etAOEAsdmYD6BDIUVssAWRMmfTG5YpOwVpOwcrMe4G8KwlEx7wH+QIE8SrOw
JHGxvhGkRnGtDAv+bjE3TxMP+0AfB8v7Vmsa7qAC+fId4C8UyON1ou8uk7MeQkEKeLI2DRDwGK89
Je896VLbIA2/9A0VOyr5ioHBjpK8utMfKHAalw8mwdAObrPAiiEiCcs/F7P8iLOjdFAZdBATHRQM
DYz8yKsOqS8DH9S84K++CDGkbPEj/wnSOwkTAi9UMTtqP0nUF5PzNHMRvuwyKSkwB31RB2WqFSEQ
VnR0Rd+BGKbBFwXSEDGwCFN0CwvSNFEzF9HPDu4BKFEAsDpxN5XhDspDRPlTMTtUvWzx2exz82Al
GENsCpEMGXMM/f6TxVqUsF6UGg3rQO3gDm7TGg3ytl40AU8T/vigsF60sD70TVHUM+cUJgOUFZng
LnUTBVDBCxsTMu8AAu00FBrUEJEzQGGKCabBEN3xHQKTGDizs0TTDv8SVN/hNdU0QO+hNKfJH0hx
QU9zGsqPD7PBDqSA+obNTgkL/QLUMgGVHbeUsbTwHUBBOnvwLlHgMEnUVRkrUCfOxf/YsMo6gv7c
ryNg5b5sLwBjMAQ5ygpBtc6+EiNRQBN4tMAMUPpucaSE6zuXYRmkD1yV4QB9sSALVClRsMyO0lvn
VRxH6hTG7wUbkgk0YUR7MPmkoA/8bDeFC1HB0jTHbwrsoAKRkqUQ1Bm31RJJlF1tswX3ESwJ0w6m
gV9B8lLjq7ys8DZ/s6NaEaXiw0g5s0KTj2FLKksrNqQm0AVldEQfzanu7O5s0MDuRAWFUAN5yxx9
SxoTCwmTdU8La/m2cT1dNB4JC/5cVVSXdVRvUTvtEP2MlbGYtrBAofXQdFC3EVcL6+GEqw6Xrw4l
9VbZtLDStguFywCp7EfV1DRdrBL/1RFr2TY6UTQvezRQ3+FX36EOr2sbRc6wlnZNO3PGepUBGctN
QWsyC2trFUsg/xD+KjAauTSb7m4el00YVe+o/msVLw/50JNDPdYnYTJjK/EWUzRUv/AWL88HqTJj
tZVD1dQOyUsfx6sYUJCwRjakdhMQCVMZDrZcdTBGTTEUAna9shK/GvRpn1RGW/IB+TS/pJNxWzAD
0Y8JyCtLl3S8urAF7QCmghdY3/VWke8FITAsgXVOee53m3Z3E7JXOSoUpRQmudc7M9Z1+be+Ssu/
QFcWx20+9cve1Itz4064Tq0VA5QY4FQwUXR7J5X6iqF0IdcfWlE2tfZFpY9uLbVG/yFQNFk3aXMR
UuX0DjbOVhm3GrUwDeHxHdwUI/+wFUG4p/j0T6mUa6NXU6nRDpyWR0GhDv9wVpGTdbszcBUzhmPK
VgWU+oI1bQlLCwM0AXOyMQ23WG/YYQvxb6mRCUAqNvnuH0wT+ajPAC/3iBkLuq7rupaEcwWR1jYO
tNqSLbXqrcw13FwqI6fARN9BJldSQFdSGZyyZeE1pbwSJUOKI1+wUpUvA52SXD0qfElKE7pvXkVK
CrQBBRINMgVWfW0qpGryNT9KKT9qGZ5yCoqqIafgBR2yipMv0TKSIB82pJph+vyxZW0W/UDBoxoy
FKd0IC0MmCEyIZFK+UBypGZwp/9aFhSkoSZpsvuWL1sFVhn8s5HRcSBN6iknkaaWwalujaOQyy3X
0q+GzqTMreXmbvDosh7MMLjYEz6Zi/5ga0quj8qoDJ431x5sK45JzLauD54jb52ZD/HMrrEKd/FU
syfxmWwh67QMbrCatT35ufCyAZ/ZED6l0Phsi8GibPNsb7wIWIBnj78CmGc76tK61PRCGsLqS77W
L6bcjcNqrgZTuj4/WuCIlNzMuBSFi6s6r7fAaxjPzaY6UL3ejd8mrEtXOkxfDFp/rcb0UIFv1yWp
uqqtuiOr+aqruhmkzyu1OmWt+h8cUqsPcGY7MhuSLzHH2iUz2aq7mqzhWvpe4QD/s/qqp8EVDhCt
4Xqv4dqsk8+rk0+sk0+U6pqvk48J46+zyFTHIhrJ3tjFnDDPUPrMBPDhPsqwMTuzqVoaLHKtq9oV
ADusNTlpQiO0OxIVqDq0/RoF2tqq1VqzU9slC/u0Vxu2U9u0qRq1DxC3xTqTcTu2U1tfKfSylMEe
PpDO/uG4d9ZnoXDVQoSwETiN1VDXMs5rc6yxndWwJK7LnHoNj83ZMq6eO27VqMwolg27R06xgzbH
iLaw0HvHguzGwHQX51vA6Fv2lvq+jTrEhA34Fgy3jlr1hHq8itq/ySun8Vu/ZXEVb1ATS7Go4YwJ
Nev0zk0bNGzGDti12tvLAO4e/yb6EFkMujb8+55NEZdtw4UWtLIsxW/MxBP0x1yru3PswxmxyA4a
x2jtpb1svJGMxTtLrXAu68ZZyFtOrlbKjkHM6GBwyIEqBvExrb7iHpm86nA21JT8yon8waoOrOzt
yRltyi2MrLYurnjuyc3tCemYr8A8pIAL2ghPGvA5umSKKJRLyeASt2qNtnytoBG6swYCc+O8ukrr
7Qja79yz664r0Puczw/roXfrNbzuxg89t8r7sNxcoKHsneU4v7Ct9HQvpaEswPdLvDavPndR4iTu
xAIuu0D9vvQNudpYwT2330Rd1kUR88wraUS632BKGuyh1ne92roxui1uxImd2LmKTGiN3cfi9thk
nMNd/NjH9MaM772jje8oDtWrDM9KTLl3EFu//WcTNGm8vdzX68yHMKVGDbyWG9yXoa0gjxpaC9xA
qts/7VrF3d0/zd7Mfc9WLtzb/WfbzQPhPZuakM/uYVrzHb5wXNrncUaWfceLzMX7ztmM4tSkMdod
3uF4nMhkp+M3Xv+SfbGlrdXru/J+D9hP3uQdDL10vBjTi8FPLMCHb+VtPdssm+XL69NvPtgNfL9W
FRIDAgA7 

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAOBaPUt014334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Nov 2007 04:36:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAOBaPsB014333; Sat, 24 Nov 2007 04:36:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAOBaMID014326 for <[e-mail]>; Sat, 24 Nov 2007 04:36:24 -0700 (MST) (envelope-from [e-mail])
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm17f4748333a; Sat, 24 Nov 2007 19:49:20 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm3274741c772; Tue, 20 Nov 2007 00:36:59 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 20 Nov 2007 00:36:59 +0800
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8po-0006UP-M5; Mon, 19 Nov 2007 10:46:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8pl-0006Rx-5I for [e-mail]; Mon, 19 Nov 2007 10:46:49 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu8pk-0002gw-Sr for [e-mail]; Mon, 19 Nov 2007 10:46:49 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id ACAA426E39; Mon, 19 Nov 2007 15:46:48 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu8pk-00036q-J1; Mon, 19 Nov 2007 10:46:48 -0500
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 19 Nov 2007 10:46:48 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: [e-mail]
Subject: Last Call: draft-ietf-pkix-2797-bis (Certificate Management  Messages over CMS) to Proposed Standard 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Reply-To: [e-mail]
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:[e-mail]?subject=subscribe>
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-Auto-Forward: [e-mail] [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
[e-mail] mailing lists by 2007-12-03. Exceptionally, 
comments may be sent to [e-mail] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lANN2YP3066567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Nov 2007 16:02:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lANN2YCS066565; Fri, 23 Nov 2007 16:02:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lANN2WUk066548 for <[e-mail]>; Fri, 23 Nov 2007 16:02:33 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 21406 invoked by uid 0); 23 Nov 2007 23:02:24 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (24.131.121.208) by woodstock.binhost.com with SMTP; 23 Nov 2007 23:02:24 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 23 Nov 2007 14:41:28 -0500
To: "Santoni Adriano" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: R: TimeStampedData draft updated - please comment
Cc: <[e-mail]>, <[e-mail]>
In-Reply-To: <[e-mail] cal>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] 
>[mailto:[e-mail]] Per conto di Russ Housley
>Inviato: martedì 20 novembre 2007 22.53
>A: [e-mail]; [e-mail]
>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: [e-mail]
> > [mailto:[e-mail]] Per conto di Santoni Adriano
> > >Inviato: lunedì 3 settembre 2007 10.42
> > >A: [e-mail]
> > >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:[e-mail]]
> > >Inviato: venerdì 31 agosto 2007 17.48
> > >A: Santoni Adriano
> > >Cc: [e-mail]
> > >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: [e-mail]
> > >> [mailto:[e-mail]]
> > >> Per conto di Julien Stern
> > >> Inviato: venerdì 31 agosto 2007 13.43
> > >> A: [e-mail]
> > >> 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:[e-mail]]
> > >>>> Inviato: giovedì 30 agosto 2007 23.05
> > >>>> A: Young H Etheridge
> > >>>> Cc: Santoni Adriano; [e-mail]
> > >>>> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lANIrk17044272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Nov 2007 11:53:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lANIrkYU044271; Fri, 23 Nov 2007 11:53:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lANIriYj044264 for <[e-mail]>; Fri, 23 Nov 2007 11:53:45 -0700 (MST) (envelope-from SRS0=R0k4=QQ=acm.org=[e-mail])
Received: from tau.invalid (p508EB083.dip0.t-ipconnect.de [80.142.176.131]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1Ivdee0ENX-0002xb; Fri, 23 Nov 2007 19:53:33 +0100
Received: by tau.invalid (Postfix, from userid 1000) id 3F47A1EBF0; Fri, 23 Nov 2007 19:53:31 +0100 (CET)
Date: Fri, 23 Nov 2007 19:53:30 +0100
From: Bodo Moeller <[e-mail]>
To: Paul Hoffman <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Eric Rescorla <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Message-ID: <[e-mail]>
Mail-Followup-To: Bodo Moeller <[e-mail]>, Paul Hoffman <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Eric Rescorla <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240802c36c9d3d7c8e@[10.20.30.150]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06240802c36c9d3d7c8e@[10.20.30.150]>
User-Agent: Mutt/1.5.9i
X-Provags-ID: V01U2FsdGVkX19qqDRMCwQpZJdxMRDp3+NzOvhBvr93NYteb42 gyRCjkMN4rHqPIoWjCc3rJixbWejDEfMDJM5T7PI6jlBdRU9D2 eikCeBcozvic4+AnLBK4ag0RLJM2Nnmsmz/nE8r7wrqS/Wi+jy 6Hw==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lANGqDwU033439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Nov 2007 09:52:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lANGqDHl033438; Fri, 23 Nov 2007 09:52:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lANGqBX7033426 for <[e-mail]>; Fri, 23 Nov 2007 09:52:12 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA70552 for <[e-mail]>; Fri, 23 Nov 2007 18:00:04 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007112317514108:14732 ; Fri, 23 Nov 2007 17:51:41 +0100 
Date: Fri, 23 Nov 2007 17:51:37 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Draft response to the liaison from ITU-T SG 17 to IETF on the resolution of DR320
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 23/11/2007 17:51:41, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 23/11/2007 17:51:57, Serialize complete at 23/11/2007 17:51:57
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="=====003_Dragon157875718364_====="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lANFPjkA026186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Nov 2007 08:25:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lANFPjUf026185; Fri, 23 Nov 2007 08:25:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lANFPhxo026179 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 23 Nov 2007 08:25:44 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Fri, 23 Nov 2007 15:25:42 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 23 Nov 2007 15:25:42 +0000
From: Stefan Santesson <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Fri, 23 Nov 2007 15:24:32 +0000
Subject: Agenda posted
Thread-Topic: Agenda posted
Thread-Index: Acgt5PLPX7bJ/FCOQFaoQNcvTCE7GA==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D32032E20ADCAEAEXMSGC332eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lANFL7eq025856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Nov 2007 08:21:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lANFL74d025855; Fri, 23 Nov 2007 08:21:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.150] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lANFL3pI025848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Nov 2007 08:21:04 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240802c36c9d3d7c8e@[10.20.30.150]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 23 Nov 2007 07:20:46 -0800
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Cc: Eric Rescorla <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAN9m4Bu098704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Nov 2007 02:48:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAN9m4DX098703; Fri, 23 Nov 2007 02:48:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAN9m2ad098694 for <[e-mail]>; Fri, 23 Nov 2007 02:48:03 -0700 (MST) (envelope-from SRS0=R0k4=QQ=acm.org=[e-mail])
Received: from tau.invalid (p508EB083.dip0.t-ipconnect.de [80.142.176.131]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1IvV8j2Fz4-0006OA; Fri, 23 Nov 2007 10:48:02 +0100
Received: by tau.invalid (Postfix, from userid 1000) id 4E6461EBF0; Fri, 23 Nov 2007 10:48:00 +0100 (CET)
Date: Thu, 22 Nov 2007 12:53:33 +0100
From: Bodo Moeller <[e-mail]>
To: max pritikin <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, "[e-mail]" <[e-mail]>, Paul Hoffman <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Message-ID: <[e-mail]>
Mail-Followup-To: Bodo Moeller <[e-mail]>, max pritikin <[e-mail]>, Eric Rescorla <[e-mail]>, "[e-mail]" <[e-mail]>, Paul Hoffman <[e-mail]>, "[e-mail]" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.9i
X-Provags-ID: V01U2FsdGVkX1+UVbq7jxQJPPebbNvgUv+7h02g2qIHWBplBF3 2CYc6NpwsYxDY7UWC+v4fFh6J1x6HrlZmwTI4RAl7EDD/aMwgA D7vOSrHKgrunyEyWeA3hD4JqylCzc3uwdWu3m7GT04UpJgArgD ABQ==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAM1M1j3066366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 18:22:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAM1M11X066365; Wed, 21 Nov 2007 18:22:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAM1Lxk2066340 for <[e-mail]>; Wed, 21 Nov 2007 18:22:00 -0700 (MST) (envelope-from [e-mail])
Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipbi.ntcif.telstra.com.au with ESMTP; 22 Nov 2007 12:21:56 +1100
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 04E83FFA1; Thu, 22 Nov 2007 12:21:55 +1100 (EST)
Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id MAA08619; Thu, 22 Nov 2007 12:21:55 +1100 (EST)
Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2902.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 12:21:54 +1100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Date: Thu, 22 Nov 2007 12:21:53 +1100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [TLS] DSA/SHA-1, and OIDs
Thread-Index: Acgq2OmrK/CPwedORjuYCnyihrUTXgAQSaBAAF1tZzA=
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 22 Nov 2007 01:21:54.0880 (UTC) FILETIME=[116FEC00:01C82CA6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id lAM1M1k2066360
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]] 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALJsxMk046449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 12:54:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lALJsx8Z046448; Wed, 21 Nov 2007 12:54:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALJsvrb046441 for <[e-mail]>; Wed, 21 Nov 2007 12:54:58 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.0.102]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1Iuvew-0001wr-3n; Wed, 21 Nov 2007 14:54:54 -0500
Mime-Version: 1.0
Message-Id: <p0624050ac36a3ac1f5ae@[192.168.0.102]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail] oft.com>	<[e-mail]> <[e-mail] oft.com> <[e-mail]>
Date: Wed, 21 Nov 2007 14:53:49 -0500
To: Eric Rescorla <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Cc: Stefan Santesson <[e-mail]>, Eric Rescorla <[e-mail]>, "Manger, James H" <[e-mail]>, "[e-mail]"	<[e-mail]>, "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALI972h037487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 11:09:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lALI9735037483; Wed, 21 Nov 2007 11:09:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (news.meritdirect.com [209.213.211.195] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALI96ti037468 for <[e-mail]>; Wed, 21 Nov 2007 11:09:06 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7EF6733C2B; Wed, 21 Nov 2007 10:04:00 -0800 (PST)
Date: Wed, 21 Nov 2007 10:03:59 -0800
From: Eric Rescorla <[e-mail]>
To: max pritikin <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, Paul Hoffman <[e-mail]>, Stefan Santesson <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALHRwMc031107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 10:27:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lALHRw5I031106; Wed, 21 Nov 2007 10:27:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALHRuR9031084 for <[e-mail]>; Wed, 21 Nov 2007 10:27:57 -0700 (MST) (envelope-from [e-mail])
X-IronPort-AV: E=Sophos;i="4.21,447,1188770400";  d="scan'208";a="158442114"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2007 18:27:41 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lALHRfBe013610; Wed, 21 Nov 2007 18:27:41 +0100
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lALHROZZ000834; Wed, 21 Nov 2007 17:27:24 GMT
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 18:27:23 +0100
Received: from [10.32.244.68] ([10.32.244.68]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 18:27:23 +0100
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: Paul Hoffman <[e-mail]>, Stefan Santesson <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Content-Transfer-Encoding: 7bit
From: max pritikin <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Date: Wed, 21 Nov 2007 11:26:53 -0600
To: Eric Rescorla <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 21 Nov 2007 17:27:23.0592 (UTC) FILETIME=[C73A2480:01C82C63]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2863; t=1195666061; x=1196530061; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20max=20pritikin=20<[e-mail]> |Subject:=20Re=3A=20[TLS]=20DSA/SHA-1,=20and=20OIDs |Sender:=20; bh=3e8YIUVBxBvBewuJQ5w8eqApu9UR0DtUzm2J6aHeGtg=; b=K6yXAEuRBNkpFD0EMZCFkkz2UZR5hA7RWL+bA+hLnOMQ9Cd/2sxtMniIyRxoF1E+WsrT9Pup 66eHD7zHSlEs0HwG697Vmft2DXX9kNZFKWrseAOAShfSyhd0Z47FhNci;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALGw0VD026247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 09:58:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lALGw0Vc026246; Wed, 21 Nov 2007 09:58:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALGvxtg026234 for <[e-mail]>; Wed, 21 Nov 2007 09:58:00 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 6F56533C2B; Wed, 21 Nov 2007 08:52:58 -0800 (PST)
Date: Wed, 21 Nov 2007 08:52:57 -0800
From: Eric Rescorla <[e-mail]>
To: Paul Hoffman <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, Stefan Santesson <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
In-Reply-To: <p06240806c36a0fa51f9e@[10.20.30.108]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALGpQY7025640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 09:51:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lALGpQC8025639; Wed, 21 Nov 2007 09:51:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALGpF4g025608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 09:51:16 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240806c36a0fa51f9e@[10.20.30.108]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail] oft.com>	<[e-mail]> <[e-mail] oft.com> <[e-mail]>
Date: Wed, 21 Nov 2007 08:50:33 -0800
To: Eric Rescorla <[e-mail]>, Stefan Santesson <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALF2rso014114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 08:02:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lALF2rsF014113; Wed, 21 Nov 2007 08:02:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALF2pES014105 for <[e-mail]>; Wed, 21 Nov 2007 08:02:52 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 3114833C2B; Wed, 21 Nov 2007 06:57:50 -0800 (PST)
Date: Wed, 21 Nov 2007 06:57:49 -0800
From: Eric Rescorla <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, "Manger, James H" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALEZL8T011796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 07:35:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lALEZLN0011795; Wed, 21 Nov 2007 07:35:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALEZKfd011789 for <[e-mail]>; Wed, 21 Nov 2007 07:35:20 -0700 (MST) (envelope-from [e-mail])
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 21 Nov 2007 06:35:21 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lALEZJZf008011; Wed, 21 Nov 2007 06:35:19 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALEZJb6020145; Wed, 21 Nov 2007 14:35:19 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 06:34:47 -0800
Received: from [10.32.244.67] ([10.32.244.67]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 06:34:46 -0800
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, "Manger, James H" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Content-Transfer-Encoding: 7bit
From: max pritikin <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Date: Wed, 21 Nov 2007 08:34:19 -0600
To: Stefan Santesson <[e-mail]>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 21 Nov 2007 14:34:46.0804 (UTC) FILETIME=[AA19B540:01C82C4B]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2170; t=1195655719; x=1196519719; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20max=20pritikin=20<[e-mail]> |Subject:=20Re=3A=20[TLS]=20DSA/SHA-1,=20and=20OIDs |Sender:=20; bh=fFdcki2T7xPGV8OtL5T7kjE6IOFwknUTxgBxK/0Qs8g=; b=IyOsvZ8CodCxQabjnpw0PBBUgkTcO99hew2DvpXJaCZ1GJeWaH4v5QJQttWHmQ+DZYaipu++ cWyxgeQ0ankOK235mmjybmUGnrHAYnEvRErKNG76YBOa/RGKeTt4nNcB;
Authentication-Results: sj-dkim-3; header.From=[e-mail]; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
>> Sent: den 20 november 2007 18:34
>> To: Stefan Santesson
>> Cc: Manger, James H; [e-mail]; [e-mail]
>> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALCmwJh001767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 05:48:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lALCmwnL001766; Wed, 21 Nov 2007 05:48:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lALCmugk001750 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 21 Nov 2007 05:48:57 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.222.3; Wed, 21 Nov 2007 12:48:55 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([2002:4135:d55c::4135:d55c]) with mapi; Wed, 21 Nov 2007 12:48:55 +0000
From: Stefan Santesson <[e-mail]>
To: Eric Rescorla <[e-mail]>
CC: "Manger, James H" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Wed, 21 Nov 2007 12:47:58 +0000
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Thread-Topic: [TLS] DSA/SHA-1, and OIDs
Thread-Index: AcgrnDhnKbG8Kks0RPCy0emscOerSwAnq6EQ
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lALCmwgj001760
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> Sent: den 20 november 2007 18:34
> To: Stefan Santesson
> Cc: Manger, James H; [e-mail]; [e-mail]
> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAL7kRHo075761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 00:46:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAL7kRUe075759; Wed, 21 Nov 2007 00:46:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1relay.itmaster.local (host48-104-static.43-193-b.business.telecomitalia.it [193.43.104.48] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAL7kP7C075743; Wed, 21 Nov 2007 00:46:26 -0700 (MST) (envelope-from [e-mail])
Received: from POSTA02.itmaster.local ([193.43.104.10]) by mail1relay.itmaster.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 08:46:20 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: R: TimeStampedData draft updated - please comment
Date: Wed, 21 Nov 2007 08:46:18 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TimeStampedData draft updated - please comment
Thread-Index: AcgrwE3L7IFHNypBQBGtWwvyBOinsgAUTX1g
References: <[e-mail]> <[e-mail]>
From: "Santoni Adriano" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 21 Nov 2007 07:46:20.0204 (UTC) FILETIME=[9B074EC0:01C82C12]
X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.0.1023-15558.002
X-TM-AS-Result: No--20.848300-0.000000-2
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAL7kR7D075751
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]] Per conto di Russ Housley
Inviato: martedì 20 novembre 2007 22.53
A: [e-mail]; [e-mail]
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: [e-mail]
> [mailto:[e-mail]] Per conto di Santoni Adriano
> >Inviato: lunedì 3 settembre 2007 10.42
> >A: [e-mail]
> >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:[e-mail]]
> >Inviato: venerdì 31 agosto 2007 17.48
> >A: Santoni Adriano
> >Cc: [e-mail]
> >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: [e-mail] 
> >> [mailto:[e-mail]]
> >> Per conto di Julien Stern
> >> Inviato: venerdì 31 agosto 2007 13.43
> >> A: [e-mail]
> >> 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:[e-mail]]
> >>>> Inviato: giovedì 30 agosto 2007 23.05
> >>>> A: Young H Etheridge
> >>>> Cc: Santoni Adriano; [e-mail]
> >>>> 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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAL2d9W3056717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 19:39:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAL2d9YJ056716; Tue, 20 Nov 2007 19:39:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx06.plaxo.com (mx.plaxo.com [66.151.128.12]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAL2d88I056708 for <[e-mail]>; Tue, 20 Nov 2007 19:39:08 -0700 (MST) (envelope-from [e-mail])
Received: from bes01.plaxo.com (bes01.plaxo.com [10.1.10.1]) by mx06.plaxo.com (Postfix) with QMQP id 995B111074 for <[e-mail]>; Tue, 20 Nov 2007 18:39:07 -0800 (PST)
Message-ID: <[e-mail]>
Date: 21 Nov 2007 02:39:07 -0000
From: "Rodrigo Botafogo" <[e-mail]>
To: "Ietf-Pkix" <[e-mail]>
Subject: Your Contact Info
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKMsfBh039000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 15:54:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAKMsfP0038999; Tue, 20 Nov 2007 15:54:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKMsch2038992 for <[e-mail]>; Tue, 20 Nov 2007 15:54:41 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Date: Tue, 20 Nov 2007 14:55:02 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [TLS] DSA/SHA-1, and OIDs
Thread-Index: Acgrx2NtlIqwAwRzR5q3reb/tLBRZgAANGEg
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Eric Rescorla" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAKMsfh2038994
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]]
On Behalf Of Russ Housley
Sent: Tuesday, November 20, 2007 10:42 AM
To: Eric Rescorla
Cc: [e-mail]; [e-mail]
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?




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKMQ473037316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 15:26:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAKMQ46B037315; Tue, 20 Nov 2007 15:26:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKMQ3l0037307 for <[e-mail]>; Tue, 20 Nov 2007 15:26:04 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id lAKMQ30i027201 for <[e-mail]>; Tue, 20 Nov 2007 17:26:03 -0500 (EST)
X-AuditID: 90333308-00000f1c000007e0-2b-47435efa5b5c
Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 17:26:02 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 17:26:02 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Date: Tue, 20 Nov 2007 17:26:02 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [TLS] DSA/SHA-1, and OIDs
Thread-Index: AcgrnD7GaEgncnFERZiJtjiaoFoeRwAILEpA
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 20 Nov 2007 22:26:02.0697 (UTC) FILETIME=[556ED390:01C82BC4]
X-Brightmail-Tracker: AAAAAA==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAKMQ4l0037309
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]] 
Sent: Tuesday, November 20, 2007 12:34 PM
To: Stefan Santesson
Cc: [e-mail]; Manger,James H; [e-mail]
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKLsKo8035012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 14:54:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAKLsK36035011; Tue, 20 Nov 2007 14:54:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAKLsJm6034999 for <[e-mail]>; Tue, 20 Nov 2007 14:54:19 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 11850 invoked by uid 0); 20 Nov 2007 21:54:11 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (24.131.121.208) by woodstock.binhost.com with SMTP; 20 Nov 2007 21:54:11 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 20 Nov 2007 16:53:20 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: TimeStampedData draft updated - please comment
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] 
> [mailto:[e-mail]] Per conto di Santoni Adriano
> >Inviato: lunedì 3 settembre 2007 10.42
> >A: [e-mail]
> >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:[e-mail]]
> >Inviato: venerdì 31 agosto 2007 17.48
> >A: Santoni Adriano
> >Cc: [e-mail]
> >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: [e-mail] [mailto:[e-mail]]
> >> Per conto di Julien Stern
> >> Inviato: venerdì 31 agosto 2007 13.43
> >> A: [e-mail]
> >> 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:[e-mail]]
> >>>> Inviato: giovedì 30 agosto 2007 23.05
> >>>> A: Young H Etheridge
> >>>> Cc: Santoni Adriano; [e-mail]
> >>>> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKLsCH4034993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 14:54:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAKLsCgV034992; Tue, 20 Nov 2007 14:54:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAKLsBFR034985 for <[e-mail]>; Tue, 20 Nov 2007 14:54:11 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 11643 invoked by uid 0); 20 Nov 2007 21:54:04 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (24.131.121.208) by woodstock.binhost.com with SMTP; 20 Nov 2007 21:54:04 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 20 Nov 2007 10:42:09 -0500
To: Eric Rescorla <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKHcbih012323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 10:38:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAKHcba4012322; Tue, 20 Nov 2007 10:38:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (news.meritdirect.com [209.213.211.195] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKHcbqi012316 for <[e-mail]>; Tue, 20 Nov 2007 10:38:37 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id B3C8133C21; Tue, 20 Nov 2007 09:33:36 -0800 (PST)
Date: Tue, 20 Nov 2007 09:33:36 -0800
From: Eric Rescorla <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: "Manger, James H" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKGj1hB007322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 09:45:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAKGj1eR007321; Tue, 20 Nov 2007 09:45:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKGj0Om007307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 20 Nov 2007 09:45:01 -0700 (MST) (envelope-from [e-mail])
Received: from GALATIONS (pool-71-111-65-176.ptldor.dsl-w.verizon.net [71.111.65.176]) by smtp1.pacifier.net (Postfix) with ESMTP id 56EFD6F19D; Tue, 20 Nov 2007 08:44:58 -0800 (PST)
From: "Jim Schaad" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, <[e-mail]>
References: <p0624051fc368a94e601f@[128.89.89.71]>
In-Reply-To: <p0624051fc368a94e601f@[128.89.89.71]>
Subject: RE: WG last call (2nd pass) on CMC docs
Date: Tue, 20 Nov 2007 08:44:58 -0800
Message-ID: <03c601c82b94$b0a47060$11ed5120$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcgriVgu8tdTHm1FTYykLFRYll++HQACzitQ
Content-Language: en-us
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Stephen Kent
> Sent: Tuesday, November 20, 2007 7:17 AM
> To: [e-mail]
> 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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKGKWsW005224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 09:20:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAKGKW6e005223; Tue, 20 Nov 2007 09:20:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKGKTSS005215 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 20 Nov 2007 09:20:31 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Tue, 20 Nov 2007 16:20:29 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 20 Nov 2007 16:20:29 +0000
From: Stefan Santesson <[e-mail]>
To: "Manger, James H" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Tue, 20 Nov 2007 16:19:40 +0000
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Thread-Topic: [TLS] DSA/SHA-1, and OIDs
Thread-Index: Acgq2OmrK/CPwedORjuYCnyihrUTXgAQSaBAAB21BnA=
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id lAKGKVSR005217
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Manger, James H
> Sent: den 20 november 2007 03:18
> To: [e-mail]; [e-mail]
> 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: [e-mail] [mailto:owner-ietf-
> [e-mail]] 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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKFGjIF097540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 08:16:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAKFGjB2097539; Tue, 20 Nov 2007 08:16:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKFGiID097533 for <[e-mail]>; Tue, 20 Nov 2007 08:16:45 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1IuUqC-0003hx-3X for [e-mail]; Tue, 20 Nov 2007 10:16:44 -0500
Mime-Version: 1.0
Message-Id: <p0624051fc368a94e601f@[128.89.89.71]>
Date: Tue, 20 Nov 2007 10:16:49 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: WG last call (2nd pass) on CMC docs
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAK7SAMa063321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2007 00:28:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAK7SAKd063320; Tue, 20 Nov 2007 00:28:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1relay.itmaster.local (host48-104-static.43-193-b.business.telecomitalia.it [193.43.104.48] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAK7S8E9063307 for <[e-mail]>; Tue, 20 Nov 2007 00:28:09 -0700 (MST) (envelope-from [e-mail])
Received: from POSTA02.itmaster.local ([193.43.104.10]) by mail1relay.itmaster.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 08:28:05 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: R: TimeStampedData draft updated - please comment
Date: Tue, 20 Nov 2007 08:28:03 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TimeStampedData draft updated - please comment
Thread-Index: Acgq9M9RxLR3F8/NQKKSVO0x3cMRFAAUVjFA
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santoni Adriano" <[e-mail]>
To: "Tilo Kienitz" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 20 Nov 2007 07:28:05.0004 (UTC) FILETIME=[E3D34CC0:01C82B46]
X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.0.1023-15556.002
X-TM-AS-Result: No--4.580700-0.000000-31
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAK7S9E9063315
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]] 
Inviato: lunedì 19 novembre 2007 22.40
A: Santoni Adriano
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]] 
> Per conto di Santoni Adriano
> Inviato: lunedì 3 settembre 2007 10.42
> A: [e-mail]
> 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:[e-mail]]
> Inviato: venerdì 31 agosto 2007 17.48
> A: Santoni Adriano
> Cc: [e-mail]
> 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: [e-mail] 
>> [mailto:[e-mail]]
>> Per conto di Julien Stern
>> Inviato: venerdì 31 agosto 2007 13.43
>> A: [e-mail]
>> 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:[e-mail]]
>>>> Inviato: giovedì 30 agosto 2007 23.05
>>>> A: Young H Etheridge
>>>> Cc: Santoni Adriano; [e-mail]
>>>> 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



Received: from h223.67.16.72.ip.alltel.net (h223.67.16.72.ip.alltel.net [72.16.67.223]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAK4Adhi050821; Mon, 19 Nov 2007 21:10:40 -0700 (MST) (envelope-from [e-mail])
Received: from young2 ([151.87.252.246]:2004 "HELO young2" smtp-auth: <none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>) by df431048bcsnet.net with ESMTP id 033930664C389 (ORCPT <rfc822;[e-mail]@mx1.imc.org>); Mon, 19 Nov 2007 22:10:36 -0600
Message-ID: <001901c82af9$02c13960$0120cefc@young2>
From: "Oliver W. Aldrich" <[e-mail]>
To: [e-mail]
Subject: A is delete
Date: Mon, 19 Nov 2007 22:10:36 -0600
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0016_01C82AF9.02C13960"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.1409

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAK2HwAD045577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 19:17:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAK2HwpZ045576; Mon, 19 Nov 2007 19:17:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAK2HuiZ045569 for <[e-mail]>; Mon, 19 Nov 2007 19:17:57 -0700 (MST) (envelope-from [e-mail])
Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipbi.ntcif.telstra.com.au with ESMTP; 20 Nov 2007 13:17:54 +1100
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 525CAFF85; Tue, 20 Nov 2007 13:17:54 +1100 (EST)
Received: from wsmsg2952.srv.dir.telstra.com (wsmsg2952.srv.dir.telstra.com [192.74.195.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA20036; Tue, 20 Nov 2007 13:17:53 +1100 (EST)
Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2952.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 13:17:53 +1100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Date: Tue, 20 Nov 2007 13:17:50 +1100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Thread-Topic: [TLS] DSA/SHA-1, and OIDs
Thread-Index: Acgq2OmrK/CPwedORjuYCnyihrUTXgAQSaBA
References: <[e-mail]> <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 20 Nov 2007 02:17:53.0002 (UTC) FILETIME=[8E352CA0:01C82B1B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id lAK2HviZ045571
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]] 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJLeTAm025501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 14:40:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJLeTrV025500; Mon, 19 Nov 2007 14:40:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.seccommerce.de (mail.seccommerce.de [80.152.147.206]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJLeOYV025490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 19 Nov 2007 14:40:27 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 6662 invoked from network); 19 Nov 2007 22:40:23 +0100
Received: from pop1-2539.catv.wtnet.de (HELO ?192.168.0.107?) (tk@84.46.89.244) by mail.seccommerce.de with SMTP; 19 Nov 2007 22:40:23 +0100
Message-ID: <[e-mail]>
Date: Mon, 19 Nov 2007 22:40:19 +0100
From: Tilo Kienitz <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Santoni Adriano <[e-mail]>
CC: [e-mail]
Subject: Re: TimeStampedData draft updated - please comment
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]] Per conto di Santoni Adriano
> Inviato: lunedì 3 settembre 2007 10.42
> A: [e-mail]
> 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:[e-mail]]
> Inviato: venerdì 31 agosto 2007 17.48
> A: Santoni Adriano
> Cc: [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
>> Per conto di Julien Stern
>> Inviato: venerdì 31 agosto 2007 13.43
>> A: [e-mail]
>> 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:[e-mail]]
>>>> Inviato: giovedì 30 agosto 2007 23.05
>>>> A: Young H Etheridge
>>>> Cc: Santoni Adriano; [e-mail]
>>>> 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



Received: from [85.124.207.246] ([85.125.183.231]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJK7WIf017328 for <[e-mail]>; Mon, 19 Nov 2007 13:07:36 -0700 (MST) (envelope-from [e-mail])
Received: by 10.43.27.191 with SMTP id eFLkStUNTYPUJ; Mon, 19 Nov 2007 21:07:32 +0100 (GMT)
Received: by 192.168.27.107 with SMTP id FbBnUmozRbfCmp.9037064301866; Mon, 19 Nov 2007 21:07:30 +0100 (GMT)
Message-ID: <000901c82ae7$ceb5ebe0$f6cf7c55@Vaio>
From: "erik Hole" <[e-mail]>
To: <[e-mail]>
Subject: 0hsabaw
Date: Mon, 19 Nov 2007 21:07:27 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C82AF0.307A53E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJK1Bia016586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 13:01:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJK1B5J016585; Mon, 19 Nov 2007 13:01:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJK17Ps016577 for <[e-mail]>; Mon, 19 Nov 2007 13:01:10 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1IuCnq-0007Rr-3z; Mon, 19 Nov 2007 15:01:06 -0500
Mime-Version: 1.0
Message-Id: <p06240510c3677b8aa64a@[128.89.89.71]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Mon, 19 Nov 2007 15:01:07 -0500
To: Eric Rescorla <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Cc: Eric Rescorla <[e-mail]>, Stefan Santesson <[e-mail]>, "[e-mail]"	<[e-mail]>, "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJJC2wG012699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 12:12:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJJC2Gn012697; Mon, 19 Nov 2007 12:12:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJJC0Tt012687 for <[e-mail]>; Mon, 19 Nov 2007 12:12:00 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 800F233C2B; Mon, 19 Nov 2007 11:07:03 -0800 (PST)
Date: Mon, 19 Nov 2007 11:07:03 -0800
From: Eric Rescorla <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, Stephen Kent <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJIdi3v009198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 11:39:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJIdiV1009197; Mon, 19 Nov 2007 11:39:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJIdgJe009189 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Mon, 19 Nov 2007 11:39:43 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.222.3; Mon, 19 Nov 2007 18:39:41 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Mon, 19 Nov 2007 18:39:41 +0000
From: Stefan Santesson <[e-mail]>
To: Eric Rescorla <[e-mail]>, Stephen Kent <[e-mail]>
CC: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Mon, 19 Nov 2007 18:39:00 +0000
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Thread-Topic: [TLS] DSA/SHA-1, and OIDs
Thread-Index: AcgqzKXJLLPnSoYjSlyrf9YbiBN5gAADC46A
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAJIdhJd009192
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> Sent: den 19 november 2007 17:48
> To: Stephen Kent
> Cc: Eric Rescorla; Stefan Santesson; [e-mail]; [e-mail]
> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJGqqLD099762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 09:52:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJGqqQ8099761; Mon, 19 Nov 2007 09:52:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJGqpvr099754 for <[e-mail]>; Mon, 19 Nov 2007 09:52:51 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 8147233C2B; Mon, 19 Nov 2007 08:47:54 -0800 (PST)
Date: Mon, 19 Nov 2007 08:47:53 -0800
From: Eric Rescorla <[e-mail]>
To: Stephen Kent <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, Stefan Santesson <[e-mail]>, "[e-mail]"	<[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
In-Reply-To: <p0624050ac367691c5467@[128.89.89.71]>
References: <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJGZnDY098732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 09:35:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJGZnoG098731; Mon, 19 Nov 2007 09:35:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJGZlTS098725 for <[e-mail]>; Mon, 19 Nov 2007 09:35:48 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1Iu9b8-0003zT-6O; Mon, 19 Nov 2007 11:35:47 -0500
Mime-Version: 1.0
Message-Id: <p0624050ac367691c5467@[128.89.89.71]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail] oft.com> <[e-mail]>
Date: Mon, 19 Nov 2007 11:35:47 -0500
To: Eric Rescorla <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
Cc: Stefan Santesson <[e-mail]>, Eric Rescorla <[e-mail]>, "[e-mail]"	<[e-mail]>, "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJGSVuF098178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 09:28:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJGSVii098177; Mon, 19 Nov 2007 09:28:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJGSTgY098163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 19 Nov 2007 09:28:31 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240801c3676a0d8b40@[10.20.30.249]>
Date: Mon, 19 Nov 2007 08:28:15 -0800
To: [e-mail]
From: The IESG <[e-mail]> (by way of Paul Hoffman)
Subject: Last Call: draft-ietf-pkix-2797-bis (Certificate Management   Messages over CMS) to Proposed Standard
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
[e-mail] mailing lists by 2007-12-03. Exceptionally,
comments may be sent to [e-mail] 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJFkoga093970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 08:46:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJFkoow093969; Mon, 19 Nov 2007 08:46:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJFknu2093961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 19 Nov 2007 08:46:50 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id ACAA426E39; Mon, 19 Nov 2007 15:46:48 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu8pk-00036q-J1; Mon, 19 Nov 2007 10:46:48 -0500
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-pkix-2797-bis (Certificate Management  Messages over CMS) to Proposed Standard 
Reply-To: [e-mail]
Cc: <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 19 Nov 2007 10:46:48 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
[e-mail] mailing lists by 2007-12-03. Exceptionally, 
comments may be sent to [e-mail] 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



Received: from hp5150 ([221.215.203.74]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAJEqnNI088768 for <[e-mail]>; Mon, 19 Nov 2007 07:52:50 -0700 (MST) (envelope-from [e-mail])
Message-ID: ae6eb01c82abb$d9ae0310$0b01a8c0@HP5150
From: "Dr. Vito Harding" <[e-mail]>
To: <[e-mail]>
Subject: Your girlfriend leaved you alone because of your cock size.
Date: Mon, 19 Nov 2007 22:52:07 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441

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/



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJDHX1S077461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 06:17:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJDHX3V077460; Mon, 19 Nov 2007 06:17:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJDHTgD077441; Mon, 19 Nov 2007 06:17:30 -0700 (MST) (envelope-from [e-mail])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA55058; Mon, 19 Nov 2007 14:25:17 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2007111914170173:22070 ; Mon, 19 Nov 2007 14:17:01 +0100 
Date: Mon, 19 Nov 2007 14:16:58 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: "S-MIME / IETF" <[e-mail]>
Subject: Re: TimeStampedData draft updated - please comment
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 19/11/2007 14:17:01, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 19/11/2007 14:17:28, Serialize complete at 19/11/2007 14:17:28
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id lAJDHWgD077448
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]] Per conto di Santoni Adriano
>Inviato: lunedì 3 settembre 2007 10.42
>A: [e-mail]
>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:[e-mail]]
>Inviato: venerdì 31 agosto 2007 17.48
>A: Santoni Adriano
>Cc: [e-mail]
>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: [e-mail] [mailto:[e-mail]]
>> Per conto di Julien Stern
>> Inviato: venerdì 31 agosto 2007 13.43
>> A: [e-mail]
>> 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:[e-mail]]
>>>> Inviato: giovedì 30 agosto 2007 23.05
>>>> A: Young H Etheridge
>>>> Cc: Santoni Adriano; [e-mail]
>>>> 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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJBbqYZ067979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 04:37:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJBbqZn067978; Mon, 19 Nov 2007 04:37:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1relay.itmaster.local (host48-104-static.43-193-b.business.telecomitalia.it [193.43.104.48] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJBbnCR067960 for <[e-mail]>; Mon, 19 Nov 2007 04:37:51 -0700 (MST) (envelope-from [e-mail])
Received: from POSTA02.itmaster.local ([193.43.104.10]) by mail1relay.itmaster.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 12:37:03 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C82AA0.78F9608C"
Subject: TimeStampedData draft updated - please comment
Date: Mon, 19 Nov 2007 12:36:48 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TimeStampedData draft updated - please comment
Thread-Index: Acfr5lpn9VemHXgsRge4idPMW7Jr1ACD5vMADyZpYIA=
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santoni Adriano" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 19 Nov 2007 11:37:03.0453 (UTC) FILETIME=[816BF8D0:01C82AA0]
X-TM-AS-Product-Ver: SMEX-7.0.0.1345-5.0.1023-15554.003
X-TM-AS-Result: No--9.237500-0.000000-31
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]] =
Per conto di Santoni Adriano
Inviato: luned=EC 3 settembre 2007 10.42
A: [e-mail]
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:[e-mail]]
Inviato: venerd=EC 31 agosto 2007 17.48
A: Santoni Adriano
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]]
> Per conto di Julien Stern
> Inviato: venerd=EC 31 agosto 2007 13.43
> A: [e-mail]
> 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:[e-mail]]
>>> Inviato: gioved=EC 30 agosto 2007 23.05
>>> A: Young H Etheridge
>>> Cc: Santoni Adriano; [e-mail]
>>> 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"

DQoNCg0KDQoNCg0KDQoNCg0KICAgICANCiAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBTYW50b25pIA0KICAgIElu
dGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQWN0
YWxpcyBTLnAuQS4gDQogICAgSW50ZW5kZWQgc3RhdHVzOiBQcm9wb3NlZCBTdGFuZGFyZCAgICAg
ICAgICAgICAgICAgICAgTm92ZW1iZXIgMTksIDIwMDcgDQogICAgRXhwaXJlczogTWF5IDIwMDgg
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICBT
eW50YXggZm9yIGJpbmRpbmcgZG9jdW1lbnRzIHdpdGggdGltZSBzdGFtcHMgDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAg
ZHJhZnQtc2FudG9uaS10aW1lc3RhbXBlZGRhdGEtMDEudHh0IA0KDQoNCiAgICBTdGF0dXMgb2Yg
dGhpcyBNZW1vIA0KDQogICAgICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBl
YWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgICAgICAgDQogICAgICAgYW55IGFwcGxpY2FibGUg
cGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzICAgICAgIA0K
ICAgICAgIGF3YXJlIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3
aGljaCBoZSBvciBzaGUgICAgICAgDQogICAgICAgYmVjb21lcyBhd2FyZSB3aWxsIGJlIGRpc2Ns
b3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiAgICAgICANCiAgICAgICBCQ1Ag
NzkuIA0KDQogICAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0
aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgDQogICAgICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBh
cmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCANCiAgICAgICBvdGhlciBn
cm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0N
CiAgICAgICBEcmFmdHMuIA0KDQogICAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1
bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIA0KICAgICAgIGFuZCBtYXkg
YmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQg
YW55IA0KICAgICAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1E
cmFmdHMgYXMgcmVmZXJlbmNlIA0KICAgICAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhl
ciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIgDQoNCiAgICAgICBUaGUgbGlzdCBvZiBjdXJy
ZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgDQogICAgICAgaHR0cDovL3d3
dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0IA0KDQogICAgICAgVGhlIGxpc3Qgb2Yg
SW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAg
ICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIA0KDQogICAgQ29weXJpZ2h0IE5v
dGljZSANCg0KICAgICAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDcpLiANCg0K
ICAgIEFic3RyYWN0IA0KDQogICAgICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzeW50YXgg
d2hpY2ggY2FuIGJlIHVzZWQgdG8gYmluZCBhIGdlbmVyaWMgDQogICAgICAgZG9jdW1lbnQgKG9y
IGFueSBzZXQgb2YgZGF0YSwgbm90IG5lY2Vzc2FyaWx5IHByb3RlY3RlZCBieSBtZWFucyBvZiAN
CiAgICAgICBjcnlwdG9ncmFwaGljIHRlY2huaXF1ZXMpIHRvIG9uZSBvciBtb3JlIHRpbWUtc3Rh
bXAgdG9rZW5zIG9idGFpbmVkIA0KICAgICAgIGZvciB0aGF0IGRvY3VtZW50LCB3aGVyZSAidGlt
ZS1zdGFtcCB0b2tlbiIgaGFzIHRoZSBtZWFuaW5nIGRlZmluZWQgDQogICAgICAgaW4gW1RTUF0u
IEFkZGl0aW9uYWwgdHlwZXMgb2YgdGVtcG9yYWwgZXZpZGVuY2UgYXJlIGFsc28gc3VwcG9ydGVk
LiANCg0KICAgICANCiAgICAgDQogICAgIA0KICAgIFNhbnRvbmkgICAgICAgICAgICAgICAgIEV4
cGlyZXMgTWF5IDE5LCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0gDQogICAgIA0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICAgSW50ZXJuZXQtRHJhZnQgICAgICAgICAg
ICAgdGltZXN0YW1wZWRkYXRhICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAwNyANCiAgICAgICAg
DQoNCiAgICAgICBXaGVyZWFzIGRpZ2l0YWwgdGltZSBzdGFtcGluZyBoYXMgYmVjb21lIHRoZSBz
dGFuZGFyZCB0ZWNobmlxdWUgZm9yIA0KICAgICAgIHByb3ZpbmcgdGhlIGV4aXN0ZW5jZSBvZiBh
IGRvY3VtZW50IGJlZm9yZSBhIGNlcnRhaW4gcG9pbnQgaW4gdGltZSwgDQogICAgICAgdGhlcmUg
aXMgbm90IGEgZ2VuZXJhbGx5IGFjY2VwdGVkIHN5bnRheCBmb3Iga2VlcGluZyB0b2dldGhlciBv
bmUgDQogICAgICAgZG9jdW1lbnQgYW5kIHRoZSBhc3NvY2lhdGVkIHRpbWUtc3RhbXBzIGluIGEg
c2luZ2xlICJidW5kbGUiLiBTdWNoIGEgDQogICAgICAgc3ludGF4IHdvdWxkIGZhY2lsaXRhdGUg
a2VlcGluZyB0cmFjayBvZiB3aGljaCB0aW1lLXN0YW1wcyBiZWxvbmcgdG8gDQogICAgICAgd2hh
dCBkb2N1bWVudHMgYW5kIHdvdWxkIHRoZXJlZm9yZSBpbXByb3ZlIHRoZSBlZmZpY2llbmN5IG9m
IA0KICAgICAgIHRpbWVzdGFtcC1hd2FyZSBhcHBsaWNhdGlvbnMuIA0KDQogICAgICAgVGhpcyBk
b2N1bWVudCBwcm9wb3NlcyBhIHNpbXBsZSBzeW50YXggYmFzZWQgb24gW0NNU10sIGJ5IGRlZmlu
aW5nIGEgDQogICAgICAgbmV3IGNvbnRlbnRUeXBlLiANCg0KICAgIENvbnZlbnRpb25zIHVzZWQg
aW4gdGhpcyBkb2N1bWVudCANCg0KICAgICAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBO
T1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgDQogICAgICAgIlNIT1VMRCIs
ICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRo
aXMgDQogICAgICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBp
biBSRkMtMjExOSBbS1dPUkRTXS4gDQoNCiAgICBUYWJsZSBvZiBDb250ZW50cyANCg0KICAgICAg
ICANCiAgICAgICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4yIA0KICAgICAgIDIuIFN5bnRheCBmb3IgVGltZVN0YW1wZWREYXRh
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zIA0KICAgICAgIDMuIENvbXBsaWFu
Y2UgcmVxdWlyZW1lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40IA0K
ICAgICAgIDQuIFJlY29tbWFuZGVkIHByb2Nlc3NpbmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi41IA0KICAgICAgIDUuIFJlY29tbWVuZGVkIGZpbGUgZXh0ZW50aW9ucy4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KICAgICAgIDYuIFNlY3VyaXR5IENv
bnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KICAg
ICAgIDcuIElBTkEgQ29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLjYgDQogICAgICAgOC4gQWNrbm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNiANCiAgICAgICA5LiBSZWZlcmVuY2VzLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi43IA0KICAgICAgIEF1
dGhvcidzIEFkZHJlc3Nlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLjcgDQogICAgICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVudC4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICAgICAgRGlzY2xhaW1lciBvZiBWYWxpZGl0eS4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOCANCiAgICAgICAgDQogICAg
MS4gSW50cm9kdWN0aW9uIA0KDQogICAgICAgRGlnaXRhbCB0aW1lIHN0YW1waW5nIGhhcyBiZWNv
bWUgdGhlIHN0YW5kYXJkIHRlY2huaXF1ZSBmb3IgcHJvdmluZyANCiAgICAgICB0aGUgZXhpc3Rl
bmNlIG9mIGEgZG9jdW1lbnQgYmVmb3JlIGEgY2VydGFpbiBwb2ludCBpbiB0aW1lLiBTZXZlcmFs
IA0KICAgICAgIGRpZ2l0YWwgc2lnbmF0dXJlIGxlZ2lzbGF0aW9ucyBhcm91bmQgdGhlIHdvcmxk
IGVtYnJhY2UgdGhlIGNvbmNlcHQgDQogICAgICAgYW5kIHByb3ZpZGUgZm9yIHRpbWUtc3RhbXBp
bmcgc2VydmljZXMgYXMgYW4gYXBwcm92ZWQgbWVhbnMgZm9yIA0KICAgICAgIGF0dGVzdGluZyB0
aGUgc2lnbmluZyB0aW1lIGFuZC9vciBmb3IgZXh0ZW5kaW5nIHRoZSB2YWxpZGl0eSBvZiANCiAg
ICAgICBzaWduZWQgZG9jdW1lbnRzIGJleW9uZCB0aGUgZXhwaXJ5IGRhdGUgb2YgdGhlIHNpZ25l
cpJzIGNlcnRpZmljYXRlLiAgDQoNCiAgICAgICBIb3dldmVyLCB3aGlsZSBkaWdpdGFsIHRpbWUg
c3RhbXBpbmcgZW5oYW5jZXMgZGlnaXRhbCBzaWduYXR1cmUsIGl0cyANCiAgICAgICB2YWx1ZSBk
b2VzIG5vdCBkZXBlbmQgb24gdGhpcyBsYXR0ZXIuIEl0IGNhbiBvYnZpb3VzbHkgYmUgdXNlZnVs
IHRvIA0KICAgICAgIHRpbWUtc3RhbXAgYSBkb2N1bWVudCBldmVuIGlmIHRoaXMgaXMgbm90IHNp
Z25lZC4gQW5kIGl0IGNhbiBhbHNvIGJlIA0KICAgICAgIHVzZWZ1bCwgb3IgZXZlbiBtYW5kYXRv
cnkgaW4gc29tZSBjYXNlcywgdG8gdGltZS1zdGFtcCBhIGRvY3VtZW50IGluIA0KICAgICAgIGl0
cyBlbnRpcmV0eSwgcmVnYXJkbGVzcyBvZiBob3cgbWFueSBzaWduYXR1cmVzIGl0IGNvbnRhaW5z
LiANCiAgICAgDQogICAgIA0KICAgIFNhbnRvbmkgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5
IDE5LCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0gDQogICAgICAgIA0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiAgICBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICB0
aW1lc3RhbXBlZGRhdGEgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3IA0KICAgICAgICANCg0K
ICAgICAgIFdoZW4gYSB0aW1lLXN0YW1wIGlzIHJlbGF0ZWQgdG8gYSBkaWdpdGFsIHNpZ25hdHVy
ZSwgdGhlcmUgYWxyZWFkeSANCiAgICAgICBleGlzdCBhIHdheSB0byBrZWVwIHRoZSB0d28gcGll
Y2VzIHRvZ2V0aGVyOiBbVFNQXSBkZXNjcmliZXMgaG93IG9uZSANCiAgICAgICBvciBtb3JlIFRp
bWVTdGFtcFRva2VucyBjYW4gYmUgaW5jbHVkZWQgaW4gYSBTaWduZXJJbmZvIHN0cnVjdHVyZSBh
cw0KICAgICAgIHVuc2lnbmVkIGF0dHJpYnV0ZXMuIE9uIHRoZSBvdGhlciBoYW5kLCB3aGVuIHRp
bWUtc3RhbXBzIGFyZSBub3QgDQogICAgICAgcmVsYXRlZCB0byBhIGRpZ2l0YWwgc2lnbmF0dXJl
LCB0aGVyZSBpcyBubyBzdGFuZGFyZCB3YXkgdG8ga2VlcCANCiAgICAgICB0b2dldGhlciB0aGUg
dGltZS1zdGFtcGVkIGRvY3VtZW50IGFuZCB0aGUgcmVsYXRlZCB0aW1lLXN0YW1wcy4gIA0KDQog
ICAgICAgSW4gc3VjaCBjYXNlcyB0d28gYXBwcm9hY2hlcyBhcmUgdHlwaWNhbGx5IGJlaW5nIGFk
b3B0ZWQ6IA0KDQogICAgICAgbyB0aW1lLXN0YW1wcyBhcmUga2VwdCBhcyBzZXBhcmF0ZSBmaWxl
cyAoa2VlcGluZyB0cmFjayBvZiB3aGF0IA0KICAgICAgICAgIHRpbWUtc3RhbXBzIGJlbG9uZyB0
byB3aGF0IGRvY3VtZW50cyBpcyB1cCB0byB0aGUgdXNlcik7IA0KDQogICAgICAgbyBhbiBhZCBo
b2Mgc29sdXRpb24gaXMgYWRvcHRlZCBmb3Igc3BlY2lmaWMgYXBwbGljYXRpb25zLCBsaWtlIGUu
Zy4gDQogICAgICAgICAgYSBaSVAgYXJjaGl2ZSBvciBhIHByb3ByaWV0YXJ5ICJlbnZlbG9wZSIg
b2Ygc29tZSBraW5kLiANCg0KICAgICAgIEJvdGggc29sdXRpb25zIGFyZSBvYnZpb3VzbHkgaW5h
ZGVxdWF0ZSB3aGVuIGludGVyb3BlcmFiaWxpdHkgaXMgDQogICAgICAgYWltZWQgYXQsIGxpa2Ug
aW4gdGhpcyBtZW1vLiANCg0KICAgICAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBzaW1wbGUg
c3ludGF4IGZvciBidW5kbGluZyBvbmUgZG9jdW1lbnQgDQogICAgICAgKGFjdHVhbGx5LCBhbnkg
a2luZCBvZiBmaWxlKSB0byB0aGUgY29ycmVzcG9uZGluZyB0ZW1wb3JhbCBldmlkZW5jZSwgDQog
ICAgICAgdGhpcyBsYXR0ZXIgYmVpbmcgdHlwaWNhbGx5IHJlcHJlc2VudGVkIGJ5IG9uZSBvciBt
b3JlIFJGQyAzMTYxIA0KICAgICAgIFRpbWVTdGFtcFRva2VucyBbVFNQXS4gQWRkaXRpb25hbCB0
eXBlcyBvZiB0ZW1wb3JhbCBldmlkZW5jZSwgbGlrZSANCiAgICAgICBlLmcuIGFuIFJGQyA0OTk4
IEV2aWRlbmNlUmVjb3JkLCBhcmUgYWxzbyBzdXBwb3J0ZWQgdmlhIGFuICJvcGVuIiANCiAgICAg
ICBzeW50YXguIEhvd2V2ZXIsIGZvciB0aGUgc2FrZSBvZiBpbnRlcm9wZXJhYmlsaXR5LCB0aGUg
ZW1waGFzaXMgaXMgDQogICAgICAgZ2l2ZW4gdG8gVGltZVN0YW1wVG9rZW5zLiANCg0KICAgICAg
IFRoZSBwcm9wb3NlZCBzeW50YXggaXMgYnJvYWRseSBiYXNlZCBvbiB0aGUgW0NNU10gc3ludGF4
LiANCg0KICAgIDIuIFN5bnRheCBmb3IgVGltZVN0YW1wZWREYXRhIA0KDQogICAgICAgVGhlIHBy
b3Bvc2VkIGRhdGEgc3RydWN0dXJlIGlzIGNhbGxlZCBUaW1lU3RhbXBlZERhdGEuIEl0IGlzIGEg
bmV3IA0KICAgICAgIHZhcmlhdGlvbiBvZiBDb250ZW50SW5mbyBbQ01TXSBtYXJrZWQgYnkgdGhl
IGZvbGxvd2luZyBzcGVjaWZpYyANCiAgICAgICBjb250ZW50VHlwZSBPSUQ6IA0KDQogICAgICAg
IA0KICAgICAgIGlkLXRpbWVzdGFtcGVkLWRhdGEgT0JKRUNUIElERU5USUZJRVIgOjo9IHsgaXNv
KDEpIG1lbWJlci1ib2R5KDIpIA0KICAgICAgIHVzKDg0MCkgcnNhZHNpKDExMzU0OSkgcGtjcygx
KSBwa2NzNyg3KSA3IH0gDQoNCiAgICAgICAgDQogICAgICAgVGhpcyBwYXJ0aWN1bGFyIE9JRCBz
aWduYWxzIHRoYXQgdGhlIGNvbnRlbnQgZmllbGQgb2YgdGhlIENvbnRlbnRJbmZvIA0KICAgICAg
IGhhcyB0aGUgZm9sbG93aW5nIHN5bnRheDogDQoNCiAgICAgICAgDQogICAgICAgVGltZVN0YW1w
ZWREYXRhIDo6PSBTRVFVRU5DRSB7IA0KICAgICAgICAgdmVyc2lvbiAgICAgSU5URUdFUiB7IHYx
KDEpIH0sIA0KICAgICAgICAgZmlsZU5hbWUgICAgIFVURjhTdHJpbmcsIA0KICAgICAgICAgbWlt
ZVR5cGUgICAgIFByaW50YWJsZVN0cmluZywgDQogICAgIA0KICAgICANCiAgICBTYW50b25pICAg
ICAgICAgICAgICAgICBFeHBpcmVzIE1heSAxOSwgMjAwOCAgICAgICAgICAgICAgICAgIFtQYWdl
IDNdIA0KICAgICAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICAgSW50
ZXJuZXQtRHJhZnQgICAgICAgICAgICAgdGltZXN0YW1wZWRkYXRhICAgICAgICAgICAgICAgTm92
ZW1iZXIgMjAwNyANCiAgICAgICAgDQoNCiAgICAgICAgIGNvbnRlbnQgICAgIE9DVEVUIFNUUklO
RywgDQogICAgICAgICBldmlkZW5jZSAgICAgRXZpZGVuY2UgDQogICAgICAgfSANCg0KICAgICAg
IEV2aWRlbmNlIDo6PSBDSE9JQ0UgeyANCiAgICAgICAgIHRpbWVTdGFtcHMgICAgIFswXSBTRVQg
KFNJWkUoMS4uTUFYKSkgT0YgVGltZVN0YW1wVG9rZW4gDQogICAgICAgICAtLSBhZGRpdGlvbmFs
IGV2aWRlbmNlIHR5cGVzIHRvIGJlIHJlZ2lzdGVyZWQgd2l0aCB0aGUgSUVURiANCiAgICAgICB9
IA0KDQogICAgICAgIA0KICAgICAgIFRoZSB2ZXJzaW9uIGZpZWxkIGNvbnRhaW5zIHRoZSB2ZXJz
aW9uIG51bWJlciBvZiB0aGUgVGltZVN0YW1wZWREYXRhIA0KICAgICAgIHN5bnRheC4gVGhlIGlu
aXRpYWwgdmVyc2lvbiBudW1iZXIgaXMgMS4gDQoNCiAgICAgICBUaGUgZmlsZU5hbWUgZmllbGQg
Y29udGFpbnMgdGhlIG9yaWdpbmFsIGZpbGVuYW1lICh3aXRob3V0IHBhdGgpIG9mIA0KICAgICAg
IHRoZSBkb2N1bWVudCB3aGljaCB3YXMgdGltZS1zdGFtcGVkIGFuZCB3aG9zZSBjb250ZW50IHdh
cyBpbnNlcnRlZCANCiAgICAgICBpbnRvIHRoZSBUaW1lU3RhbXBlZERhdGEgc3RydWN0dXJlLiAN
Cg0KICAgICAgIFRoZSBtaW1lVHlwZSBmaWVsZCBjb250YWlucyBhIE1JTUUgdHlwZSAoYWNjb3Jk
aW5nIHRvIFtNSU1FXSkgZm9yIHRoZSANCiAgICAgICBidW5kbGVkIGZpbGUuIEl0IGlzIGFuIGFk
dmlzb3J5IGluZm9ybWF0aW9uIHdoaWNoIG1heSBoZWxwIGRlY2lkZSBob3cgDQogICAgICAgdG8g
b3BlbiB0aGUgZmlsZSBhZnRlciBoYXZpbmcgImRldGFjaGVkIiBpdCBmcm9tIHRoZSBUaW1lU3Rh
bXBlZERhdGEgDQogICAgICAgc3RydWN0dXJlLCByZWdhcmRsZXNzIG9mIHRoZSBmaWxlbmFtZSBl
eHRlbnNpb24gKHdoaWNoIGNvdWxkIGJlIA0KICAgICAgIG1pc3Npbmcgb3IgdW5rbm93bikuIA0K
DQogICAgICAgVGhlIGNvbnRlbnQgZmllbGQgY2FycmllcyB0aGUgZW50aXJlIGNvbnRlbnQsIGlu
IGl0cyBvcmlnaW5hbCBmb3JtYXQsIA0KICAgICAgIG9mIHRoZSBmaWxlIHdoaWNoIHdhcyB0aW1l
LXN0YW1wZWQuIFRoZSBmaWxlIG5lZWQgbm90IGJlIGEgZG9jdW1lbnQgDQogICAgICAgaW4gdGhl
IHN0cmljdCBzZW5zZTsgaXQgY2FuIGJlIGFueSBraW5kIG9mIGZpbGUgKGUuZy4gYW4gZXhlY3V0
YWJsZSwgDQogICAgICAgYSBkYXRhYmFzZSwgZXRjKS4gDQoNCiAgICAgICBUaGUgZXZpZGVuY2Ug
ZmllbGQgY2FycmllcyB0aGUgZXZpZGVuY2UgdGhhdCB0aGUgY29udGVudCBkYXRhIGV4aXN0ZWQg
DQogICAgICAgYmVmb3JlIGEgY2VydGFpbiBwb2ludCBpbiB0aW1lLiBEaWZmZXJlbnQgdHlwZXMg
b2YgZXZpZGVuY2UgY2FuIGJlIA0KICAgICAgIHVzZWQsIGluIHRoZW9yeSwgYnV0IHRoaXMgZG9j
dW1lbnQgZGVmaW5lcyBhbmQgbWFuZGF0ZXMgc3VwcG9ydCBmb3IgDQogICAgICAgb25lIHNwZWNp
ZmljIHR5cGU6IGEgbm9uLWVtcHkgc2V0IG9mIFJGQyAzMTYxIFRpbWVTdGFtcFRva2VuJ3MgW1RT
UF0uIA0KDQogICAgICAgQWRkaXRpb25hbCB0eXBlcyBvZiBldmlkZW5jZSBtYXkgYmUgdXNlZCBh
ZnRlciBoYXZpbmcgcmVnaXN0ZXJlZCB0aGVtIA0KICAgICAgIChhbmQgaGF2aW5nIGhhZCBhIGRp
c3Rpbmd1aXNoaW5nIHRhZyBhc3NpZ25lZCB0byB0aGVtKSB3aXRoIHRoZSBJRVRGLiANCiAgICAg
ICBBIHN1aXRhYmxlIHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmUgd2lsbCBiZSBkZWZpbmVkIGZvciB0
aGF0IHB1cnBvc2UuIA0KDQogICAgMy4gQ29tcGxpYW5jZSByZXF1aXJlbWVudHMgDQoNCiAgICAg
ICBDb21wbGlhbnQgYXBwbGljYXRpb25zIE1VU1Qgc3VwcG9ydCB0aGUgUkZDIDMxNjEtYmFzZWQg
dHlwZSBvZiANCiAgICAgICBldmlkZW5jZSAoaS5lLiB0aGUgdGltZVN0YW1wcyBDSE9JQ0UpLiAN
Cg0KICAgICAgIENvbXBsaWFudCBhcHBsaWNhdGlvbnMgU0hBTEwgYWx3YXlzIHBvcHVsYXRlIHRo
ZSBmaWxlTmFtZSBmaWVsZCBvZiANCiAgICAgICBUaW1lU3RhbXBlZERhdGEgc3RydWN0dXJlIHdp
dGggYSBub24tZW1wdHkgc3RyaW5nLCB3aGljaCBpcyBzdXBwb3NlZCANCiAgICAgICB0byBiZSB0
aGUgcmVhbCBuYW1lIG9mIHRoZSB0aW1lLXN0YW1wZWQgZmlsZS4gUGF0aCBpbmZvcm1hdGlvbiBN
VVNUIA0KICAgICAgIE5PVCBiZSBpbmNsdWRlZC4gQSB2YWxpZCBleGFtcGxlIGlzICJwYXRlbnQx
MjMuZG9jIi4gQW4gaW52YWxpZCANCiAgICAgICBleGFtcGxlIGlzICJjOlxEb2N1bWVudHMgYW5k
IHNldHRpbmdzXEpvaG5cRGVza3RvcFxwYXRlbnQxMjMuZG9jIi4gDQogICAgIA0KICAgICANCiAg
ICBTYW50b25pICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAxOSwgMjAwOCAgICAgICAgICAg
ICAgICAgIFtQYWdlIDRdIA0KICAgICAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQogICAgSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgdGltZXN0YW1wZWRkYXRhICAgICAg
ICAgICAgICAgTm92ZW1iZXIgMjAwNyANCiAgICAgICAgDQoNCiAgICAgICBDb21wbGlhbnQgYXBw
bGljYXRpb25zIFNIQUxMIGFsd2F5cyBwb3B1bGF0ZSB0aGUgbWltZVR5cGUgZmllbGQgb2YgDQog
ICAgICAgVGltZVN0YW1wZWREYXRhIHN0cnVjdHVyZSB3aXRoIGEgdmFsaWQgTUlNRSBjb250ZW50
LXR5cGUgc3RyaW5nLiBBIA0KICAgICAgIHZhbGlkIGV4YW1wbGUgaXMgImFwcGxpY2F0aW9uL3Bk
ZiIuIEFuIGludmFsaWQgZXhhbXBsZSBpcyAid2hhdGV2ZXIiLiANCg0KICAgIDQuIFJlY29tbWFu
ZGVkIHByb2Nlc3NpbmcgDQoNCiAgICAgICBXaGVuIGdlbmVyYXRpbmcgdGhlIFRpbWVTdGFtcGVk
RGF0YSBzdHJ1Y3R1cmUsIGFwcGxpY2F0aW9ucyBhcmUgDQogICAgICAgc3VwcG9zZWQgdG8gYmVo
YXZlIGxpa2UgZm9sbG93czogDQoNCiAgICAgICBvIHBvcHVsYXRlIHRoZSB2ZXJzaW9uIGZpZWxk
IHdpdGggdGhlIGludGVnZXIgdmFsdWUgdjEoMSk7IA0KDQogICAgICAgbyBwb3B1bGF0ZSB0aGUg
ZmlsZU5hbWUgZmllbGQgd2l0aCB0aGUgcmVhbCBuYW1lIG9mIHRoZSBmaWxlLCANCiAgICAgICAg
ICB3aXRob3V0IHBhdGg7IA0KDQogICAgICAgbyBwb3B1bGF0ZSB0aGUgbWltZVR5cGUgZmllbGQg
d2l0aCBhbiBhcHByb3ByaWF0ZSBNSU1FIHR5cGUgc3RyaW5nLCANCiAgICAgICAgICBwcmVmZXJh
Ymx5LCBvciBhdCBsZWFzdCB3aXRoICJhcHBsaWNhdGlvbi9vY3RldC1zdHJlYW0iOyANCg0KICAg
ICAgIG8gcG9wdWxhdGUgdGhlIGNvbnRlbnQgZmllbGQgd2l0aCB0aGUgZW50aXJlIGNvbnRlbnRz
IG9mIHRoZSBmaWxlOyANCg0KICAgICAgIG8gYWRkIHRoZSBuZWNlc3NhcnkgZXZpZGVuY2UgKGUu
Zy4gb25lIG9yIG1vcmUgVGltZVN0YW1wVG9rZW5zKTsgDQoNCiAgICAgICBvIGluc2VydCB0aGUg
VGltZVN0YW1wZWREYXRhIGludG8gYSBDb250ZW50SW5mbyBzdHJ1Y3R1cmUsIHdpdGggdGhlIA0K
ICAgICAgICAgIGlkLXRpbWVzdGFtcGVkLWRhdGEgT0lEIGluIHRoZSBjb250ZW50VHlwZSBmaWVs
ZDsgDQoNCiAgICAgICBvIEJFUi1lbmNvZGUgdGhlIENvbnRlbnRJbmZvIHN0cnVjdHVyZSBhbmQg
c2F2ZSBpdCB3aXRoIHRoZSBzYW1lIA0KICAgICAgICAgIG5hbWUgb2YgdGhlIHRpbWUtc3RhbXBl
ZCBmaWxlLCBidXQgd2l0aCB0aGUgZmlsZSBleHRlbnNpb24gDQogICAgICAgICAgcmVjb21tZW5k
ZWQgaW4gc2VjdGlvbiA1LiANCg0KICAgICAgIFdoZW4gcGFyc2luZyBhbiBleGlzdGluZyBUaW1l
U3RhbXBlZERhdGEgc3RydWN0dXJlLCBhcHBsaWNhdGlvbnMgYXJlIA0KICAgICAgIHN1cHBvc2Vk
IHRvIGJlaGF2ZSBsaWtlIGZvbGxvd3M6IA0KDQogICAgICAgbyBjaGVjayB0aGF0IHRoZSBjb250
ZW50VHlwZSBmaWVsZCBvZiB0aGUgQ29udGVudEluZm8gc3RydWN0dXJlIGhhcyANCiAgICAgICAg
ICB0aGUgZXhwZWN0ZWQgdmFsdWUgKGlkLXRpbWVzdGFtcGVkLWRhdGEpIGluIGl0cyBjb250ZW50
VHlwZSBmaWVsZDsgDQogICAgICAgICAgdGhlbiwgZXh0cmFjdCB0aGUgaW5uZXIgVGltZVN0YW1w
ZWREYXRhIHN0cnVjdHVyZSBhbmQgY29udGludWUgDQogICAgICAgICAgcHJvY2Vzc2luZzsgDQoN
CiAgICAgICBvIGNoZWNrIHRoZSB2ZXJzaW9uIGZpZWxkIChpdCBzaG91bGQgYmUgdjEpOyANCg0K
ICAgICAgIG8gY2hlY2sgdGhlIGZpbGVOYW1lIGZpZWxkIChpdCBtdXN0IG5vdCBiZSBlbXB0eSkg
YW5kIGtlZXAgaXQgZm9yIA0KICAgICAgICAgIGxhdGVyIHVzZTsgDQoNCiAgICAgICBvIGNoZWNr
IHRoZSBtaW1lVHlwZSBmaWVsZCAoaXQgbXVzdCBub3QgYmUgZW1wdHkpIGFuZCBrZWVwIGl0IGZv
ciANCiAgICAgICAgICBsYXRlciB1c2U7IA0KDQogICAgICAgbyByZWFkIHRoZSBjb250ZW50IGZp
ZWxkIGFuZCBwcmVwYXJlIHRvIHNhdmUgaXQgaW4gYSBzZXBhcmF0ZSBmaWxlIA0KICAgICAgICAg
IGFuZC9vciBzaG93IGl0IHRvIHRoZSB1c2VyOyANCg0KICAgICANCiAgICAgDQogICAgU2FudG9u
aSAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMTksIDIwMDggICAgICAgICAgICAgICAgICBb
UGFnZSA1XSANCiAgICAgICAgDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KICAg
IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgIHRpbWVzdGFtcGVkZGF0YSAgICAgICAgICAgICAg
IE5vdmVtYmVyIDIwMDcgDQogICAgICAgIA0KDQogICAgICAgbyBjaGVjayB0aGF0IHRoZSBldmlk
ZW5jZSBmaWVsZCBub3QgYmUgZW1wdHk7IGV4dHJhY3QgdGhlIGlubmVyIGRhdGEgDQogICAgICAg
ICAgYW5kIHByZXBhcmUgdG8gc2hvdyB0aGVtIHRvIHRoZSB1c2VyIGFuZC9vciBzYXZlIHRoZW0g
dG8gc2VwYXJhdGUgDQogICAgICAgICAgZmlsZXM7IA0KDQogICAgICAgbyB2YWxpZGF0ZSB0aGUg
ZXZpZGVuY2UgZGF0YSAoZS5nLiBpbiBjYXNlIG9mIHRpbWVTdGFtcHM6IGNoZWNrIHRoYXQgDQog
ICAgICAgICAgZWFjaCBUaW1lU3RhbXBUb2tlbiBkb2VzIGluZGVlZCBjb250YWluIHRoZSBoYXNo
IG9mIHRoZSB0aW1lLQ0KICAgICAgICAgIHN0YW1wZWQgZG9jdW1lbnQgYW5kIGl0IHdhcyBzaWdu
ZWQgYnkgYSB0cnVzdGVkIFRTQSk7IA0KDQogICAgICAgbyBkZXBlbmRpbmcgb24gdGhlIGFwcGxp
Y2F0aW9uLCBzaG93IHRoZSBldmlkZW5jZSBkYXRhIHRvIHRoZSB1c2VyOyANCg0KICAgICAgIG8g
ZGVwZW5kaW5nIG9uIHRoZSBhcHBsaWNhdGlvbiwgc2hvdyB0aGUgdGltZS1zdGFtcGVkIGRvY3Vt
ZW50IHRvIA0KICAgICAgICAgIHRoZSB1c2VyLCBwb3NzaWJseSBieSBhY3RpdmF0aW5nIGEgc3Vp
dGFibGUgZXh0ZXJuYWwgInZpZXdlciI7IGlmIA0KICAgICAgICAgIHRoZSBmaWxlTmFtZSBleHRl
bnNpb24gaXMgbm90IHN1ZmZpY2llbnQgdG8gZmlndXJlIG91dCB0aGUgDQogICAgICAgICAgc3Vp
dGFibGUgdmlld2VyLCB0cnkgdXNpbmcgdGhlIG1pbWVUeXBlIGZpZWxkIGFzIGFuIGFkZGl0aW9u
YWwgDQogICAgICAgICAgaGludDsgDQoNCiAgICAgICBvIGRlcGVuZGluZyBvbiB0aGUgYXBwbGlj
YXRpb24sIHNhdmUgdGhlIGNvbnRlbnQgZmllbGQgaW50byBhIA0KICAgICAgICAgIHNlcGFyYXRl
IGZpbGUgd2l0aCB0aGUgbmFtZSBzcGVjaWZpZWQgYnkgdGhlIGZpbGVOYW1lIGZpZWxkIChvciAN
CiAgICAgICAgICBsZXQgdGhlIHVzZXIgc3BlY2lmeSB0aGUgZGVzaXJlZCBmaWxlbmFtZSkuIA0K
DQogICAgNS4gUmVjb21tZW5kZWQgZmlsZSBleHRlbnNpb25zIA0KDQogICAgICAgQSBmaWxlIGNv
bnRhaW5pbmcgYSBUaW1lU3RhbXBlZERhdGEgc3RydWN0dXJlIFNIT1VMRCBiZWFyIHRoZSAudHNk
IA0KICAgICAgIGV4dGVuc2lvbi4gRXhhbXBsZTogInBhdGVudDEyMy50c2QiIA0KDQogICAgNi4g
U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQoNCiAgICAgICBUaGVyZSBhcmUgbm8gc2VjdXJpdHkg
aXNzdWVzLiANCg0KICAgIDcuIElBTkEgQ29uc2lkZXJhdGlvbnMgDQoNCiAgICAgICBUaGlzIGRv
Y3VtZW50IGRlZmluZXMgb25lIG9iamVjdCBpZGVudGlmaWVyIHVuZGVyIHRoZSBwa2NzNyBhcmM6
IA0KDQogICAgICAgaWQtdGltZXN0YW1wZWQtZGF0YSBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBp
c28oMSkgbWVtYmVyLWJvZHkoMikgDQogICAgICAgdXMoODQwKSByc2Fkc2koMTEzNTQ5KSBwa2Nz
KDEpIHBrY3M3KDcpIDcgfSANCg0KICAgIDguIEFja25vd2xlZGdtZW50cyANCg0KICAgICAgIFRo
aXMgZG9jdW1lbnQgd2FzIHByZXBhcmVkIHVzaW5nIDItV29yZC12Mi4wLnRlbXBsYXRlLmRvdC4g
DQoNCg0KDQoNCg0KDQoNCiAgICAgDQogICAgIA0KICAgIFNhbnRvbmkgICAgICAgICAgICAgICAg
IEV4cGlyZXMgTWF5IDE5LCAyMDA4ICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0gDQogICAgICAg
IA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiAgICBJbnRlcm5ldC1EcmFmdCAg
ICAgICAgICAgICB0aW1lc3RhbXBlZGRhdGEgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDA3IA0K
ICAgICAgICANCg0KICAgIDkuIFJlZmVyZW5jZXMgDQoNCiAgICAgICBbS1dPUkRTXSAgQnJhZG5l
ciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIA0KICAgICAgICAg
ICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3
LiANCiAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjMjExOS50eHQg
DQoNCiAgICAgICBbVFNQXSAgICBBZGFtcywgQy4sIENhaW4sIFAuLCBQaW5rYXMsIEQuIGFuZCBS
LiBadWNjaGVyYXRvLCANCiAgICAgICAgICAgICAgICAgIkludGVybmV0IFguNTA5IFB1YmxpYyBL
ZXkgSW5mcmFzdHJ1Y3R1cmUgVGltZS1TdGFtcCANCiAgICAgICAgICAgICAgICAgUHJvdG9jb2wg
KFRTUCkiLCBSRkMgMzE2MSwgQXVndXN0IDIwMDEuIA0KICAgICAgICAgICAgICAgICBodHRwOi8v
d3d3LmlldGYub3JnL3JmYy9yZmMzMTYxLnR4dCANCg0KICAgICAgIFtDTVNdICAgIEhvdXNsZXks
IFIuLCAiQ3J5cHRvZ3JhcGhpYyBNZXNzYWdlIFN5bnRheCAoQ01TKSIsICANCiAgICAgICAgICAg
ICAgICAgUkZDIDM4NTIsIEp1bHkgMjAwNC4gDQogICAgICAgICAgICAgICAgIGh0dHA6Ly93d3cu
aWV0Zi5vcmcvcmZjL3JmYzM4NTIudHh0IA0KDQogICAgICAgW01JTUVdICAgQm9yZW5zdGVpbiwg
Ti4sIGFuZCBOLiBGcmVlZCwgIk11bHRpcHVycG9zZSBJbnRlcm5ldCBNYWlsIA0KICAgICAgICAg
ICAgICAgICBFeHRlbnNpb25zIChNSU1FKSBQYXJ0IE9uZTogRm9ybWF0IG9mIEludGVybmV0IE1l
c3NhZ2UgDQogICAgICAgICAgICAgICAgIEJvZGllcyIsIFJGQyAyMDQ1LCBOb3ZlbWJlciAxOTk2
LiANCiAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjMjA0NS50eHQg
DQoNCiAgICAgDQoNCiAgICBBdXRob3IncyBBZGRyZXNzZXMgDQoNCiAgICAgICBBZHJpYW5vIFNh
bnRvbmkgDQogICAgICAgQWN0YWxpcyBTLnAuQS4gDQogICAgICAgVmlhIFRhcmFtZWxsaSAyNiAN
CiAgICAgICBJLTIwMTI0IE1pbGFubyANCiAgICAgICAgICANCiAgICAgICBQaG9uZTogKzM5LTAy
LTY4ODI1LjEgDQogICAgICAgRW1haWw6IGFkcmlhbm8uc2FudG9uaUBhY3RhbGlzLml0IA0KICAg
ICAgICANCg0KICAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQgDQoNCiAgICAgICBU
aGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3Bl
IG9mIGFueSANCiAgICAgICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJp
Z2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8gDQogICAgICAgcGVydGFpbiB0byB0aGUgaW1w
bGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbiANCiAgICAg
ICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIg
c3VjaCByaWdodHMgDQogICAgICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9y
IGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzIA0KICAgICAgIG1hZGUgYW55IGluZGVwZW5k
ZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbiANCiAg
ICAgICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1
bWVudHMgY2FuIGJlIA0KICAgICAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5LiANCg0KICAg
ICAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlh
dCBhbmQgYW55IA0KICAgICAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFp
bGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4gDQogICAgICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFp
biBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mIA0KICAgICAN
CiAgICAgDQogICAgU2FudG9uaSAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMTksIDIwMDgg
ICAgICAgICAgICAgICAgICBbUGFnZSA3XSANCiAgICAgICAgDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KICAgIEludGVybmV0LURyYWZ0ICAgICAgICAgICAgIHRpbWVzdGFtcGVk
ZGF0YSAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDcgDQogICAgICAgIA0KDQogICAgICAgc3Vj
aCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMgDQog
ICAgICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5l
IElQUiByZXBvc2l0b3J5IGF0IA0KICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLiANCg0K
ICAgICAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8g
aXRzIGF0dGVudGlvbiBhbnkgDQogICAgICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQg
YXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeSANCiAgICAgICByaWdodHMgdGhhdCBt
YXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQgDQog
ICAgICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0
aGUgSUVURiBhdCANCiAgICAgICBpZXRmLWlwckBpZXRmLm9yZy4gDQoNCiAgICBEaXNjbGFpbWVy
IG9mIFZhbGlkaXR5IA0KDQogICAgICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9u
IGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuIA0KICAgICAgICJBUyBJUyIgYmFz
aXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5U
UyANCiAgICAgICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJ
RVRZLCBUSEUgSUVURiBUUlVTVCBBTkQgDQogICAgICAgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5H
IFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgDQogICAgICAgT1Ig
SU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBU
SEUgVVNFIE9GIA0KICAgICAgIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklO
R0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCANCiAgICAgICBXQVJSQU5USUVTIE9GIE1FUkNI
QU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gDQoNCiAgICBD
b3B5cmlnaHQgU3RhdGVtZW50IA0KDQogICAgICAgQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVz
dCAoMjAwNykuIA0KDQogICAgICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdo
dHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgDQogICAgICAgY29udGFpbmVkIGluIEJDUCA3
OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgDQogICAgICAg
cmV0YWluIGFsbCB0aGVpciByaWdodHMuIA0KDQogICAgQWNrbm93bGVkZ21lbnQgDQoNCiAgICAg
ICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlk
ZWQgYnkgdGhlIA0KICAgICAgIEludGVybmV0IFNvY2lldHkuIA0KDQogICAgICAgIA0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KICAgICANCiAgICAgDQogICAgU2FudG9uaSAgICAgICAgICAgICAg
ICAgRXhwaXJlcyBNYXkgMTksIDIwMDggICAgICAgICAgICAgICAgICBbUGFnZSA4XSANCiAgICAg
ICAgDQoNCg0KDQoNCg0KDQoNCg0K

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJ7K3L4045785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 00:20:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJ7K3EP045784; Mon, 19 Nov 2007 00:20:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJ7K2gW045778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 19 Nov 2007 00:20:02 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 95697328F4; Mon, 19 Nov 2007 07:20:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu0vJ-0004Bv-Gj; Mon, 19 Nov 2007 02:20:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-pkix-2797-bis-05.txt 
Message-Id: <[e-mail]>
Date: Mon, 19 Nov 2007 02:20:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:     <[e-mail]>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJ704WP044425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 00:00:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJ704Ao044423; Mon, 19 Nov 2007 00:00:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJ703AX044411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 19 Nov 2007 00:00:03 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 6999B175BF; Mon, 19 Nov 2007 07:00:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu0bx-0002oI-Tp; Mon, 19 Nov 2007 02:00:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-pkix-cmc-compl-04.txt 
Message-Id: <[e-mail]>
Date: Mon, 19 Nov 2007 02:00:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:     <[e-mail]>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJ704U7044424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 00:00:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAJ704AJ044422; Mon, 19 Nov 2007 00:00:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAJ702ih044410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 19 Nov 2007 00:00:03 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 2C3E3328F8; Mon, 19 Nov 2007 07:00:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu0by-0002pL-00; Mon, 19 Nov 2007 02:00:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-pkix-cmc-trans-06.txt 
Message-Id: <[e-mail]>
Date: Mon, 19 Nov 2007 02:00:02 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:     <[e-mail]>

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



Received: from muskoka.com ([218.75.149.218]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAI9DaJY063027; Sun, 18 Nov 2007 02:13:37 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 43376 invoked from network); Sun, 18 Nov 2007 17:27:50 +0800
Received: from unknown (HELO S47) ([e-mail]@83.28.182.235) by da954bdamuskoka.com with SMTP; Sun, 18 Nov 2007 17:27:50 +0800
Message-ID: <001a01c82a08$57fd1d50$0160e494@S47>
From: "Jamar E. Gold" <[e-mail]>
To: [e-mail]
Subject: by do daytime
Date: Sun, 18 Nov 2007 17:27:50 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C82A08.57FD1D50"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.2969
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.0000

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



Received: from host224.200-82-118.telecom.net.ar (host224.200-82-118.telecom.net.ar [200.82.118.224]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAHIZ1Ee017627 for <[e-mail]>; Sat, 17 Nov 2007 11:35:07 -0700 (MST) (envelope-from [e-mail])
Received: from Mariela by selfdefence.co.za with ASMTP id 37481EC7 for <[e-mail]>; Sat, 17 Nov 2007 15:35:21 -0300
Received: from Mariela ([184.179.152.29]) by selfdefence.co.za with ESMTP id FC1BC3979ECB for <[e-mail]>; Sat, 17 Nov 2007 15:35:21 -0300
Message-ID: <000b01c82948$9359a910$e07652c8@Mariela>
From: "gareth Golden" <[e-mail]>
To: <[e-mail]>
Subject: naaldbom
Date: Sat, 17 Nov 2007 15:35:06 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C8292F.6E0C7110"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAHEMZWK095400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Nov 2007 07:22:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAHEMZck095399; Sat, 17 Nov 2007 07:22:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAHEMYjY095392 for <[e-mail]>; Sat, 17 Nov 2007 07:22:34 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id B445033C21; Sat, 17 Nov 2007 06:17:38 -0800 (PST)
Date: Sat, 17 Nov 2007 06:17:38 -0800
From: Eric Rescorla <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] DSA/SHA-1, and OIDs
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAGFRgST070092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Nov 2007 08:27:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAGFRgqm070091; Fri, 16 Nov 2007 08:27:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAGFRet1070082 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 16 Nov 2007 08:27:41 -0700 (MST) (envelope-from [e-mail])
Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.222.3; Fri, 16 Nov 2007 15:27:39 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 16 Nov 2007 15:27:39 +0000
From: Stefan Santesson <[e-mail]>
To: Eric Rescorla <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Fri, 16 Nov 2007 15:27:20 +0000
Subject: RE: [TLS] DSA/SHA-1, and OIDs
Thread-Topic: [TLS] DSA/SHA-1, and OIDs
Thread-Index: AcglYyixk89m+4dNQ8SjtdSWyP3DzwDAR28Q
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAGFRft0070086
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
> Sent: den 12 november 2007 20:11
> To: [e-mail]; [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tls



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAFNLcSx095400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2007 16:21:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAFNLcSp095399; Thu, 15 Nov 2007 16:21:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from host.eb2bcom.com (host.eb2bcom.com [72.232.34.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAFNLasO095391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 15 Nov 2007 16:21:37 -0700 (MST) (envelope-from [e-mail])
Received: from [202.164.192.219] (helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.68) (envelope-from <[e-mail]>) id 1Iso1f-0005zE-Ui; Fri, 16 Nov 2007 10:21:36 +1100
Message-ID: <[e-mail]>
Date: Fri, 16 Nov 2007 10:21:31 +1100
From: Steven Legg <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mike <[e-mail]>
CC: [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAFIePsY072216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2007 11:40:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAFIePjF072215; Thu, 15 Nov 2007 11:40:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAFIeLDP072203 for <[e-mail]>; Thu, 15 Nov 2007 11:40:24 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 23263 invoked by uid 0); 15 Nov 2007 18:40:16 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 15 Nov 2007 18:40:16 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 15 Nov 2007 13:40:18 -0500
To: Mike <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAFHIjWg063832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2007 10:18:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAFHIjsY063831; Thu, 15 Nov 2007 10:18:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAFHIg0U063813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 15 Nov 2007 10:18:44 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 59E7A100415A4; Thu, 15 Nov 2007 17:18:38 +0000 (GMT)
X-Virus-Scanned: amavisd-new at newbay.com
Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Uk+zHgKjsDc; Thu, 15 Nov 2007 17:18:35 +0000 (GMT)
Received: from [192.168.2.156] (unknown [192.168.2.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id B6FA41004072A; Thu, 15 Nov 2007 17:18:34 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Thu, 15 Nov 2007 17:18:35 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: "Kemp, David P." <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:owner-ietf-
>> [e-mail]] On Behalf Of Stephen Farrell
>> Sent: den 15 november 2007 00:53
>> To: Kemp, David P.
>> Cc: [e-mail]
>> 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.
> 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAFFuxL7056548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2007 08:56:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAFFuxpI056547; Thu, 15 Nov 2007 08:56:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAFFuvVq056541 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 15 Nov 2007 08:56:58 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Thu, 15 Nov 2007 15:56:56 +0000
Received: from EA-EXMSG-C320.europe.corp.microsoft.com ([65.53.221.77]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([2002:4135:d55c::4135:d55c]) with mapi; Thu, 15 Nov 2007 15:56:56 +0000
From: Stefan Santesson <[e-mail]>
To: Stephen Farrell <[e-mail]>, "Kemp, David P." <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Thu, 15 Nov 2007 15:56:45 +0000
Subject: RE: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Thread-Topic: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Thread-Index: AcgnId3f74D2bG6+RFS8/S8VdULVOQAfeiAA
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAFFuwVp056542
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Stephen Farrell
> Sent: den 15 november 2007 00:53
> To: Kemp, David P.
> Cc: [e-mail]
> 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.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAFFTtkq054584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Nov 2007 08:29:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAFFTt18054583; Thu, 15 Nov 2007 08:29:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sceptre.pobox.com (sceptre.pobox.com [207.106.133.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAFFTsBP054577 for <[e-mail]>; Thu, 15 Nov 2007 08:29:55 -0700 (MST) (envelope-from [e-mail])
Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 38AC62F9 for <[e-mail]>; Thu, 15 Nov 2007 10:30:16 -0500 (EST)
Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 08A2795F6E for <[e-mail]>; Thu, 15 Nov 2007 10:30:15 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 15 Nov 2007 07:31:48 -0800
From: Mike <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAF1HBKu093430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2007 18:17:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAF1HBj7093429; Wed, 14 Nov 2007 18:17:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from host.eb2bcom.com (host.eb2bcom.com [72.232.34.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAF1HAEl093422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 14 Nov 2007 18:17:10 -0700 (MST) (envelope-from [e-mail])
Received: from cust3803.vic01.dataco.com.au ([202.164.192.219] helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.68) (envelope-from <[e-mail]>) id 1IsTLx-0002HX-El; Thu, 15 Nov 2007 12:17:10 +1100
Message-ID: <[e-mail]>
Date: Thu, 15 Nov 2007 12:17:04 +1100
From: Steven Legg <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Kemp, David P." <[e-mail]>
CC: [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.eb2bcom.com
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - eb2bcom.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from AMarseille-157-1-94-230.w90-37.abo.wanadoo.fr (AMarseille-157-1-94-230.w90-37.abo.wanadoo.fr [90.37.101.230]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAF0T145090071 for <[e-mail]>; Wed, 14 Nov 2007 17:29:03 -0700 (MST) (envelope-from [e-mail])
Received: from ACER ([173.107.166.84]:1039 "EHLO ACER" smtp-auth: <none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>) by AMarseille-157-1-94-230.w90-37.abo.wanadoo.fr with ESMTP id S22YENHNTNERQULX (ORCPT <rfc822;[e-mail]>); Thu, 15 Nov 2007 01:29:31 +0100
Message-ID: <000401c8271e$85ab3030$e665255a@ACER>
From: "Arjan Mannonen" <[e-mail]>
To: [e-mail]
Subject: 1txen
Date: 	Thu, 15 Nov 2007 01:29:02 +0100
Message-ID: <000401c8271e$85ab3030$e665255a@ACER>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

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

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAENqvJP086904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2007 16:52:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAENqv4w086903; Wed, 14 Nov 2007 16:52:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay.imagine.ie (dns2.dns.imagine.ie [87.232.1.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAENqtEV086896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 14 Nov 2007 16:52:56 -0700 (MST) (envelope-from [e-mail])
Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id 7AFAF4358; Wed, 14 Nov 2007 23:52:54 +0000 (GMT)
Received: from [10.87.48.3] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id lAENqmO4009074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Nov 2007 23:52:50 GMT
Message-ID: <[e-mail]>
Date: Wed, 14 Nov 2007 23:52:43 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Kemp, David P." <[e-mail]>
CC: [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0508 (Score 0)
X-Spam-Score: 0.00 () [Hold at 8.00] 
X-Canit-Stats-ID: 17227992 - b0394f359410
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAEMWcID080651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2007 15:32:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAEMWcpx080650; Wed, 14 Nov 2007 15:32:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAEMWc4O080642 for <[e-mail]>; Wed, 14 Nov 2007 15:32:38 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id lAEMWZsb003046 for <[e-mail]>; Wed, 14 Nov 2007 17:32:35 -0500 (EST)
X-AuditID: 90333308-000029cc00000750-9d-473b778334f9
Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 17:32:35 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Nov 2007 17:32:35 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Date: Wed, 14 Nov 2007 17:32:34 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Thread-Index: Acgm9cdNS0VFARdvR3yqIqIafaR+iwAEc1fQ
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 14 Nov 2007 22:32:35.0208 (UTC) FILETIME=[40E8C080:01C8270E]
X-Brightmail-Tracker: AAAAAA==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAEMWc4O080645
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAEKo3XE071871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2007 13:50:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAEKo3LW071870; Wed, 14 Nov 2007 13:50:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAEKo0b0071853 for <[e-mail]>; Wed, 14 Nov 2007 13:50:03 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 20085 invoked by uid 0); 14 Nov 2007 20:49:54 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 14 Nov 2007 20:49:54 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 14 Nov 2007 15:49:41 -0500
To: Mike <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAEIsDhl057805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2007 11:54:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAEIsDag057804; Wed, 14 Nov 2007 11:54:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sceptre.pobox.com (sceptre.pobox.com [207.106.133.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAEIsBSI057795 for <[e-mail]>; Wed, 14 Nov 2007 11:54:12 -0700 (MST) (envelope-from [e-mail])
Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 221212F9 for <[e-mail]>; Wed, 14 Nov 2007 13:54:33 -0500 (EST)
Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id E330B959A6 for <[e-mail]>; Wed, 14 Nov 2007 13:54:32 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 14 Nov 2007 10:54:55 -0800
From: Mike <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAEIPFX6054708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2007 11:25:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAEIPFWV054706; Wed, 14 Nov 2007 11:25:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAEIPDju054696 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 14 Nov 2007 11:25:14 -0700 (MST) (envelope-from [e-mail])
Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Wed, 14 Nov 2007 18:25:12 +0000
Received: from EA-EXMSG-C320.europe.corp.microsoft.com ([65.53.221.77]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([2002:4135:d55c::4135:d55c]) with mapi; Wed, 14 Nov 2007 18:25:11 +0000
From: Stefan Santesson <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Wed, 14 Nov 2007 18:25:07 +0000
Subject: Preliminary agenda uploaded
Thread-Topic: Preliminary agenda uploaded
Thread-Index: Acgm668Hvs4KW7TNQ4qCTLVxj9fLhQ==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_E75F200AF1718F45B2024A88C3141A1D0647BDBD7AEAEXMSGC320eu_"
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from estacion8 (200-110-173-38.mediacommerce.com.co [200.110.173.38] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAEFJAJa033427; Wed, 14 Nov 2007 08:19:11 -0700 (MST) (envelope-from [e-mail])
Message-ID: dee001c826d2$49e82f40$6c01a8c0@estacion8
From: "BackgammonRoom" <[e-mail]>
To: <[e-mail]>
Subject: The best place to play Backgammon with 100$ bonus
Date: Wed, 14 Nov 2007 10:23:09 +0500
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lADH4gBj028458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Nov 2007 10:04:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lADH4gh3028457; Tue, 13 Nov 2007 10:04:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lADH4fl8028447 for <[e-mail]>; Tue, 13 Nov 2007 10:04:41 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id lADH4csI019035 for <[e-mail]>; Tue, 13 Nov 2007 12:04:38 -0500 (EST)
X-AuditID: 90333308-000029c000000750-95-4739d9263b37
Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 12:04:38 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Nov 2007 12:04:38 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Date: Tue, 13 Nov 2007 12:04:36 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Thread-Index: Acgk6+qnBwvvg0i+ToSZyoJy4+GGEwBJ+zlA
References: <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 13 Nov 2007 17:04:38.0258 (UTC) FILETIME=[461EB520:01C82617]
X-Brightmail-Tracker: AAAAAA==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lADH4fl8028452
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]]
On Behalf Of Peter Gutmann
Sent: Sunday, November 11, 2007 11:21 PM
To: [e-mail]
Cc: [e-mail]
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 <[e-mail]>
>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.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lADEHDcb011653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Nov 2007 07:17:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lADEHDHn011652; Tue, 13 Nov 2007 07:17:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lADEHAgH011641 for <[e-mail]>; Tue, 13 Nov 2007 07:17:12 -0700 (MST) (envelope-from [e-mail])
Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id lADEH76a018480; Tue, 13 Nov 2007 16:17:07 +0200 (IST)
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Yoav Nir <[e-mail]>
To: Peter Gutmann <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; boundary=Apple-Mail-11--239632127; micalg=sha1; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v912)
Subject: Re: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Date: Tue, 13 Nov 2007 16:16:56 +0200
References: <[e-mail]>
X-Mailer: Apple Mail (2.912)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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 <[e-mail]>
>> 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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw
ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz
N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p
ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3
WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd
MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77
BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp
n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH
bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50
LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9
MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC
ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC
AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl
cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo
MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0
aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE
pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J
8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n
ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4
oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww
CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN
BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0
HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO
rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa
BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTExMzE0
MTY1NlowIwYJKoZIhvcNAQkEMRYEFF2a7Rs+w3WRBBTbJg6EO4w/AuKMMIGFBgkrBgEEAYI3EAQx
eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu
MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn
yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQBOm5XUC8WP
CbcNxJgGYLhWiqAYvJpFtQQrh2KpqRJSnWCj7UayMhDI+eOHXMEYXhSornxS5asEAmS003suM8LM
YmOTBAi5zK4fESo883Lg3cOPlLB2ZurxwyoErEt4pu4iLYM4D4XU6Fv7y4hP3UbvsTXg0hogNDLL
gsk8BreQGvUK8mwXTTzZm9qU2XpyyG6XvrimRNZCg5HZGpMSGJEUSWCDZdBlfDqb6lzCGoWZMnFn
2hskDKTasKHFPU2/c33E/nEomZRMGaX9x0SXdRIrs+0L6jErfWiGYis+/QAadPdVvgKv+sIcA2zp
KtNNIc9/3xfCa8k5vp7JaXwa72x1AAAAAAAA

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



Received: from 27.Red-80-37-197.staticIP.rima-tde.net (27.Red-80-37-197.staticIP.rima-tde.net [80.37.197.27]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAD9iLGL087044 for <[e-mail]>; Tue, 13 Nov 2007 02:44:41 -0700 (MST) (envelope-from [e-mail])
Received: from SANKYODELL24 by nnewstar.com.cn with ASMTP id 51FA65E7 for <[e-mail]>; Tue, 13 Nov 2007 10:44:01 +0100
Received: from SANKYODELL24 ([177.118.131.13]) by nnewstar.com.cn with ESMTP id 40C9DE4BA567 for <[e-mail]>; Tue, 13 Nov 2007 10:44:01 +0100
Message-ID: <000801c825d9$ac493930$1bc52550@SANKYODELL24>
From: "Randi Bond" <[e-mail]>
To: <[e-mail]>
Subject: dett{v{n
Date: Tue, 13 Nov 2007 10:43:40 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C825E2.0E0DA130"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lACKaNEF032636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2007 13:36:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lACKaNRB032635; Mon, 12 Nov 2007 13:36:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.150] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lACKaM2Y032628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 12 Nov 2007 13:36:23 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240802c35e64dd8f30@[10.20.30.150]>
In-Reply-To: <[e-mail]>
References: <p0624083ac3592924cca5@[10.20.30.150]> <[e-mail]> <p06240807c35a734e379c@[10.20.30.150]> <[e-mail]>
Date: Mon, 12 Nov 2007 12:35:13 -0800
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lACJZ1LZ026008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2007 12:35:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lACJZ1It026007; Mon, 12 Nov 2007 12:35:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (news.meritdirect.com [209.213.211.195] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lACJZ06C026000 for <[e-mail]>; Mon, 12 Nov 2007 12:35:00 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 543C833C2B; Mon, 12 Nov 2007 11:11:15 -0800 (PST)
Date: Mon, 12 Nov 2007 11:11:14 -0800
From: Eric Rescorla <[e-mail]>
To: [e-mail], [e-mail]
Subject: DSA/SHA-1, and OIDs
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lACJHZjj024605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2007 12:17:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lACJHZQ1024604; Mon, 12 Nov 2007 12:17:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from delta.rtfm.com (news.meritdirect.com [209.213.211.195] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lACJHXBv024596 for <[e-mail]>; Mon, 12 Nov 2007 12:17:34 -0700 (MST) (envelope-from [e-mail])
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 1881733C3D; Mon, 12 Nov 2007 11:12:23 -0800 (PST)
Date: Mon, 12 Nov 2007 11:12:23 -0800
From: Eric Rescorla <[e-mail]>
To: [e-mail], [e-mail]
Subject: DSA/SHA-1, and OIDs
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAC4WO7l055710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2007 21:32:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAC4WO4W055709; Sun, 11 Nov 2007 21:32:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAC4WMkC055703 for <[e-mail]>; Sun, 11 Nov 2007 21:32:23 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2F85E1855B; Mon, 12 Nov 2007 17:32:22 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrZ2LMXcd8Li; Mon, 12 Nov 2007 17:32:21 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DDEBE185BC; Mon, 12 Nov 2007 17:32:20 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id B0EEBE080B5; Mon, 12 Nov 2007 17:32:18 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1IrQna-0004yD-Bh; Mon, 12 Nov 2007 17:21:22 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Cc: [e-mail]
Message-Id: <[e-mail]>
Date: Mon, 12 Nov 2007 17:21:22 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Stephen Farrell <[e-mail]>
>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 --

-----BEGIN PGP PUBLIC KEY BLOCK-----
mQGiBD3SS2sRBAD2+GyR36eyTqcAnjnK4bGO1TXZV3awn90I73T+WsiyDGUu8ReP
E3IcaFbO6SX2Y8bVZ6l+aYvctoRyETEhQMa+ZA8hCxGS0XoLKptn1i3gNC7MThzr
3WHTdT6x3T2bR3vkpmheiKwEHuzWDJcZn7FdyeQc5kNU33T4DK/zmRNFZwCg/6TI
DDQJpaLZfS+396OAFR3CiA8D+gO9hpp6bYwf6z0ZNzjLlQHbxTnBTj9qHoyerrvy
54rui8i25Qha6M8oL2QDY+yVeSz0p8Z4arTxHlBssp/Z0Hv3llRNlLdBCrUtnkas
oVPxCGoeu+8fT2ftBrfmJd+QOOqWZsmtMvRUSW3sauQtVNjRJ5HGy6w9faafZjGJ
mVsRA/0Y5nx+OSsYBzAGRI8xG+hW/BUpyUJro0EyKs2JCjHA880b61zk/6xVV4B9
TqSU1s+u8w5+b0EAOPus1L2pWV7b16SNAjaajcHs6wxcvd/uC0q2JPayTV+qFwgD
oPxAjlI1xG/bFoWYQwgQ0RmSUKa5OwgX0TFn4MrilIRlpXgnarQMbm9jQGFybmVz
LnNpiEsEEBECAAsFAj3SS2wECwMBAgAKCRBigg3uSAJ/fQSKAKDYi4RQ5Q9rV3z5
WzCzkPi279InkwCfRJlHWq4lMHMcvgioBOKWaozI3AuInAQTAQIABgUCPpUgOgAK
CRB7qiN1erJgzc6NA/kBbEFD1XLqnW7t1tKwEH7imTvdX87EHEiVA3PdfZscb8kd
DWbfrO7hcsvVfathsWsSEN7Gnkg8NdM4J6uyQzIWuiKXEI0FEyeeG/botouC+uva
xjO8T5ylCYg3qThi1UjagTGJARblL70qBDfBNI8iAOlDfy2wN0iPMl0ZR7LQlLkB
DQQ90kvhEAQA9us9kL++VfLgbXEVQzqQtoqu7ONeX2PrxBzzxl9dAP4kdoC/LTay
0JSfSoHBl/GkJo3m9yI965XTEpfsrPuOezLFdpUKfujj8r6E+V4Zy4IMJCia+g1w
qICqXcvf5E7AwHOWkp7WJnedqMDtP5qgnwGZ6n1CBD4uWVAngHPOcIcAAgID/12X
rlvZq0fq2nwTYea1oQxdiRrGzSpIgYYX5TZJujFNTxQ16b1bHsJvv7yuLtskCKaU
1TFvBRbuqPKTlq6obcxzcdycetGH50HcdNeG/o1gNIgoQ7P7BEOId1vufOhoICoQ
sX2WYtSdz8LdaZH9PGZGieL/bQ1t+JgKe3w1KDS/iD8DBRg90kvhYoIN7kgCf30R
AnwdAKCPt4LB9/5e2PLI50aPKJa/LoplcQCfbiHBebc39EcR/t4idGM5XIfRhBk=
=dg/R
-----END PGP PUBLIC KEY BLOCK-----



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAC42RYq054392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2007 21:02:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAC42Rag054391; Sun, 11 Nov 2007 21:02:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAC42Nna054372 for <[e-mail]>; Sun, 11 Nov 2007 21:02:26 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C122E4805AF; Mon, 12 Nov 2007 17:02:22 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnPJvno0cXHG; Mon, 12 Nov 2007 17:02:22 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 81B5A480597; Mon, 12 Nov 2007 17:02:21 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BB16919EC0B6; Mon, 12 Nov 2007 17:02:18 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1IrQNC-0003O6-8i; Mon, 12 Nov 2007 16:54:06 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 12 Nov 2007 16:54:06 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Farrell <[e-mail]>
>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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAC0dBFk045317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2007 17:39:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAC0dBSs045316; Sun, 11 Nov 2007 17:39:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAC0dAIb045309 for <[e-mail]>; Sun, 11 Nov 2007 17:39:10 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 80932 invoked from network); 12 Nov 2007 00:39:05 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.108.39.68 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 12 Nov 2007 00:39:05 -0000
X-YMail-OSG: kjoYsNUVM1lWaZ.dOE0h7CIzFxDOfh5NY5VE71Vin_XXKx4tkWXNcgYHMHcIVWXqLc49Ys5_yfpLuRm.pLNqhdR1NnQhgcz50EL6X_4uae0c77vnOEa6Q0YfD9zzXPiOUePtPvaCS8Sa3Ds-
From: "Turner, Sean P." <[e-mail]>
To: "'Stephen Farrell'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
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.
Message-ID: <001a01c824c3$f7961550$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcgkVGA1YUyM+hAMQCSYbDPqn5S+kwAbunMw
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Stephen Farrell
>Sent: Sunday, November 11, 2007 5:46 AM
>To: Peter Gutmann
>Cc: [e-mail]; [e-mail]; [e-mail]
>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.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lABAkMGC083238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2007 03:46:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lABAkMLQ083237; Sun, 11 Nov 2007 03:46:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lABAkKMP083219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sun, 11 Nov 2007 03:46:21 -0700 (MST) (envelope-from [e-mail])
Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id 98DFE41C1; Sun, 11 Nov 2007 10:46:19 +0000 (GMT)
Received: from [127.0.0.1] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id lABAkGKS000664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Nov 2007 10:46:17 GMT
Message-ID: <[e-mail]>
Date: Sun, 11 Nov 2007 10:46:23 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0)
X-Spam-Score: 0.00 () [Hold at 8.00] 
X-Canit-Stats-ID: 17105436 - 6f20666acf7c
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Ridiculous nonsense.

Stephen.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lABAghUe083056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2007 03:42:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lABAghr5083055; Sun, 11 Nov 2007 03:42:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from relay.imagine.ie (dns2.dns.imagine.ie [87.232.1.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lABAgfJv083039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sun, 11 Nov 2007 03:42:42 -0700 (MST) (envelope-from [e-mail])
Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id CB5B542B6; Sun, 11 Nov 2007 10:42:40 +0000 (GMT)
Received: from [127.0.0.1] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id lABAgZYS032626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Nov 2007 10:42:36 GMT
Message-ID: <[e-mail]>
Date: Sun, 11 Nov 2007 10:42:42 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Paul Hoffman <[e-mail]>
CC: Mike <[e-mail]>, [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
References: <p0624083ac3592924cca5@[10.20.30.150]> <[e-mail]> <p06240807c35a734e379c@[10.20.30.150]>
In-Reply-To: <p06240807c35a734e379c@[10.20.30.150]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0004 (Score 0)
X-Spam-Score: 0.00 () [Hold at 8.00] 
X-Canit-Stats-ID: 17105385 - 1d3ff8427c8e (trained as not-spam)
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAB9Fuce077434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2007 02:15:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAB9FuGN077433; Sun, 11 Nov 2007 02:15:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAB9Fta4077427 for <[e-mail]>; Sun, 11 Nov 2007 02:15:56 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B70799C367; Sun, 11 Nov 2007 22:15:54 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95CJQMMcoIzM; Sun, 11 Nov 2007 22:15:54 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F36FB9C380; Sun, 11 Nov 2007 22:15:53 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id DEF9819EC0B6; Sun, 11 Nov 2007 22:15:51 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1Ir8v1-0001J4-Pc; Sun, 11 Nov 2007 22:15:51 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sun, 11 Nov 2007 22:15:51 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike <[e-mail]> 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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAB9Erhd077350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2007 02:14:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAB9Er2I077349; Sun, 11 Nov 2007 02:14:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAB9Ej6d077328 for <[e-mail]>; Sun, 11 Nov 2007 02:14:50 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 53CD3183A3; Sun, 11 Nov 2007 22:14:45 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6dOtJ7HZKGd; Sun, 11 Nov 2007 22:14:44 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DA91F183A7; Sun, 11 Nov 2007 22:14:43 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6D02019EC0B6; Sun, 11 Nov 2007 22:14:37 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1Ir8tp-00017O-Ag; Sun, 11 Nov 2007 22:14:37 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
In-Reply-To: <p06240807c35a734e379c@[10.20.30.150]>
Message-Id: <[e-mail]>
Date: Sun, 11 Nov 2007 22:14:37 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman <[e-mail]> 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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAAJVbgL029449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Nov 2007 12:31:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAAJVbxC029448; Sat, 10 Nov 2007 12:31:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rune.pobox.com (rune.pobox.com [208.210.124.79]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAAJVZSo029431 for <[e-mail]>; Sat, 10 Nov 2007 12:31:36 -0700 (MST) (envelope-from [e-mail])
Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 539401583EB for <[e-mail]>; Sat, 10 Nov 2007 14:31:47 -0500 (EST)
Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 22A85157F7B for <[e-mail]>; Sat, 10 Nov 2007 14:31:46 -0500 (EST)
Message-ID: <[e-mail]>
Date: Sat, 10 Nov 2007 11:30:22 -0800
From: Mike <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
References: <p0624083ac3592924cca5@[10.20.30.150]> <[e-mail]> <p06240807c35a734e379c@[10.20.30.150]>
In-Reply-To: <p06240807c35a734e379c@[10.20.30.150]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from customer68-118-37.iplannetworks.net (customer68-118-37.iplannetworks.net [200.68.118.37] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAAHfS6H020682 for <[e-mail]>; Sat, 10 Nov 2007 10:42:01 -0700 (MST) (envelope-from [e-mail])
Received: from pc-0c83b8812310 ([128.158.41.47]:27062 "EHLO pc-0c83b8812310" smtp-auth: <none> TLS-CIPHER: <none> TLS-PEER-CN1: <none>) by customer68-118-37.iplannetworks.net with ESMTP id S22IKNJWPJSVXCZE (ORCPT <rfc822;[e-mail]>); Sat, 10 Nov 2007 14:42:23 -0300
Message-ID: <000501c823c0$fbc12010$257644c8@pc0c83b8812310>
From: "MUHAMMET Junger" <[e-mail]>
To: <[e-mail]>
Subject: ocerped
Date: Sat, 10 Nov 2007 14:41:54 -0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C823A7.D673E810"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA9MoF7r047444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2007 15:50:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA9MoF7G047443; Fri, 9 Nov 2007 15:50:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA9MoDsx047435 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Fri, 9 Nov 2007 15:50:14 -0700 (MST) (envelope-from [e-mail])
Received: from DF-GWY-14.exchange.corp.microsoft.com (157.54.96.140) by df-gwy-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server id 8.1.236.0; Fri, 9 Nov 2007 14:50:13 -0800
Received: from DF-MLT-01.exchange.corp.microsoft.com (157.54.63.150) by DF-GWY-14.exchange.corp.microsoft.com (157.54.96.140) with Microsoft SMTP Server (TLS) id 14.0.194.3; Fri, 9 Nov 2007 14:50:13 -0800
Received: from df-bulldog-msg.exchange.corp.microsoft.com ([157.54.52.157]) by DF-MLT-01.exchange.corp.microsoft.com ([157.54.63.150]) with mapi; Fri, 9 Nov 2007 14:50:13 -0800
From: Trevor Freeman <[e-mail]>
To: "Vijay K. Gurbani" <[e-mail]>, "[e-mail]" <[e-mail]>
CC: Scott Lawrence <[e-mail]>
Date: Fri, 9 Nov 2007 14:49:56 -0800
Subject: RE: sip-eku and sip-domain-certs drafts
Thread-Topic: sip-eku and sip-domain-certs drafts
Thread-Index: AQHIIjKV8xEwDxn17YbbdwZ0TOSMN4y1xaDg
Message-ID: <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lA9MoEsw047436
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:owner-ietf-
* [e-mail]] On Behalf Of Vijay K. Gurbani
* Sent: Thursday, November 08, 2007 9:38 AM
* To: [e-mail]
* 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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA9KdWe9038189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2007 13:39:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA9KdWRX038188; Fri, 9 Nov 2007 13:39:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.150] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA9KdAaE038080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2007 13:39:12 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240807c35a734e379c@[10.20.30.150]>
In-Reply-To: <[e-mail]>
References: <p0624083ac3592924cca5@[10.20.30.150]> <[e-mail]>
Date: Fri, 9 Nov 2007 12:39:01 -0800
To: Mike <[e-mail]>, [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA9J4wot031248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2007 12:04:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA9J4w38031247; Fri, 9 Nov 2007 12:04:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sceptre.pobox.com (sceptre.pobox.com [207.106.133.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA9J4r95031238 for <[e-mail]>; Fri, 9 Nov 2007 12:04:56 -0700 (MST) (envelope-from [e-mail])
Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 6EBDC2FC for <[e-mail]>; Fri,  9 Nov 2007 14:05:15 -0500 (EST)
Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 2A01D93A61 for <[e-mail]>; Fri,  9 Nov 2007 14:05:15 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 09 Nov 2007 11:04:07 -0800
From: Mike <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
References: <p0624083ac3592924cca5@[10.20.30.150]>
In-Reply-To: <p0624083ac3592924cca5@[10.20.30.150]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA9GJ0qK015465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2007 09:19:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA9GJ0nn015464; Fri, 9 Nov 2007 09:19:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from visa.com (portal4.visa.com [198.241.156.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA9GIwDe015456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 9 Nov 2007 09:18:59 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: RFC3647 Question
Date: Fri, 9 Nov 2007 08:18:36 -0800
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC3647 Question
Thread-Index: AcgiXdbzQjA4xxudRqGHtCi1Mr2+8AAjcOkg
References: <01ed01c82242$e13211c0$0301a8c0@Wylie> <[e-mail]> <[e-mail]>
From: "Terwilliger, Ann" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Scott Rea" <[e-mail]>, "Turner, Sean P." <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 09 Nov 2007 16:18:37.0759 (UTC) FILETIME=[2F14FCF0:01C822EC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lA9GJ0Dd015459
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]]
On Behalf Of Russ Housley
Sent: Thursday, November 08, 2007 2:11 PM
To: Scott Rea; Turner, Sean P.
Cc: [e-mail]
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
>
>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA92GeTe056300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 19:16:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA92GeZE056299; Thu, 8 Nov 2007 19:16:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lA92GaNu056284 for <[e-mail]>; Thu, 8 Nov 2007 19:16:39 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 35009 invoked from network); 9 Nov 2007 02:16:30 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.108.46.209 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 9 Nov 2007 02:16:30 -0000
X-YMail-OSG: yF9_ukEVM1nAvVnVXeOIggTO.hWzJNuyi5ULJrNT6fVzVDSe0av.InfXUS4dSTjwf5bPN3DswXm4PhMGv3SIpqDYBGFT_leGpQeoqsTKCcqeVxtKcIU-
From: "Turner, Sean P." <[e-mail]>
To: "'Paul Hoffman'" <[e-mail]>, <[e-mail]>
References: <p0624083ac3592924cca5@[10.20.30.150]>
Subject: RE: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Date: Thu, 8 Nov 2007 21:13:18 -0500
Organization: IECA, Inc.
Message-ID: <033e01c82276$182ff2e0$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgiT3+vlZpMfmNXQymt6uVliYG5/gAJn2xw
In-Reply-To: <p0624083ac3592924cca5@[10.20.30.150]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

spt 

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Paul Hoffman
>Sent: Thursday, November 08, 2007 4:00 PM
>To: [e-mail]
>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
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8MBWuq041696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 15:11:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8MBWZ4041695; Thu, 8 Nov 2007 15:11:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lA8MBVKt041689 for <[e-mail]>; Thu, 8 Nov 2007 15:11:31 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 11944 invoked by uid 0); 8 Nov 2007 22:11:23 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 8 Nov 2007 22:11:23 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 08 Nov 2007 17:11:28 -0500
To: Scott Rea <[e-mail]>, "Turner, Sean P." <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: RFC3647 Question
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <01ed01c82242$e13211c0$0301a8c0@Wylie> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8LWKDs039348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 14:32:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8LWKBw039347; Thu, 8 Nov 2007 14:32:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lA8LWI4N039339 for <[e-mail]>; Thu, 8 Nov 2007 14:32:19 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 10415 invoked from network); 8 Nov 2007 21:32:14 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.108.46.209 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 8 Nov 2007 21:32:14 -0000
X-YMail-OSG: Mbxtb0QVM1kCcvHf0bpLV9LNSAHuxNmo5HIAgu1PIcDphFExUEOVaHTiuCKHQAFXh92JfVpgUZCKuc4LSBzNOvZ2Xjv5fN375jP3HB5iC9IQGepHxOP_5NqebhURxClnXrp9gMDLm2jf7Q--
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
References: <01ed01c82242$e13211c0$0301a8c0@Wylie> <[e-mail]>
Subject: RE: RFC3647 Question
Date: Thu, 8 Nov 2007 16:29:01 -0500
Organization: IECA, Inc.
Message-ID: <022301c8224e$61d06560$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0224_01C82224.78FA5D60"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgiQuDVVtRsYNgvQmeMnD/s/4Ir1gACj5zgAAA1j6A=
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]] 
Sent: Thursday, November 08, 2007 4:22 PM
To: Turner, Sean P.; [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Turner, Sean P.
Sent: Thursday, November 08, 2007 3:07 PM
To: [e-mail]
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:[e-mail]] <BR><B>Sent:</B> Thursday, November 08, =
2007=20
  4:22 PM<BR><B>To:</B> Turner, Sean P.; =
[e-mail]<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
  [e-mail] [mailto:[e-mail]] =
<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
  [e-mail]<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--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8LLoA3038879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 14:21:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8LLokV038878; Thu, 8 Nov 2007 14:21:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8LLomj038871 for <[e-mail]>; Thu, 8 Nov 2007 14:21:50 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8224D.96052FD4"
Subject: RE: RFC3647 Question
Date: Thu, 8 Nov 2007 13:22:08 -0800
Message-ID: <[e-mail]>
In-Reply-To: <01ed01c82242$e13211c0$0301a8c0@Wylie>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC3647 Question
thread-index: AcgiQuDVVtRsYNgvQmeMnD/s/4Ir1gACj5zg
References: <01ed01c82242$e13211c0$0301a8c0@Wylie>
From: "Santosh Chokhani" <[e-mail]>
To: "Turner, Sean P." <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] [mailto:[e-mail]]
On Behalf Of Turner, Sean P.
Sent: Thursday, November 08, 2007 3:07 PM
To: [e-mail]
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'>
[e-mail] [mailto:[e-mail]] =
<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> [e-mail]<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--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8L0C3h037349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 14:00:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8L0CCX037348; Thu, 8 Nov 2007 14:00:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from [10.20.30.150] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8L09Vt037333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 8 Nov 2007 14:00:12 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624083ac3592924cca5@[10.20.30.150]>
Date: Thu, 8 Nov 2007 13:00:02 -0800
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8KsDK6036875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 13:54:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8KsDjn036874; Thu, 8 Nov 2007 13:54:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhub1.dartmouth.edu (mailhub1.dartmouth.edu [129.170.16.122]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8KsBvX036866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 8 Nov 2007 13:54:13 -0700 (MST) (envelope-from [e-mail])
Received: from [127.0.0.1] ([129.170.87.243]) (authenticated bits=0) by mailhub1.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id lA8Krb9k019711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Nov 2007 15:53:51 -0500
Message-ID: <[e-mail]>
Date: Thu, 08 Nov 2007 15:53:36 -0500
From: Scott Rea <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Turner, Sean P." <[e-mail]>
CC: [e-mail]
Subject: Re: RFC3647 Question
References: <01ed01c82242$e13211c0$0301a8c0@Wylie>
In-Reply-To: <01ed01c82242$e13211c0$0301a8c0@Wylie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8K9tPn033901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 13:09:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8K9taD033900; Thu, 8 Nov 2007 13:09:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lA8K9stO033890 for <[e-mail]>; Thu, 8 Nov 2007 13:09:54 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 84228 invoked from network); 8 Nov 2007 20:09:53 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.108.46.209 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 8 Nov 2007 20:09:53 -0000
X-YMail-OSG: yXwD3Y0VM1nCP3MYzExBLXzlDtW0IpKI8SXVWE6GzB9tn9q1
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
Subject: RFC3647 Question
Date: Thu, 8 Nov 2007 15:06:41 -0500
Organization: IECA, Inc.
Message-ID: <01ed01c82242$e13211c0$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EE_01C82218.F85C09C0"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcgiQuDVVtRsYNgvQmeMnD/s/4Ir1g==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8Hbuqp020362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2007 10:37:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8Hbut9020361; Thu, 8 Nov 2007 10:37:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8HbsLg020354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 8 Nov 2007 10:37:55 -0700 (MST) (envelope-from [e-mail])
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lA8HbkrO028473; Thu, 8 Nov 2007 11:37:46 -0600 (CST)
Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lA8Hbkj15889; Thu, 8 Nov 2007 11:37:46 -0600 (CST)
Message-ID: <[e-mail]>
Date: Thu, 08 Nov 2007 11:37:45 -0600
From: "Vijay K. Gurbani" <[e-mail]>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: [e-mail]
CC: Scott Lawrence <[e-mail]>
Subject: sip-eku and sip-domain-certs drafts
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA5AjRDG023546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2007 03:45:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA5AjRmX023545; Mon, 5 Nov 2007 03:45:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA5AjQRx023538 for <[e-mail]>; Mon, 5 Nov 2007 03:45:26 -0700 (MST) (envelope-from [e-mail])
Received: from morten (0x50a4450b.albnxx10.adsl-dhcp.tele.dk [80.164.69.11]) by pfepa.post.tele.dk (Postfix) with ESMTP id 63B0FFAC03F; Mon,  5 Nov 2007 11:45:13 +0100 (CET)
From: "Erik Andersen" <[e-mail]>
To: "PKIX" <[e-mail]>, "Directory list" <[e-mail]>, <[e-mail]>
Subject: RE: Free standards! Get your free standards here!
Date: Mon, 5 Nov 2007 11:46:14 +0100
Message-ID: <000901c81f99$1c21e5a0$0100a8c0@morten>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6822
In-Reply-To: <a06240803c354303c3d18@[192.168.0.4]>
Importance: Normal
Thread-Index: AcgfYid/FO0fWJf/SUWnazkF8BFslQANmGiw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [phone]
e-mail: [e-mail]
http://www.x500standard.com/
http://home20.inet.tele.dk/era/me
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA58b1Zs012459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2007 01:37:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA58b1BI012458; Mon, 5 Nov 2007 01:37:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA58b0wY012451 for <[e-mail]>; Mon, 5 Nov 2007 01:37:00 -0700 (MST) (envelope-from [e-mail])
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=J4MAzlZNJdenGtvPrFles1KWW4KIE/eGAdH0/m5eDSsd9F7jCu3Rfr6Wpp7jJ/Zu; h=Received:Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [151.118.178.5] (helo=[192.168.0.4]) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1IoxS7-0008ET-Ia; Mon, 05 Nov 2007 03:36:59 -0500
Mime-Version: 1.0
Message-Id: <a06240805c35480d01f93@[192.168.0.4]>
In-Reply-To: <[e-mail]>
References: <a06240803c354303c3d18@192.168.0.4> <[e-mail]>
Date: Mon, 5 Nov 2007 01:35:38 -0700
To: "ronnie sahlberg" <[e-mail]>, [e-mail]
From: Hoyt L Kesterson II <[e-mail]>
Subject: Re: Free standards! Get your free standards here!
Content-Type: text/plain; charset="us-ascii"
X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d478cd9d7aa2e6231870d6ca8b9c7f914e35ddc7f265eccadb89350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 151.118.178.5
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]> 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
>>
>>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA52pOxF080743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2007 19:51:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA52pO7E080742; Sun, 4 Nov 2007 19:51:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA52pNHe080736 for <[e-mail]>; Sun, 4 Nov 2007 19:51:23 -0700 (MST) (envelope-from [e-mail])
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=G9SIXd7+ygEzTnvehjXaC6T92oleLBKTztPWudrJc+BvYKP2pgQh9zQ2gxuWZROL; h=Received:Mime-Version:Message-Id:Date:To:From:Subject:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [151.118.178.5] (helo=[192.168.0.4]) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1Ios3e-0007us-BG; Sun, 04 Nov 2007 21:51:22 -0500
Mime-Version: 1.0
Message-Id: <a06240803c354303c3d18@[192.168.0.4]>
Date: Sun, 4 Nov 2007 19:51:02 -0700
To: Recipient List Suppressed:;
From: Hoyt L Kesterson II <[e-mail]>
Subject: Free standards! Get your free standards here!
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d478cd9d7aa2e62318706d8e6f02f6e6926966abd96fb4e16af2350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 151.118.178.5
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from [80.73.210.206] (bbdhome3-209-79.cwgsy.net [80.73.209.79] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA4KBjC5055015 for <[e-mail]>; Sun, 4 Nov 2007 13:11:49 -0700 (MST) (envelope-from [e-mail])
Received: from user-36063597dd ([127.151.96.116] helo=user-36063597dd) by [80.73.210.206] ( sendmail 8.13.3/8.13.1) with esmtpa id 1HZuYv-000ULG-Iz for [e-mail]; Sun, 4 Nov 2007 20:11:41 -0000
Message-ID: <000601c81f1e$d7dc7b50$ced24950@user36063597dd>
From: "Arrian Bobowski" <[e-mail]>
To: <[e-mail]>
Subject: hsiraebg
Date: Sun, 4 Nov 2007 20:11:11 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C81F1E.D7DC7B50"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028

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



Received: from 189-11-159-253.cpnet.com.br ([189.11.176.175]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA3HjZ3x045156 for <[e-mail]>; Sat, 3 Nov 2007 10:45:36 -0700 (MST) (envelope-from [e-mail])
Received: by 10.51.176.153 with SMTP id CeKuFhChATUVC; Sat, 3 Nov 2007 16:45:29 -0200 (GMT)
Received: by 192.168.158.83 with SMTP id jOURjEYcuGKiGj.9307358698296; Sat, 3 Nov 2007 16:45:27 -0200 (GMT)
Message-ID: <000e01c81e49$b1f839e0$fd9f0bbd@xp>
From: "Cass Grankvist" <[e-mail]>
To: <[e-mail]>
Subject: oovaerts
Date: Sat, 3 Nov 2007 16:45:24 -0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C81E38.EE6F69E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Antivirus: avast! (VPS 071103-0, 03/11/2007), Outbound message
X-Antivirus-Status: Clean

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