Subject: ***SPAM*** 63.303 (5) Love Is...

From: <[email-masked]>
Date: Fri, 1 Feb 2008 02:37:19 -0500

I Love Thee http://76.103.154.45/

From: "Dung atik" <[email-masked]>
To: [email-masked]
Subject: Carry yourself with confidence - get your new huge d1ck here
Date: Thu, 31 Jan 2008 18:21:17 -0500

----------=_NextPart_000_0004_01C86436.12425DD0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Want to make your p3nis long and thick? click here
----------=_NextPart_000_0004_01C86436.12425DD0
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.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.jeelisnab.com/">Want to make your p3nis long and =
thick?=20
click here</A></BODY></HTML>
----------=_NextPart_000_0004_01C86436.12425DD0--

Date: Thu, 31 Jan 2008 10:28:00 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
Sender: [email-masked]

At 10:15 AM -0500 1/31/08, IESG Secretary wrote:
>PKIX Work Plan
>
>PKIX will continue to track the evolution of ITU-T X.509 documents,
>and will maintain compatibility between these documents and IETF PKI
>standards, since the profiling of X.509 standards for use in the
>Internet remains an important topic for the working group.

Maybe add: "In other words, the PKIX WG will probably last forever 
because the ITU-T X.509 work will probably last forever." Yes, this 
is a bit sarcastic, but is essentially true. If the IETF wants to 
have permanent WGs, PKIX should be one of them for the reason given 
in this proposed charter text.

>PKIX will pursue new work items in the PKI arena if working group
>members express sufficient interest, and if approved by the cognizant
>Security Area director.

Maybe add: "In other words, the PKIX WG will probably last forever 
because the interest by many active individuals in extending and 
enhancing the use of PKIX formats and protocols will probably last 
forever." Yes, this is a bit sarcastic, but is essentially true. If 
the IETF wants to have permanent WGs, PKIX should be one of them for 
the reason given in this proposed charter text.

Editorial:

The term "standards track RFC" should probably be "standards-track 
RFC" (although RFC 2026 is not consistent on this). In the 
milestones, "PROPOSED" should not be all caps.

--Paul Hoffman, Director
--VPN Consortium

To: [email-masked]
Cc: Stephen Kent <[email-masked]>, Stefan Santesson <[email-masked]>, [email-masked]
From: IESG Secretary <[email-masked]>
Subject: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix) 
Reply-To: [email-masked]
Date: Thu, 31 Jan 2008 10:15:02 -0500
Sender: [email-masked]

A modified charter has been submitted for the Public-Key Infrastructure
(X.509) (pkix) working group in the Security Area of the IETF. The IESG
has not made any determination as yet.  The modified charter is provided
below for informational purposes only.  Please send your comments to the
IESG mailing list ([email-masked]) by February 4.

+++

Public-Key Infrastructure (X.509) (pkix)

Chair(s):

Stephen Kent <[email-masked]>
Stefan Santesson <[email-masked]>

Security Area Director(s):

Tim Polk <[email-masked]>
Sam Hartman <[email-masked]>

Security Area Advisor:

Tim Polk <[email-masked]>

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: subscribe (In Body)
Archive: http://www.imc.org/ietf-pkix

Description of Working Group:

The PKIX Working Group was established in the fall of 1995 with the 
goal of developing Internet standards to support X.509-based Public 
Key Infrastructures (PKIs). Initially PKIX pursued this goal by 
profiling X.509 standards developed by the CCITT (later the ITU-T). 
Later, PKIX initiated the development of standards that are not 
profiles of ITU-T work, but rather are independent initiatives 
designed to address X.509-based PKI needs in the Internet. Over time 
this latter category of work has become the major focus of PKIX work, 
i.e., most PKIX-generated RFCs are no longer profiles of ITU-T X.509 
documents.

PKIX has produced a number of standards track and informational RFCs. 
RFC 3280 (Certificate and CRL Profile), and RCF 3281 (Attribute 
Certificate Profile) are recent examples of standards track RFCs that 
profile ITU-T documents. RFC 2560 (Online Certificate Status 
Profile), RFC 3779 (IP Address and AS Number Extensions), and RFC 
3161 (Time Stamp Authority) are examples of standards track RFCs that 
are IETF-initiated. RFC 4055 (RSA) and RFC 3874 (SHA2) are examples 
of informational RFCs that describe how to use public key and hash 
algorithms in PKIs.

PKIX Work Plan

PKIX will continue to track the evolution of ITU-T X.509 documents, 
and will maintain compatibility between these documents and IETF PKI 
standards, since the profiling of X.509 standards for use in the 
Internet remains an important topic for the working group.

PKIX does not endorse the use of specific cryptographic algorithms 
with its protocols. However, PKIX does publish standards track RFCs 
that describe how to identify algorithms and represent associated 
parameters in these protocols, and how to use these algorithms with 
these protocols. We anticipate efforts in this arena will continue to 
be required over time.

PKIX will pursue new work items in the PKI arena if working group 
members express sufficient interest, and if approved by the cognizant 
Security Area director. For example, certificate validation under X. 
509 and PKIX standards calls for a relying party to use a trust 
anchor as the start of a certificate path. Neither X.509 nor extant 
PKIX standards define protocols for the management of trust anchors. 
Existing mechanisms for managing trust anchors, e.g., in browsers, 
are limited in functionality and non-standard. There is considerable 
interest in the PKI community to define a standard model for trust 
anchor management, and standard protocols to allow remote management. 
Thus a future work item for PKIX is the definition of such protocols 
and associated data models.

UPDATED PKIX Milestones

Feb 2008 Update to CMC approved as PROPOSED Standard
Mar 2008 RFC 3280bis approved as PROPOSED Standard
Mar 2008 ECC Algorithms approved as PROPOSED Standard
Mar 2008 TAM Problem Statement published as Informational
Jul 2008 TAM Protocols and Models published as PROPOSED Standard

From: "Caroline Cartwright" <[email-masked]>
To: <[email-masked]>
Subject: Luxurious costume replica watches at ...   
Date: Thu, 31 Jan 2008 08:03:21 +0400

Best Rolex replica watches at Replica Classics 

Rolex replica watch

Rolex replica watch

http://www.totedwig.com/

From: "MAL mcqueen" <[email-masked]>
To: [email-masked]
Subject: Doctors endorse this miracle pen1s enlargement formula, that has been proven to work in thousands of men worldwide
Date: Thu, 31 Jan 2008 07:13:24 -0000

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

Make her dreams come true when she sees that you now have a HUGE tool in =
your pants
----------=_NextPart_000_000C_01C863D8.C4FD00A0
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.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.usetesup.com/">Make her dreams come true when she =
sees that=20
you now have a HUGE tool in your pants</A></BODY></HTML>
----------=_NextPart_000_000C_01C863D8.C4FD00A0--

Date: Wed, 30 Jan 2008 17:47:25 +0100
From: Peter Sylvester <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

I fully agree, nice work anyway for looking up all the other RFCs.
> It does not make sense holding up 3280bis trying to address these=20
> issues when it is not even clear that there is consensus that the PKIX =

> certificate and CRL profile should be changed.
>
>

--=20
To verify the signature, see http://edelpki.edelweb.fr/=20
Cela vous permet de charger le certificat de l'autorit=E9;=20
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20

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

--------------ms000900050004040804080507--

Date: Wed, 30 Jan 2008 10:31:24 -0500
To: "David A. Cooper" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Cc: pkix <[email-masked]>
Sender: [email-masked]

David,

There is no consensus to change 3280bis, so yes, it should proceed 
towards publication as an RFC as is.

If consensus emerges on this topic in the future, I also agree that 
an addendum focusing exclusively on this issue would be the preferred 
solution.

Steve

Date: Wed, 30 Jan 2008 09:41:16 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Sender: [email-masked]

RFC 2818 is not the only issue.  As I noted in an earlier message 
(http://www.imc.org/ietf-pkix/mail-archive/msg03834.html), I was able to 
find 9 RFCs that mention the use of wildcard characters, eight of which 
specifically mention using a wildcard character in the dNSName field of 
subjectAltName.  Of these, only RFC 2818 was published before RFC 3280.

It would be nice if there were not a bunch of RFCs out there that were 
inconsistent with the PKIX certificate and CRL profile with respect to 
the inclusion of wildcard characters in the dNSName field of 
subjectAltName, but I think it is too late to address this in 3280bis.  
3280bis has already been approved by the IESG and should be published 
relatively soon, once Chris Newman's editorial comments have been 
addressed 
(https://datatracker.ietf.org/idtracker/draft-ietf-pkix-rfc3280bis/comment/76604).  
The use of wildcard characters in DNS names is clearly a controversial 
topic and so we cannot expect the issue to be resolved quickly.

I believe that if there is ever agreement that the PKIX certificate and 
CRL profile should be changed in this area, then it should be done as a 
separate document that is published as an update to 3280bis.  As I noted 
in my earlier email, even if it were agreed that wildcard characters 
should be allowed, most of the 9 RFCs that I quoted seem to be more 
restrictive than RFC 2818 in how wildcard characters may be used, so it 
would take time to agree on what the PKIX profile should say about the 
permitted uses of wildcard characters.  There would also be a need to 
resolve the name constraints question:

      Would a subjectAltName of *.example.com fall within the
      subtree of host.example.com? Would it depend on whether
      host.example.com was a permitted or excluded subtree?

It does not make sense holding up 3280bis trying to address these issues 
when it is not even clear that there is consensus that the PKIX 
certificate and CRL profile should be changed.

Dave

Stephen Kent wrote:
> At 1:48 PM +0100 1/29/08, Peter Sylvester wrote:
>>   maybe someone should update RFC 2818? It talks about the
>> subjectAltName. It deprecates common name but not wild cards.
>> or should there be a note in 3280bis that it updates 2818?
>>
>>
>>
>>   If a subjectAltName extension of type dNSName is present, that MUST
>>   be used as the identity. Otherwise, the (most specific) Common Name
>>   field in the Subject field of the certificate MUST be used. Although
>>   the use of the Common Name is existing practice, it is deprecated and
>>   Certification Authorities are encouraged to use the dNSName instead.
>>
>>   Matching is performed using the matching rules specified by
>>   [RFC2459].  If more than one identity of a given type is present in
>>   the certificate (e.g., more than one dNSName name, a match in any one
>>   of the set is considered acceptable.) Names may contain the wildcard
>>   character * which is considered to match any single domain name
>>   component or component fragment. E.g., *.a.com matches foo.a.com but
>>   not bar.foo.a.com. f*.com matches foo.com but not bar.com.
>
>
> RFC 2818 correctly noted that use of CN to hold a DNS name was 
> existing practice then, but that its use was deprecated going forward. 
> That RFC is now 7.5 years old.  2818 cites "matching rules" from RFC 
> 2459, but 2459 does not specify matching rules for DNS names augmented 
> with a wildcard. There is only one reference to wildcard characters in 
> 2459. The text says that the interpretation of such subject alt names 
> is not defined in 2459, and it even fails to say which SANs could make 
> use of wildcard characters. So, the reference to 2459 matching rules 
> in 2818 is ambiguous when a wildcard is present.
>
> RFC 3280, which superseded 2459, removed the reference to wildcard 
> characters in SANs, making it clear that they were no longer 
> acceptable.  3280 was published in 2002, 5.5 years ago.
>
> I agree that 2818 should be revised, given that the reference it makes 
> to the PKIX cert profile is now 2 revs (.5. years) out of date, and no 
> longer valid.
>
> Steve

From: "layachi reka" <[email-masked]>
To: [email-masked]
Subject: Small instruments are not a cause for concern - you will be amazed at the results
Date: Thu, 31 Jan 2008 01:52:15 -0800

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

Your worst fears are now over - your tool can be enlarged
----------=_NextPart_000_000E_01C863AB.E75A4770
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.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.raozleks.com/">Your worst fears are now over - =
your tool can=20
be enlarged</A></BODY></HTML>
----------=_NextPart_000_000E_01C863AB.E75A4770--

From: "Sabry B" <[email-masked]>
To: "ietf-pkix-archive" <[email-masked]>
Subject: Do u want to know me?
Date: Wed, 30 Jan 2008 05:47:13 +0200

Greetings to you!

I love to travel and I dream to visit many countries, but I need a partner, 
intelligent, handsome, self-confident.  I dream of romantic dinners in 
strange countries and of passionate nights.  I dream to lay on the beach 
under the hot sun and he would help me with the sun blocking cream.  I dream 
of visiting museums and historical places holding my beloved by the hand and 
take pictures of all those places.  And after each trip, returning home 
remember all happy moments together and watch the photos:
You can prove me that you are my man, I have a great hope that 
you are!  I am waiting for your thoughts at http://singelgals.info/?idAff=182 and so far 
wish you to have a wonderful day.

Good-bye

Sabry B

Date: Tue, 29 Jan 2008 17:21:12 -0500
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Cc: pkix <[email-masked]>
Sender: [email-masked]

At 1:48 PM +0100 1/29/08, Peter Sylvester wrote:
>   maybe someone should update RFC 2818? It talks about the
>subjectAltName. It deprecates common name but not wild cards.
>or should there be a note in 3280bis that it updates 2818?
>
>
>
>   If a subjectAltName extension of type dNSName is present, that MUST
>   be used as the identity. Otherwise, the (most specific) Common Name
>   field in the Subject field of the certificate MUST be used. Although
>   the use of the Common Name is existing practice, it is deprecated and
>   Certification Authorities are encouraged to use the dNSName instead.
>
>   Matching is performed using the matching rules specified by
>   [RFC2459].  If more than one identity of a given type is present in
>   the certificate (e.g., more than one dNSName name, a match in any one
>   of the set is considered acceptable.) Names may contain the wildcard
>   character * which is considered to match any single domain name
>   component or component fragment. E.g., *.a.com matches foo.a.com but
>   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

RFC 2818 correctly noted that use of CN to hold a DNS name was 
existing practice then, but that its use was deprecated going 
forward. That RFC is now 7.5 years old.  2818 cites "matching rules" 
from RFC 2459, but 2459 does not specify matching rules for DNS names 
augmented with a wildcard. There is only one reference to wildcard 
characters in 2459. The text says that the interpretation of such 
subject alt names is not defined in 2459, and it even fails to say 
which SANs could make use of wildcard characters. So, the reference 
to 2459 matching rules in 2818 is ambiguous when a wildcard is 
present.

RFC 3280, which superseded 2459, removed the reference to wildcard 
characters in SANs, making it clear that they were no longer 
acceptable.  3280 was published in 2002, 5.5 years ago.

I agree that 2818 should be revised, given that the reference it 
makes to the PKIX cert profile is now 2 revs (.5. years) out of date, 
and no longer valid.

Steve

Date: Tue, 29 Jan 2008 13:48:53 +0100
From: Peter Sylvester <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

maybe someone should update RFC 2818? It talks about the
subjectAltName. It deprecates common name but not wild cards. 

or should there be a note in 3280bis that it updates 2818?

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

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

--------------ms050304010206010306040302--

Content-class: urn:content-classes:message
Subject: Re: Certificate suspension
Date: Tue, 29 Jan 2008 08:55:59 +0100
From: "SCHEIBELHOFER Karl" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

We run a national health card project in Austria with 10 million cards issued [1](Mr. Merkle mentioned it), each with digital signature based on ECDSA (P-192) and X.509 public-key certificates. The employed PKI supports certificate suspension using the onHold reason code in the sense of "certificate revocation is under investigation - try later". There are CRLs and OCSP for revocation checking.
An external CA [2] provides additional qualified certificates for the cards based on the Austrian Signature Act ([3] and [4] §10 (7)), which also mandates this type of suspension.

An analysis showed that this really safes money because several thousand certificates/cards that were set onHold were re-activated and we did not have to issue a new card.

As far as I know, onHold is the only means in PKIX/X.509 for implementing certificate suspension. Deprecating this feature seems impossible to me as long as PKIX/X.509 does not offer an alternative option for implementing this requirement, and as we can see from various postings, we face this requirement frequently.

[1] English information about the e-card project: http://www.chipkarte.at/portal/index.html;jsessionid=C88A207E80EA852A1495B3E051C22D7F?ctrl:cmd=render&ctrl:window=ecardportal.channel_content.cmsWindow&p_menuid=52069&p_tabid=5
[2] A-Trust, http://www.a-trust.at/
[3] Austrian Signature Act, http://www.signatur.rtr.at/en/legal/sigg.html (German)
[4] Austrian Signature Ordinance, http://www.signatur.rtr.at/en/legal/sigv.html (German)

regards

  Karl Scheibelhofer

--
SVC
Sozialversicherungs-Chipkarten Betriebs- und Errichtungsges.m.b.H. - SVC A-1020 Wien, Raimundgasse 1
T: +43 50 124 714 - 4262
F: +43 50 124 714 - 3776
[email-masked]
www.svc.co.at

FN: 206187t, Handelsgericht Wien
DVR: 3000966
UID: ATU52613104

Date: Mon, 28 Jan 2008 23:40:43 -0700 (MST)
Content-Return: allowed 
To: <[email-masked]>
Subject: January 73% OFF
From: <[email-masked]>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html dir="ltr">
    <style>
<img id=EC_freeWelcomeCgif alt="" src="http://h.qazau.com/c.gif?RF=&amp;PI=44364&amp;DI=5707&amp;PS=94669" width=1 height=1>

    <table width=550 border=0 cellspacing=0 cellpadding=0 align=center>
      <tr>
        <td colspan=3 bgcolor="#CCCCCC"><img border=0 height=1 src="http://gfx2.nvbsn.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=550></td>
      </tr>
      <tr>
	    <td bgcolor="#CCCCCC" width=1><img border=0 height=1 src="http://gfx2.vkico.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=1></td>
        <td width=548 align=left valign=top>
    	
	    <table align=center cellpadding=0 cellspacing=0 width=548 bgcolor="#FFFFFF">
	      <tr valign=top>
		    <td>			
		    <table align=center border=0 cellpadding=0 cellspacing=0 width=548 bgcolor="#FFFFFF">	
		      <tr valign=top>
			    <td valign=top><table width="100%" border=0 cellspacing=0 cellpadding=0>
                  <tr>
                    <td valign=top><table width="100%" border=0 cellspacing=0 cellpadding=0>
                      <tr>
                        <td><img src="http://gfx1.lasul.com/mail/w2/ltr/welcomeletter/header-left-WL-Hotmail.jpg" width=339 height=111 alt=""></td>
                      </tr>
                      <tr>
                        <td><table width="100%" border=0 cellspacing=0 cellpadding=0>
                          <tr>
                            <td><img border=0 height=1 src="http://gfx2.gxkpw.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=16></td>
                            <td><font size=4 color="#0099ff">Hello and Welcome to Windows Live Hotmail<span style="font-size:10px;vertical-align:super">®</span><br>
                            </font>
						    <img border=0 height=5 src="http://gfx2.xaica.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=1><br>
						    <font color="#000000">
						    Congratulations! The next generation of MSN® Hotmail is in your hands - fast, simple, and safer than ever before.<br>•  Bookmark this link to login to your <a href="http://mail.oduhb.com" target="_blank">Windows Live Hotmail</a>
						    </font></td>
                          </tr>
                        </table></td>
                      </tr>
                    </table>
                      </td>
                    <td valign=top><img src="http://gfx1.cdwlb.com/mail/w2/ltr/welcomeletter/header-right.jpg" width=211 height=223></td>
                  </tr>
                </table></td>
		      </tr>
		      <tr valign=top>
		        <td colspan=3 bgcolor="#CCCCCC"><img border=0 height=1 src="http://gfx2.bpwaz.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=548></td> 
		      </tr>
		    </table>
            
		    <table align=center border=0 cellpadding=5 cellspacing=0 width="100%" bgcolor="#FFFFFF">
		      <tr valign=top>
			    <td width=180>
			    
			        <a href="http://mail.vghml.com/mail/options.aspx?subsection=25" target="_blank">
			    
			    <img src="http://gfx1.mkacq.com/mail/w2/ltr/welcomeletter/folder.jpg" width=180 height=130 border=0 alt="Import Your Contacts">
			    
			    </a>
			    
			    </td>
			    <td width=328>
			    
			        <a href="http://mail.hfluu.com/mail/options.aspx?subsection=25" style="text-decoration:none" target="_blank">
			    
			    <font size=4 color="#0099ff">
			    Easily import contacts
			    </font>
			    
			    </a>
			    
			    <br>
			    <img border=0 height=5 src="http://gfx2.ifmvd.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=1><br>
			    
			    <font color="#000000">Move contacts from Microsoft® Office Outlook® or Outlook Express to get started sending e-mail to the people you care about most. Simply go to the Contacts page of Windows Live Hotmail, click Options, and then select Import Contacts. Just like that, all your contacts are at your fingertips.
			    <img border=0 height=5 src="http://gfx2.mrnou.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=1><br>
			    
			    » <a href="http://mail.uljfg.com/mail/options.aspx?subsection=25" target="_blank">Import Your Contacts Now</a></font></td>
			    
			    </td>
		      </tr>
		    </table>
    		
		    <table align=center border=0 cellpadding=5 cellspacing=0 width="100%" bgcolor="#FFFFFF">				
		      <tr valign=top>
			    <td width=328>
			    
			        <a href="http://get.wgczo.com/mail/classic_features" style="text-decoration:none" target="_blank">
			    
			    <font size=4 color="#0099ff">
			    Your mail, your look
			    </font>
			    
			    </a>
			    </style>
<center>
<a href="http://www.eighthigh.com"><img src="http://www.eighthigh.com/1.gif">
<style>
			    <br>
			    <img border=0 height=5 src="http://gfx2.cifyw.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=1><br>
			    <font color="#000000">It's easy to create your own personal look with Windows Live Hotmail. From the Mail page, click Options.  The Options page offers you themes for your Windows Live Hotmail, links to easily set up other preferences, and an option to upgrade to the Full View of Windows Live Hotmail.<br>
			    <img border=0 height=5 src="http://gfx2.yilaa.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=1><br>
			    
			    » <a href="http://get.xeysm.com/mail/classic_features" target="_blank">Get the Details</a></font></td>
			    
			    <td width=180>
			    
			        <a href="http://get.ilutl.com/mail/classic_features" target="_blank">
			    
			    <img src="http://gfx2.mflwz.com/mail/w2/ltr/welcomeletter/palette.jpg" width=180 height=130 border=0 alt="Customize your Windows Live Hotmail">
			    
			    </a>
			    
			    </td>
		      </tr>
		    </table>
    		
		    <table align=center border=0 cellpadding=5 cellspacing=0 width="100%" bgcolor="#FFFFFF">
		      <tr valign=top>
			    <td width=180>
			    
			        <a href="http://get.jvmxu.com/mail/classic_features" target="_blank">
			    
			    <img src="http://gfx2.zgnmv.com/mail/w2/ltr/welcomeletter/mglass.jpg" width=180 height=130 border=0 alt="Wait, there's more">
			    
			    </a>
			    
			    </td>
			    <td width=328>
			    
			        <a href="http://get.pchec.com/mail/classic_features" style="text-decoration:none" target="_blank">
			    
			    <font size=4 color="#0099ff">
			    Wait, there's more
			    </font>
			    
			    </a>
			    
			    <br>
			    <img border=0 height=5 src="http://gfx2.siphq.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=1><br>
			    <font color="#000000">But we don't want to overload you with too much of a good thing - see more of what Windows Live Hotmail can do:<br>
			    <img border=0 height=5 src="http://gfx2.gxanu.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=1><br>
			    
			    » <a href="http://get.weakx.com/mail/classic_features" target="_blank">Learn more</a><br></font></td>
		        
		      </tr>
		    </table>
    	    
		    <table align=center border=0 cellpadding=5 cellspacing=0 width="100%" bgcolor="#FFFFFF">				
		      <tr valign=top>
			    <td>
			    <font color="#000000">Windows Live Hotmail. Fast, simple and safer than ever.<br>

Live is good.
</font><br>
			    </td>
		      </tr>
		    </table>
    	    
		    <table align=center border=0 cellpadding=5 cellspacing=0 width="100%" bgcolor="#FFFFFF">
		      <tr valign=top>
			    <td><font color="#000000">Sincerely,<br>The Windows Live Hotmail Team</font></td>		
		      </tr>			
		    </table>
	    </td>
      </tr>
      <tr>
        <td colspan=3 bgcolor="#CCCCCC"><img border=0 height=1 src="http://gfx2.avash.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=548></td>
      </tr>
    </table>

    <table align=center cellpadding=5 cellspacing=0 width="100%">
      <tr valign=top>
	    <td><font color="#999999">
	    You are receiving this message from Windows Live because you are a valued member. Microsoft respects your privacy. To learn more, please read our online <a href="http://go.microsoft.com/fwlink/?LinkId=74170" target="_blank">Privacy Statement</a>.<br>
	    <img border=0 height=5 src="http://gfx2.jihbj.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=1><br>
	    For more information or for general questions regarding your e-mail account, please visit <a href="http://help.ikdsa.com/help.aspx?project=MailClassic&amp;market=en-xx&amp;querytype=keyword&amp;query=qaf " target="_blank">Windows Live Hotmail Help</a>.<br>
        <img border=0 height=5 src="http://gfx2.qwdzc.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=1><br>
	    Microsoft Corporation, One Microsoft Way, Redmond, WA 98052-6399, USA
© 2007 Microsoft Corporation.  All rights reserved.<br>
	    <img border=0 height=5 src="http://gfx2.loyah.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=1><br></font></td>
	    </tr>
	     </table>
	     </td>
	     <td bgcolor="#CCCCCC" width=1><img border=0 height=1 src="http://gfx2.ofjll.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=1></td>
       </tr>
       <tr valign=top>
         <td colspan=3 bgcolor="#CCCCCC"><img border=0 height=1 src="http://gfx2.sifdu.com/mail/w2/ltr/welcomeletter/spacer.gif" alt="" width=550></td>
      </tr>
    </table>

        </div>
    </div>

          </div>
    
    </body>
</style>

From: "Turner, Sean P." <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-01.txt
Date: Fri, 25 Jan 2008 10:58:58 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Good catch. When I updated the key usage list I didn't remove the sentence.
I'll post an updated draft.

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Russ Housley
>Sent: Thursday, January 24, 2008 5:30 PM
>To: [email-masked]
>Subject: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-01.txt
>
>
>The second to last paragraph in Section 3 says:
>
>    If the EE certificate keyUsage extension asserts 
>keyAgreement then it
>    MAY assert either encipherOnly or decipherOnly.  However, this
>    specification RECOMMENDS that if cRLSign is present, then
>    keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.
>
>I think the second sentence does not seem to fit here.  I 
>think it should be deleted.
>
>Russ
>

Date: Mon, 28 Jan 2008 13:28:09 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

At 10:08 PM +0100 1/23/08, Anders Rundgren wrote:
>Certificates with wildcards are fairly widely used because they
>can save you both hassles and money.
>
>Issuer: https://www.godaddy.com/gdshop/ssl/ssl.asp?ci=8979  A major 
>issuer of SSL certs.
>
>That is, it does not matter what 3280bis says, this is de-facto standard
>and I doubt that Microsoft intends to remove support for this in MSIE.
>
>If an issuer creates a certificate for *.com it is a bad issuer while
>*.mycompany.com is ok.  Bad issuers don't have their roots
>deployed in browsers so I don't see what the problem is.  If
>you have bad issuers nothing really helps.
>
>Anders

Putting a DNS name into the CN attribute is bad behavior.  It was one 
thing for CAs to do this when there was no SAN that could represent a 
DNS name, but that has not been the case for years. Inserting an 
invalid DNS name construct, e.g., one with an asterisk, into that 
attribute is more egregious bad behavior.

The situation you describe seems to be:

	- a CA generates a cert that contains a CN value that looks 
like a DNS name, but is syntactically NOT a DNS name

	- a provider of browser software decides to ascribe semantics 
to this CN value.

	- the browser uses this interpretation to make a security 
relevant decision on behalf of the user, e.g., when validating a cert 
for a web site

	- the syntax and semantics adopted by the CA and enforced the 
browser vendor are not consistent with the standards that describe 
certs nor their interpretation by browsers as defined by the 
cognizant IETF WGs (i.e., PKIX & TLS).

Most folks would consider this a bad outcome, as it undermines 
interoperability as promoted through the use of open standards.

The fact that you view this sort of collusion between a CA and a 
browser vendor as a legitimate way to create a (de facto) standard 
suggests that maybe you ought not waste your time in non-de facto 
standards activities, e.g., PKIX.

Steve

From: "Turner, Sean P." <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-01.txt
Date: Fri, 25 Jan 2008 10:58:58 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Good catch. When I updated the key usage list I didn't remove the sentence.
I'll post an updated draft.

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Russ Housley
>Sent: Thursday, January 24, 2008 5:30 PM
>To: [email-masked]
>Subject: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-01.txt
>
>
>The second to last paragraph in Section 3 says:
>
>    If the EE certificate keyUsage extension asserts 
>keyAgreement then it
>    MAY assert either encipherOnly or decipherOnly.  However, this
>    specification RECOMMENDS that if cRLSign is present, then
>    keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.
>
>I think the second sentence does not seem to fit here.  I 
>think it should be deleted.
>
>Russ
>

From: "Turner, Sean P." <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-01.txt
Date: Fri, 25 Jan 2008 10:58:58 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Good catch. When I updated the key usage list I didn't remove the sentence.
I'll post an updated draft.

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Russ Housley
>Sent: Thursday, January 24, 2008 5:30 PM
>To: [email-masked]
>Subject: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-01.txt
>
>
>The second to last paragraph in Section 3 says:
>
>    If the EE certificate keyUsage extension asserts 
>keyAgreement then it
>    MAY assert either encipherOnly or decipherOnly.  However, this
>    specification RECOMMENDS that if cRLSign is present, then
>    keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.
>
>I think the second sentence does not seem to fit here.  I 
>think it should be deleted.
>
>Russ
>

Date: Fri, 25 Jan 2008 13:10:39 +0100
From: Peter Sylvester <[email-masked]>
To: Jim Schaad <[email-masked]>
Cc: "'David A. Cooper'" <[email-masked]>, [email-masked]
Subject: Re: rfc3280bis change requested
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Jim Schaad wrote:
> Peter,
>
> A couple of more comments.
>
> 1.  The XER encoding would most likely be placed in a Base64 encoding
> because of the OCTET STRING wrapper, so I don't know that there is any =
real
> advantange not be DER.
>  =20
My small sentence was grammatically false and also incomplete.

I think the real requirement is
- One must be able to create the DER encoding of the certficate.
- X509 specifies that extensions' content need to be DER encoded
  but I think what is meant is the same as in the previous point.

As you said in another mail. Without knowing the ASN.1 it
is impossible to create a DER encoding from any other encoding
both for the tbsCertficate and extension content. Since extension
are open types and a creator certainly does not know whether
a verifier knows an extension.

I think somewhere in the defining of SIGNED in X.5/6xx it is
said that one should use DER to transport such things.

What about:

  Each extension includes an OID and an ASN.1 structure.  When an
  extension appears in a certificate, the OID appears as the field
  extnID and the corresponding ASN.1 encoded structure is the value of
  the octet string extnValue.
  In order to be sure that a user of a certificate can correctly perform
  signature verification, an encoder MUST use a DER encoding of the
  extension content.

As a result of a the ping pong game of asn1 people defining
octetstring wrappers (CONTAINING constraints) allowing good
parsers to go into the contents, which is what the other camp
tried to avoid by not simply using ANY DEFINED BY, today
one would probably define

      extnValue  EXTENSION.&ExtnType({ExtensionSet}{@extnId}))

which, to keep compatibility would say:

>>
>>    Extension ::=3D SEQUENCE {
>>       extnId       EXTENSION.&id ({ExtensionSet}),
>>       critical       BOOLEAN DEFAULT FALSE,
>>       extnValue  OCTET STRING CONTAINING
>>                  EXTENSION.&ExtnType({ExtensionSet}{@extnId}))
>>    =20

--=20
To verify the signature, see http://edelpki.edelweb.fr/=20
Cela vous permet de charger le certificat de l'autorit=E9;=20
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20

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

--------------ms080701000403030005000102--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-pkix-rfc4055-update-00.txt 
Date: Mon, 28 Jan 2008 12:20:01 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : Update for RSAES-OAEP Algorithm Parameters
	Author(s)       : S. Turner, et al.
	Filename        : draft-ietf-pkix-rfc4055-update-00.txt
	Pages           : 6
	Date            : 2008-01-23

This document updates RFC 4055.  It updates the conventions for using 
the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding 
(RSAES-OAEP) key transport algorithm with the Public-Key Cryptography 
Standards (PKCS) #1 version 1.5 signature algorithm in the Internet 
X.509 Public Key Infrastructure (PKI).  Specifically, it updates the 
conventions for algorithm parameters in an X.509 certificate's 
subjectPublicKeyInfo field.

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

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

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

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

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

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

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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc4055-update-00.txt

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

Content-Type: text/plain
Content-ID:     <2008-01-28121853.I-D\@ietf.org>

--OtherAccess--

--NextPart--

From: "VIP Casino Club." <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Armchair Vegas
Date: Mon, 28 Jan 2008 13:25:30 -0200

Enjoy all the action of Las Vegas with 24 hour customer services,

great offers and promotions and reliable payments from your armchair with ClubVIP:

- Download and install our free software 
- Register your account 
- Purchase chips and get playing!

See you at the tables! 

http://www.steeprichcasino.net

Date: Mon, 28 Jan 2008 12:19:15 +1100
From: Stephen Wilson <[email-masked]>
Organization: Lockstep
To: [email-masked]
Subject: PKI in court [was: Certificate suspension]
Sender: [email-masked]

Eric Norman wrote:

> Since we're talking about court cases here, it's not obvious to me that
> the court would even care about whether certificates used for signing
> were valid at signing time.  The only things a court might care about
> is whether the signer had the *intent* to sign, or the signature was
> under duress, or something like that.
> 
> I have a suspicion, and hope, that these attempts to design "electronic
> justice" result in nothing more than discussions on mailing lists.

I don't know about hoping these discussions go nowhere ;-)

But I agree with the implication that 'designing electronic justice' is 
problematic.  In my view, too many of the PKI-in-court discussions seem 
to be devoid of context.  Famously, Jane Winn years ago lampooned the 
idea of forming contracts on line using digital signatures -- but I 
think she was looking at the special case (the very special case) of 
stranger-to-stranger business.

Certificate subjects tend not to use their keys in a vacuum; when they 
sign things, there is plenty of context apart from their certificate. To 
imagine that a court case might turn on the certificate and private key 
alone I think is utterly academic.

It is better to realise that certificates are always used as part of 
some defined scheme (we should heed the practical experience that all 
most if not all successful individual certificate programs are "closed" 
or vertical).  Certificates are not usually presented to Relying Parties 
by total strangers (and if they are, they should be ignored, just as we 
would tend to ignore an unexpected order sent to us by an unknown party 
on plain paper, even if it is signed by hand).  Instead certificates are 
generally used to automate transactions between parties that either 
already know each other, or else recognise one another's credentials and 
capacity to act in the transaction at hand.  There isn't a lot of 
"serious" use of certificates in vanilla e-mail applications.  Rather, 
"serious" certificates are used in the context of special purpose 
software (e.g. medical software applications, e-conveyancing, government 
forms, trade documentation etc.) or are embedded in dedicated systems 
like smartcards, e-passports, set-top boxes, and Skype.

In these sorts of contexts, I think that when disputes get as far as a 
court, they are usually concerned with much more prosaic matters, like 
product failures, product liability, user interface design, and contracts.

Cheers,

Stephen Wilson
www.lockstep.com.au.

Date: Sun, 27 Jan 2008 09:05:50 +0100
To: [email-masked]
From: "lamiaceo" <[email-masked]>
Subject: launa
Reply-To: [email-masked]

http://officialtostrut.com/
Gucci Prada Dsquared D&G & Other Top Fashion Designer Shoes and Boots Amazing DEALS HERE

From: Yoav Nir <[email-masked]>
To: [email-masked]
Subject: Re: Certificate suspension
Date: Sun, 27 Jan 2008 09:53:07 +0200
Sender: [email-masked]

On Jan 27, 2008, at 4:20 AM, Eric Norman wrote:
>
> On Jan 26, 2008, at 7:06 PM, Stephen Wilson wrote:
>
>> I could try to
>> deny making the payment, and to bolster my case, I could say to a  
>> judge
>> "Look Your Honour, there was no 'non-repudiation' in the transaction
>> technology, therefore I can repudiate it!".  Fat chance!!  So if the
>> absence of an NR bit will not help me win the case, the presence of  
>> an
>> NR bit cannot be defining of a legal position either.]
>>
> ...
>
>> makes it very difficult to take a signature created at some time in
>> the past and determine from CRLs and delta CRLs whether or not the
>> certificate was valid at that time.
>
> Since we're talking about court cases here, it's not obvious to me  
> that
> the court would even care about whether certificates used for signing
> were valid at signing time.  The only things a court might care about
> is whether the signer had the *intent* to sign, or the signature was
> under duress, or something like that.

I don't think you can prove duress, no matter how much cryptography or  
certificate policy you throw at it. The only claim that's relevant to  
certificates in court is a claim that "some other dude" signed this  
transaction. As long as I signed it, it makes no difference if the  
certificate is suspended, revoked, expired or in its "not before"  
period.

>
> I have a suspicion, and hope, that these attempts to design  
> "electronic
> justice" result in nothing more than discussions on mailing lists.

Eventually it can be hoped that signatures done with a certificate  
that was already revoked (and deployed in the CRL) should not be  
binding.
Same should go for certificates that were suspended at the time, and  
not subsequently re-enabled.

Date: Sat, 26 Jan 2008 20:20:20 -0600
From: Eric Norman <[email-masked]>
Subject: Re: Certificate suspension
To: [email-masked]
Sender: [email-masked]

On Jan 26, 2008, at 7:06 PM, Stephen Wilson wrote:

>  I could try to
> deny making the payment, and to bolster my case, I could say to a  
> judge
> "Look Your Honour, there was no 'non-repudiation' in the transaction
> technology, therefore I can repudiate it!".  Fat chance!!  So if the
> absence of an NR bit will not help me win the case, the presence of an
> NR bit cannot be defining of a legal position either.]
>
...

>  makes it very difficult to take a signature created at some time in
> the past and determine from CRLs and delta CRLs whether or not the
> certificate was valid at that time.

Since we're talking about court cases here, it's not obvious to me that
the court would even care about whether certificates used for signing
were valid at signing time.  The only things a court might care about
is whether the signer had the *intent* to sign, or the signature was
under duress, or something like that.

I have a suspicion, and hope, that these attempts to design "electronic
justice" result in nothing more than discussions on mailing lists.

Eric Norman

Date: Sun, 27 Jan 2008 12:06:17 +1100
From: Stephen Wilson <[email-masked]>
Organization: Lockstep
To: [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

Anders Rundgren wrote:
> Alfredo, The problem you are referring is relevant regardless if you
>  support certificate suspension or not since a valid *certificate*
> [emphasis added] may indeed be in the wrong hands ...

You mean private key I think, not certificate.

> ...  without the legitimate user knowing or having reported it.
> 
> Since the majority of signatures these days are performed in on-line
> scenarios, certificate suspension for signatures and authentication
> is essentially the same thing.

I disagree with the emphasis on on-line signing.  Even if it
were empirically true, a prevalence of on-line PKI applications is not
reflective of the unique value of PKI -- which is that signatures can be
verified off-line, and retrospectively -- and we should therefore NOT
bake into our standards and conventions any dependence on, or
presumption of, certificates being used on-line.

> Regarding legality the fact is that people are actually convicted 
> based on IP address associations and e-mail addresses.

I agree that we should not over-do "legality" since there are indeed all
sorts of ways to find someone legally liable (or not) for things that
happen electronically.

[BTW the richness of IT forensics is one reason I think that
"non-repudiation" is such a red herring and such an albatross around our
necks (pardon the mixed marine metaphor! And pardon the alliteration!!).

[If I create a digital signature using complex software as part of a
transaction, and there follows some sort of court case, I do not believe
that the outcome will depend much at all on whether the NR bit is
asserted.  A reductio ad absurdum helps underscore the futility of
"non-repudiation": Imagine I make a credit card payment over the
Internet, and then change my mind about the purchase.  I could try to
deny making the payment, and to bolster my case, I could say to a judge
"Look Your Honour, there was no 'non-repudiation' in the transaction
technology, therefore I can repudiate it!".  Fat chance!!  So if the
absence of an NR bit will not help me win the case, the presence of an
NR bit cannot be defining of a legal position either.]

> The difference between signatures and authentication is that only the
> latter cannot be revoked which is why authentication remains the 
> most critical operation regardless of its legal status.

I don't understand the idea that 'authentication cannot be revoked'.

> I wouldn't outlaw certificate suspension, it seems appropriate in an
>  on-line world.

If there is any case for a credential being suspended for a period of
time, with the expectation of it being un-suspended, then I say let's
suspend the key, and not worry about the certificate.

Looking at the off-line world of PKI, I remain won over by the argument
that the possibility of a certificate being suspended, and then
re-instated some time later (and then suspended again and reinstated
...) makes it very difficult to take a signature created at some time in
the past and determine from CRLs and delta CRLs whether or not the
certificate was valid at that time.

Another scenario advanced in favour of suspension is when the key owner
has misplaced their key but thinks it might still turn up.  But this
introduces too much wiggle room into Required Revocation.
Conventionally, most Certificate Policies insist that if one even
suspects possible private key compromise, revocation is required.  It
seems to me very difficult to characterise in a Policy any middle ground
that would allow a user some shade of doubt.  Tellingly, you cannot
"suspend" a credit card if it is misplaced (not in Australia at any
rate).  I misplaced a card once, and called my bank to have it put on
hold while I looked for it.  But the operator asked me "Is your card
lost, or is it not?".  There was no middle ground, I had to either
cancel the card, or wear the consequences of it being misused while not
under my control.

I cannot see why digital certificates would ever be any different.

Cheers,

Stephen Wilson.
www.lockstep.com.au.

Content-class: urn:content-classes:message
Subject: RE: Certificate suspension
Date: Sat, 26 Jan 2008 15:35:09 -0800
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I have been skim reading this thread for a while.

Please note that suspension does not get in the way of non-repudiation;
it simply increases software complexity on the part of relying parties
trying to sort out time of signature application.

Also, note that there are lots of other issues for preservation of
signatures for long term.  I encourage you to follow the developments of
the IETF LTANS WG for that.  Again, for the long term, with properly
archived revocation information, signature verification in the future
can be securely sorted out using LTANS developed RFCs and I-Ds whether
suspension is used or not.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Todd E. Johnson
Sent: Saturday, January 26, 2008 5:05 PM
To: Anders Rundgren
Cc: Alfredo Esposito; Bechlaghem, Malek; Denis Pinkas; [email-masked]
Subject: Re: Certificate suspension

Then there are those signatures which are kept long term, say, one that 
is used to initiate a financial instruction after proper validation, and

authorization, occurs.  The problem in this example is, the signature is

archived, and may require validation in the future due to an audit, 
litigation, etc.  This may be years depending on the application's 
business requirements, or law.

To be specific, my only issue with supporting suspension are with 
certificates which assert the nonRepudiation bit.

Otherwise, I understand the usefulness of having the ability to suspend 
certificates which assert only the digitalSignature bit.

These can be settled by policy in isolated implementations.  It becomes 
problematic when honoring credentials from other implementations which 
do not align with your policy.

Only subtle changes could be adopted, allowing for respect of the 
current law internationally (which some appear to require suspension) 
maintaining the technical ability to suspend, and the technical ability 
to not honor the credential by a digital signature centric business 
application if desired.

Anders Rundgren wrote:
> Alfredo,
> The problem you are referring is relevant regardless if you support
certificate suspension or not since a valid certificate may
> indeed be in the wrong hands without the legitimate user knowing or
having reported it.
> 
> Since the majority of signatures these days are performed in on-line
scenarios, certificate suspension for signatures and
> authentication is essentially the same thing.
> 
> Regarding legality the fact is that people are actually convicted
based on IP address associations and e-mail addresses.
> 
> The difference between signatures and authentication is that only the
latter cannot be revoked which is why authentication remains
> the most critical operation regardless of its legal status.
> 
> I wouldn't outlaw certificate suspension, it seems appropriate in an
on-line world.
> thanks
> Anders Rundgren

-- 

Regards,

Todd E. Johnson

Date: Sat, 26 Jan 2008 17:05:18 -0500
From: "Todd E. Johnson" <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: Alfredo Esposito <[email-masked]>, "Bechlaghem, Malek" <[email-masked]>, Denis Pinkas <[email-masked]>, [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

Then there are those signatures which are kept long term, say, one that 
is used to initiate a financial instruction after proper validation, and 
authorization, occurs.  The problem in this example is, the signature is 
archived, and may require validation in the future due to an audit, 
litigation, etc.  This may be years depending on the application's 
business requirements, or law.

To be specific, my only issue with supporting suspension are with 
certificates which assert the nonRepudiation bit.

Otherwise, I understand the usefulness of having the ability to suspend 
certificates which assert only the digitalSignature bit.

These can be settled by policy in isolated implementations.  It becomes 
problematic when honoring credentials from other implementations which 
do not align with your policy.

Only subtle changes could be adopted, allowing for respect of the 
current law internationally (which some appear to require suspension) 
maintaining the technical ability to suspend, and the technical ability 
to not honor the credential by a digital signature centric business 
application if desired.

Anders Rundgren wrote:
> Alfredo,
> The problem you are referring is relevant regardless if you support certificate suspension or not since a valid certificate may
> indeed be in the wrong hands without the legitimate user knowing or having reported it.
> 
> Since the majority of signatures these days are performed in on-line scenarios, certificate suspension for signatures and
> authentication is essentially the same thing.
> 
> Regarding legality the fact is that people are actually convicted based on IP address associations and e-mail addresses.
> 
> The difference between signatures and authentication is that only the latter cannot be revoked which is why authentication remains
> the most critical operation regardless of its legal status.
> 
> I wouldn't outlaw certificate suspension, it seems appropriate in an on-line world.
> 
> thanks
> Anders Rundgren
> 

-- 

Regards,

Todd E. Johnson

From: "Anders Rundgren" <[email-masked]>
To: "Alfredo Esposito" <[email-masked]>, "Bechlaghem, Malek" <[email-masked]>
Cc: "Todd E. Johnson" <[email-masked]>, "Denis Pinkas" <[email-masked]>, <[email-masked]>
Subject: Re: Certificate suspension
Date: Sat, 26 Jan 2008 21:34:15 +0100
Sender: [email-masked]

Alfredo,
The problem you are referring is relevant regardless if you support certificate suspension or not since a valid certificate may
indeed be in the wrong hands without the legitimate user knowing or having reported it.

Since the majority of signatures these days are performed in on-line scenarios, certificate suspension for signatures and
authentication is essentially the same thing.

Regarding legality the fact is that people are actually convicted based on IP address associations and e-mail addresses.

The difference between signatures and authentication is that only the latter cannot be revoked which is why authentication remains
the most critical operation regardless of its legal status.

I wouldn't outlaw certificate suspension, it seems appropriate in an on-line world.

thanks
Anders Rundgren

----- Original Message ----- 
From: Alfredo Esposito
To: Bechlaghem, Malek
Cc: Todd E. Johnson ; Denis Pinkas ; [email-masked]
Sent: Saturday, January 26, 2008 17:13
Subject: Re: Certificate suspension

The point is the usage of certificate. For authentication purposes, suspension is fine. If my certificate is suspended "now", "now"
I can not authenticate myself to, say, my workstation. If the purpose is non repudiation (digital signature has a handwritten
signature) the legal value of a document signed during the suspension period is not trivial to assess

Bechlaghem, Malek wrote:
Hello there,

While I do agree that the semantic of processing a digital signature is
difficult for a relying party when the signer certificate is suspended,
I would like to point out to at least one area where certificate
suspension does have a practical use.

Having been involved in few ID card issuing projects worldwide, my
experience from these is that eID card lifecycle processes tend to be
coupled to certificate lifecycle processes. In other terms, when an ID
card holder suspects that his card is lost or stolen, we call a helpdesk
that suspend his ID card for a defined period of time. This results in
the card certificates revoked with status on-hold (i.e. suspended). If
the guy founds his card, he calls the same helpdesk that will activate
his card back which results in his certificates un-suspended.

This is at least one practical use of using certificate
suspension-unsuspension. As for the relying-party application, it shall
be developed according so that it interprets the certificate on-hold
status which should not be difficult any way.

Hope this helps.
Regards,
Malek.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Todd E. Johnson
Sent: Friday, January 25, 2008 1:42 AM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: Certificate suspension

Thanks for the insight.

Personally, I believe it is the "temporary" that is the cause of
discomfort.  As you already know, the CA is effectively saying "We can
not guarantee proof of possession of the private key to this end
entity", and then it is removed without applications ever knowing.  This

is of course, only by personal experience.

Rather, I would be more comfortable if something like invalidityDate
were added, only in the form of a date range, so the CA then says "We
can not guarantee proof of possession of the private key to this end
entity between the dates of [beginHold] and [endHold].  Further,
eliminate the ability for the CA to remove the entry from the CRL, but
allow for replacement in the event it is actually revoked in the future.

I don't feel the CA should not be in the business of suspending a
certificate to deny access to applications.  I feel that that is more
the application/authorization responsibility.  (i.e., certificate vs.
key suspension)

Perhaps this seems a bit like a Rube Goldberg process, but in the end,
it gives a true technical capability to accept, or outright deny as
revoked depending on the application/business needs.  That's only my
opinion though.  And of course, everybody has one ;)

Denis Pinkas wrote:

Russ and Todd,

I do not share your opinions.

The U.S. Treasury does not support suspension mainly due to obvious
issues encountered with digital signature related transactions, and
future validation of those transactions.  The problem is, if you are
willing to honor signatures produced using certificates from an
infrastructure that does support suspension, you wind up in the same
boat.  It has been a topic of much debate.

At the very begining, I was reluctant to support suspension, but there

is no security flaw

both for authentication and for non repudiation.

In general, if a relying party application does not support

suspension,

then it will treat suspension as (definitively) revoked.

In the case of non repudiation (which mandates the use of either a

time-stamping or

a time-marking mechanism) there is however a slight difference:

 - If the relying party application supports suspension, the

(electronic) signature will be considered

   as (temporary) invalid. In some cases, it MAY try again *at a later

time* to gather new revocation

   information which demonstrate that the electronic signature is

*now* valid. These applications

   may thus know when it is no more necessary to attempt to validate

temporary invalid signatures.

 - If the relying party application does not support suspension,
   the (electronic) signature will usually be considered as

(definitiveley) invalid.

   However, this class of applications could be designed to support

suspension, without supporting

   the suspension extension. The relying party application MAY attempt

to validate at a later time,

   e.g. two or three days later, electronic signatures that were

invalid because the signer's certificate

   was revoked. So they may end up  with the same result, but not

necessarilly within the same time frame.

Denis

Date: Sat, 26 Jan 2008 17:13:54 +0100
From: Alfredo Esposito <[email-masked]>
To: "Bechlaghem, Malek" <[email-masked]>
CC: "Todd E. Johnson" <[email-masked]>, Denis Pinkas <[email-masked]>, [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
The point is the usage of certificate. For authentication purposes,
suspension is fine. If my certificate is suspended "now", "now" I can
not authenticate myself to, say, my workstation. If the purpose is non
repudiation (digital signature has a handwritten signature) the legal
value of a document signed during the suspension period is not trivial
to assess<br>
<br>
Bechlaghem, Malek wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">Hello there,

While I do agree that the semantic of processing a digital signature is
difficult for a relying party when the signer certificate is suspended,
I would like to point out to at least one area where certificate
suspension does have a practical use.

Having been involved in few ID card issuing projects worldwide, my
experience from these is that eID card lifecycle processes tend to be
coupled to certificate lifecycle processes. In other terms, when an ID
card holder suspects that his card is lost or stolen, we call a helpdesk
that suspend his ID card for a defined period of time. This results in
the card certificates revoked with status on-hold (i.e. suspended). If
the guy founds his card, he calls the same helpdesk that will activate
his card back which results in his certificates un-suspended.

This is at least one practical use of using certificate
suspension-unsuspension. As for the relying-party application, it shall
be developed according so that it interprets the certificate on-hold
status which should not be difficult any way.

Hope this helps.
Regards,
Malek.  

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]
On Behalf Of Todd E. Johnson
Sent: Friday, January 25, 2008 1:42 AM
To: Denis Pinkas
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Subject: Re: Certificate suspension

Thanks for the insight.

Personally, I believe it is the "temporary" that is the cause of 
discomfort.  As you already know, the CA is effectively saying "We can 
not guarantee proof of possession of the private key to this end 
entity", and then it is removed without applications ever knowing.  This

is of course, only by personal experience.

Rather, I would be more comfortable if something like invalidityDate 
were added, only in the form of a date range, so the CA then says "We 
can not guarantee proof of possession of the private key to this end 
entity between the dates of [beginHold] and [endHold].  Further, 
eliminate the ability for the CA to remove the entry from the CRL, but 
allow for replacement in the event it is actually revoked in the future.

I don't feel the CA should not be in the business of suspending a 
certificate to deny access to applications.  I feel that that is more 
the application/authorization responsibility.  (i.e., certificate vs. 
key suspension)

Perhaps this seems a bit like a Rube Goldberg process, but in the end, 
it gives a true technical capability to accept, or outright deny as 
revoked depending on the application/business needs.  That's only my 
opinion though.  And of course, everybody has one ;)

Denis Pinkas wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Russ and Todd,

I do not share your opinions.

    </pre>
    <blockquote type="cite">
      <pre wrap="">The U.S. Treasury does not support suspension mainly due to obvious 
issues encountered with digital signature related transactions, and 
future validation of those transactions.  The problem is, if you are 
willing to honor signatures produced using certificates from an 
infrastructure that does support suspension, you wind up in the same 
boat.  It has been a topic of much debate.
      </pre>
    </blockquote>
    <pre wrap="">At the very begining, I was reluctant to support suspension, but there
    </pre>
  </blockquote>
  <pre wrap=""><!---->is no security flaw 
  </pre>
  <blockquote type="cite">
    <pre wrap="">both for authentication and for non repudiation.

In general, if a relying party application does not support
    </pre>
  </blockquote>
  <pre wrap=""><!---->suspension, 
  </pre>
  <blockquote type="cite">
    <pre wrap="">then it will treat suspension as (definitively) revoked.

In the case of non repudiation (which mandates the use of either a
    </pre>
  </blockquote>
  <pre wrap=""><!---->time-stamping or 
  </pre>
  <blockquote type="cite">
    <pre wrap="">a time-marking mechanism) there is however a slight difference:

 - If the relying party application supports suspension, the
    </pre>
  </blockquote>
  <pre wrap=""><!---->(electronic) signature will be considered 
  </pre>
  <blockquote type="cite">
    <pre wrap="">   as (temporary) invalid. In some cases, it MAY try again *at a later
    </pre>
  </blockquote>
  <pre wrap=""><!---->time* to gather new revocation 
  </pre>
  <blockquote type="cite">
    <pre wrap="">   information which demonstrate that the electronic signature is
    </pre>
  </blockquote>
  <pre wrap=""><!---->*now* valid. These applications 
  </pre>
  <blockquote type="cite">
    <pre wrap="">   may thus know when it is no more necessary to attempt to validate
    </pre>
  </blockquote>
  <pre wrap=""><!---->temporary invalid signatures. 
  </pre>
  <blockquote type="cite">
    <pre wrap=""> - If the relying party application does not support suspension, 
   the (electronic) signature will usually be considered as
    </pre>
  </blockquote>
  <pre wrap=""><!---->(definitiveley) invalid. 
  </pre>
  <blockquote type="cite">
    <pre wrap="">   However, this class of applications could be designed to support
    </pre>
  </blockquote>
  <pre wrap=""><!---->suspension, without supporting 
  </pre>
  <blockquote type="cite">
    <pre wrap="">   the suspension extension. The relying party application MAY attempt
    </pre>
  </blockquote>
  <pre wrap=""><!---->to validate at a later time,
  </pre>
  <blockquote type="cite">
    <pre wrap="">   e.g. two or three days later, electronic signatures that were
    </pre>
  </blockquote>
  <pre wrap=""><!---->invalid because the signer's certificate 
  </pre>
  <blockquote type="cite">
    <pre wrap="">   was revoked. So they may end up  with the same result, but not
    </pre>
  </blockquote>
  <pre wrap=""><!---->necessarilly within the same time frame.
  </pre>
  <blockquote type="cite">
    <pre wrap="">Denis 

    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>

From: "Carmen Hastings" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Click here and order replica watches from best brands   
Date: Sat, 26 Jan 2008 14:19:14 -0100

Solid 14k or 18k Gold on two-toned models 

Startling Brietling watches at Replica Classics   

Rolex replica watch

http://www.muttagelectric.com/

Content-class: urn:content-classes:message
Subject: RE: Certificate suspension
Date: Sat, 26 Jan 2008 12:57:40 +0400
From: "Bechlaghem, Malek" <[email-masked]>
To: "Todd E. Johnson" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hello there,

While I do agree that the semantic of processing a digital signature is
difficult for a relying party when the signer certificate is suspended,
I would like to point out to at least one area where certificate
suspension does have a practical use.

Having been involved in few ID card issuing projects worldwide, my
experience from these is that eID card lifecycle processes tend to be
coupled to certificate lifecycle processes. In other terms, when an ID
card holder suspects that his card is lost or stolen, we call a helpdesk
that suspend his ID card for a defined period of time. This results in
the card certificates revoked with status on-hold (i.e. suspended). If
the guy founds his card, he calls the same helpdesk that will activate
his card back which results in his certificates un-suspended.

This is at least one practical use of using certificate
suspension-unsuspension. As for the relying-party application, it shall
be developed according so that it interprets the certificate on-hold
status which should not be difficult any way.

Hope this helps.
Regards,
Malek.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Todd E. Johnson
Sent: Friday, January 25, 2008 1:42 AM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: Certificate suspension

Thanks for the insight.

Personally, I believe it is the "temporary" that is the cause of 
discomfort.  As you already know, the CA is effectively saying "We can 
not guarantee proof of possession of the private key to this end 
entity", and then it is removed without applications ever knowing.  This

is of course, only by personal experience.

Rather, I would be more comfortable if something like invalidityDate 
were added, only in the form of a date range, so the CA then says "We 
can not guarantee proof of possession of the private key to this end 
entity between the dates of [beginHold] and [endHold].  Further, 
eliminate the ability for the CA to remove the entry from the CRL, but 
allow for replacement in the event it is actually revoked in the future.

I don't feel the CA should not be in the business of suspending a 
certificate to deny access to applications.  I feel that that is more 
the application/authorization responsibility.  (i.e., certificate vs. 
key suspension)

Perhaps this seems a bit like a Rube Goldberg process, but in the end, 
it gives a true technical capability to accept, or outright deny as 
revoked depending on the application/business needs.  That's only my 
opinion though.  And of course, everybody has one ;)

Denis Pinkas wrote:
> Russ and Todd,
> 
> I do not share your opinions.
> 
>> The U.S. Treasury does not support suspension mainly due to obvious 
>> issues encountered with digital signature related transactions, and 
>> future validation of those transactions.  The problem is, if you are 
>> willing to honor signatures produced using certificates from an 
>> infrastructure that does support suspension, you wind up in the same 
>> boat.  It has been a topic of much debate.
> 
> At the very begining, I was reluctant to support suspension, but there
is no security flaw 
> both for authentication and for non repudiation.
> 
> In general, if a relying party application does not support
suspension, 
> then it will treat suspension as (definitively) revoked.
> 
> In the case of non repudiation (which mandates the use of either a
time-stamping or 
> a time-marking mechanism) there is however a slight difference:
> 
>  - If the relying party application supports suspension, the
(electronic) signature will be considered 
>    as (temporary) invalid. In some cases, it MAY try again *at a later
time* to gather new revocation 
>    information which demonstrate that the electronic signature is
*now* valid. These applications 
>    may thus know when it is no more necessary to attempt to validate
temporary invalid signatures. 
> 
>  - If the relying party application does not support suspension, 
>    the (electronic) signature will usually be considered as
(definitiveley) invalid. 
> 
>    However, this class of applications could be designed to support
suspension, without supporting 
>    the suspension extension. The relying party application MAY attempt
to validate at a later time,
>    e.g. two or three days later, electronic signatures that were
invalid because the signer's certificate 
>    was revoked. So they may end up  with the same result, but not
necessarilly within the same time frame.
> Denis 

-- 

Regards,

Todd E. Johnson

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

Date: Fri, 25 Jan 2008 22:05:17 -1000
To: [email-masked]
From: "ruuhciem" <[email-masked]>
Subject: saatsen
Reply-To: [email-masked]

http://www.tostrutshop.com/
Forget Department Stores for Designer Footwear Check us out for Savings on Prada Shoes Gucci Chanel

Date: Fri, 25 Jan 2008 17:13:40 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Fwd: RFC 5114 on Additional Diffie-Hellman Groups for Use with IETF 	Standards
Sender: [email-masked]

>A new Request for Comments is now available in online RFC libraries.
>
>        
>         RFC 5114
>
>         Title:      Additional Diffie-Hellman Groups for Use
>                     with IETF Standards
>         Author:     M. Lepinski, S. Kent
>         Status:     Informational
>         Date:       January 2008
>         Mailbox:    [email-masked],
>                     [email-masked]
>         Pages:      23
>         Characters: 49565
>         Updates/Obsoletes/SeeAlso:   None
>
>         I-D Tag:    draft-lepinski-dh-groups-03.txt
>
>         URL:        http://www.rfc-editor.org/rfc/rfc5114.txt
>
>This document describes eight Diffie-Hellman groups that can be used
>in conjunction with IETF protocols to provide security for Internet
>communications.  The groups allow implementers to use the same groups
>with a variety of security protocols, e.g., SMIME, Secure SHell (SSH),
>Transport Layer Security (TLS), and Internet Key Exchange (IKE).
>
>All of these groups comply in form and structure with relevant
>standards from ISO, ANSI, NIST, and the IEEE.  These groups are
>compatible with all IETF standards that make use of Diffie-Hellman or
>Elliptic Curve Diffie-Hellman cryptography.
>
>These groups and the associated test data are defined by NIST on
>their web site [EX80056A], but have not yet (as of this writing) been
>published in a formal NIST document.  Publication of these groups and
>associated test data, as well as describing how to use Diffie-Hellman
>and Elliptic Curve Diffie-Hellman for key agreement in all of the
>protocols cited below, in one RFC, will facilitate development of
>interoperable implementations and support the Federal Information
>Processing Standard (FIPS) validation of
>implementations that make use of these groups.  This memo provides
>information for the Internet community.
>
>
>INFORMATIONAL: This memo provides information for the Internet community.
>It does not specify an Internet standard of any kind. Distribution
>of this memo is unlimited.

PKIX implementers should see especially section 3.1.

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 25 Jan 2008 23:36:30 +0100
To: [email-masked]
From: "hydromys" <[email-masked]>
Subject: iarutrot
Reply-To: [email-masked]

http://newtostrut.com/
Gucci Prada Dsquared D&G & Other Top Fashion Designer Shoes and Boots Amazing DEALS HERE

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-pkix-ecc-subpubkeyinfo-02.txt 
Date: Fri, 25 Jan 2008 11:10:01 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : Elliptic Curve Cryptography Subject Public Key Information
	Author(s)       : S. Turner, et al.
	Filename        : draft-ietf-pkix-ecc-subpubkeyinfo-02.txt
	Pages           : 19
	Date            : 2008-01-25

This document specifies the syntax and semantics for the Subject 
Public Key Information field in certificates that support Elliptic 
Curve Cryptography.  This document updates [RFC3279].

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

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

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

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

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

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

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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-02.txt

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

Content-Type: text/plain
Content-ID:     <2008-01-25110523.I-D\@ietf.org>

--OtherAccess--

--NextPart--

From: "Turner, Sean P." <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-01.txt
Date: Fri, 25 Jan 2008 10:58:58 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Good catch. When I updated the key usage list I didn't remove the sentence.
I'll post an updated draft.

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Russ Housley
>Sent: Thursday, January 24, 2008 5:30 PM
>To: [email-masked]
>Subject: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-01.txt
>
>
>The second to last paragraph in Section 3 says:
>
>    If the EE certificate keyUsage extension asserts 
>keyAgreement then it
>    MAY assert either encipherOnly or decipherOnly.  However, this
>    specification RECOMMENDS that if cRLSign is present, then
>    keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.
>
>I think the second sentence does not seem to fit here.  I 
>think it should be deleted.
>
>Russ
>

Date: Fri, 25 Jan 2008 13:10:39 +0100
From: Peter Sylvester <[email-masked]>
To: Jim Schaad <[email-masked]>
Cc: "'David A. Cooper'" <[email-masked]>, [email-masked]
Subject: Re: rfc3280bis change requested
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Jim Schaad wrote:
> Peter,
>
> A couple of more comments.
>
> 1.  The XER encoding would most likely be placed in a Base64 encoding
> because of the OCTET STRING wrapper, so I don't know that there is any =
real
> advantange not be DER.
>  =20
My small sentence was grammatically false and also incomplete.

I think the real requirement is
- One must be able to create the DER encoding of the certficate.
- X509 specifies that extensions' content need to be DER encoded
  but I think what is meant is the same as in the previous point.

As you said in another mail. Without knowing the ASN.1 it
is impossible to create a DER encoding from any other encoding
both for the tbsCertficate and extension content. Since extension
are open types and a creator certainly does not know whether
a verifier knows an extension.

I think somewhere in the defining of SIGNED in X.5/6xx it is
said that one should use DER to transport such things.

What about:

  Each extension includes an OID and an ASN.1 structure.  When an
  extension appears in a certificate, the OID appears as the field
  extnID and the corresponding ASN.1 encoded structure is the value of
  the octet string extnValue.
  In order to be sure that a user of a certificate can correctly perform
  signature verification, an encoder MUST use a DER encoding of the
  extension content.

As a result of a the ping pong game of asn1 people defining
octetstring wrappers (CONTAINING constraints) allowing good
parsers to go into the contents, which is what the other camp
tried to avoid by not simply using ANY DEFINED BY, today
one would probably define

      extnValue  EXTENSION.&ExtnType({ExtensionSet}{@extnId}))

which, to keep compatibility would say:

>>
>>    Extension ::=3D SEQUENCE {
>>       extnId       EXTENSION.&id ({ExtensionSet}),
>>       critical       BOOLEAN DEFAULT FALSE,
>>       extnValue  OCTET STRING CONTAINING
>>                  EXTENSION.&ExtnType({ExtensionSet}{@extnId}))
>>    =20

--=20
To verify the signature, see http://edelpki.edelweb.fr/=20
Cela vous permet de charger le certificat de l'autorit=E9;=20
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20

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

--------------ms080701000403030005000102--

From: "Jim Schaad" <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>, "'David A. Cooper'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: rfc3280bis change requested
Date: Thu, 24 Jan 2008 23:14:24 -0800
Sender: [email-masked]

Peter,

A couple of more comments.

1.  The XER encoding would most likely be placed in a Base64 encoding
because of the OCTET STRING wrapper, so I don't know that there is any real
advantange not be DER.

2. Do you have reason to believe that one can successfully convert from an
XER encoding to a DER encoding using just the XML (you don't get to use the
ASN.1).  I believe that I have shown it cannot be done in all cases for BER
to DER, this is the reason for the change.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Peter Sylvester
> Sent: Thursday, January 24, 2008 8:33 AM
> To: David A. Cooper
> Cc: [email-masked]; Sam Hartman; [email-masked]
> Subject: Re: rfc3280bis change requested
> 
> X.509 should probably say
> 
>    Extension ::= SEQUENCE {
>       extnId       EXTENSION.&id ({ExtensionSet}),
>       critical       BOOLEAN DEFAULT FALSE,
>       extnValue  OCTET STRING CONTAINING
>                  EXTENSION.&ExtnType({ExtensionSet}{@extnId}))
> 
> 
> which would mean that when the signature is created DER encoding
> is used, but if one uses a XER encoding of the certficate, one would
> not see the raw DER octets but the XER encoding of the content.
> 
> I am still not sure whether the above is correct ASN.1, at least some
> gurus say so.
> 
> IMO the text below should say:
> 
> Each extension includes an OID and an ASN.1 structure.  When an
>   extension appears in a DER encoding of the certificate,
>   the OID appears as the field extnID and the corresponding
>   ASN.1 DER encoded structure is the value of the octet string
> extnValue.
>   in particuler, DER encoing is used for the calculation of the
> certficate.
> 
> regards
> 
> 
> David A. Cooper wrote:
> >
> > [email-masked] wrote:
> >> I believe that in section 4.2 there needs to be a statement added to
> the
> >> effect that extensions MUST be encoded using DER and stored in that
> >> encoding
> >> in the extnValue field.
> >>
> >
> > If there is confusion about whether 3280bis requires extensions to be
> > DER encoded and it is not too late to make a clarifying change, then
> > it would be a good idea to add something to 3280bis that clearly
> > states that extensions must be DER encoded.
> >
> > This is an X.509 requirement.  The ASN.1 for Extension in X.509 is:
> >
> >    Extension ::= SEQUENCE {
> >       extnId       EXTENSION.&id ({ExtensionSet}),
> >       critical       BOOLEAN DEFAULT FALSE,
> >       extnValue  OCTET STRING
> >                -- contains a DER encoding of a value of type
> &ExtnType
> >                -- for the extension object identified by extnId -- }
> >
> >
> > I would suggest the following changes to 3280bis:
> >
> > section 4.1 and appendix A.1 (add a comment to the ASN.1 for
> Extension):
> >
> > old:
> >   Extension  ::=  SEQUENCE  {
> >        extnID      OBJECT IDENTIFIER,
> >        critical    BOOLEAN DEFAULT FALSE,
> >        extnValue   OCTET STRING  }
> >
> > new:
> >   Extension  ::=  SEQUENCE  {
> >        extnID      OBJECT IDENTIFIER,
> >        critical    BOOLEAN DEFAULT FALSE,
> >        extnValue   OCTET STRING
> >            -- contains the DER encoding of an ASN.1 value
> corresponding
> >            -- to the extension type identified by extnID -- }
> >
> >
> > section 4.2 (add the word "DER" to "ASN.1 encoded"):
> >
> > old:
> >   Each extension includes an OID and an ASN.1 structure.  When an
> >   extension appears in a certificate, the OID appears as the field
> >   extnID and the corresponding ASN.1 encoded structure is the value
> of
> >   the octet string extnValue.
> >
> > new:
> >   Each extension includes an OID and an ASN.1 structure.  When an
> >   extension appears in a certificate, the OID appears as the field
> >   extnID and the corresponding ASN.1 DER encoded structure is the
> > value of
> >   the octet string extnValue.
> >
> >
> >
> 
> 
> --
> To verify the signature, see http://edelpki.edelweb.fr/
> Cela vous permet de charger le certificat de l'autorité;
> die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
> 

Date: Thu, 24 Jan 2008 19:04:21 -0500
From: "Todd E. Johnson" <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Certificate suspension
Sender: [email-masked]

Hrm...

1,$s/don't feel the CA should not be/don't feel the CA should be/

Todd E. Johnson wrote:

> I don't feel the CA should not be in the business of suspending a 
> certificate to deny access to applications.  I feel that that is more 
> the application/authorization responsibility.  (i.e., certificate vs. 
> key suspension)

-- 

Regards,

Todd E. Johnson

Date: Thu, 24 Jan 2008 17:41:45 -0500
From: "Todd E. Johnson" <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Certificate suspension
Sender: [email-masked]

Thanks for the insight.

Personally, I believe it is the "temporary" that is the cause of 
discomfort.  As you already know, the CA is effectively saying "We can 
not guarantee proof of possession of the private key to this end 
entity", and then it is removed without applications ever knowing.  This 
is of course, only by personal experience.

Rather, I would be more comfortable if something like invalidityDate 
were added, only in the form of a date range, so the CA then says "We 
can not guarantee proof of possession of the private key to this end 
entity between the dates of [beginHold] and [endHold].  Further, 
eliminate the ability for the CA to remove the entry from the CRL, but 
allow for replacement in the event it is actually revoked in the future.

I don't feel the CA should not be in the business of suspending a 
certificate to deny access to applications.  I feel that that is more 
the application/authorization responsibility.  (i.e., certificate vs. 
key suspension)

Perhaps this seems a bit like a Rube Goldberg process, but in the end, 
it gives a true technical capability to accept, or outright deny as 
revoked depending on the application/business needs.  That's only my 
opinion though.  And of course, everybody has one ;)

Denis Pinkas wrote:
> Russ and Todd,
> 
> I do not share your opinions.
> 
>> The U.S. Treasury does not support suspension mainly due to obvious 
>> issues encountered with digital signature related transactions, and 
>> future validation of those transactions.  The problem is, if you are 
>> willing to honor signatures produced using certificates from an 
>> infrastructure that does support suspension, you wind up in the same 
>> boat.  It has been a topic of much debate.
> 
> At the very begining, I was reluctant to support suspension, but there is no security flaw 
> both for authentication and for non repudiation.
> 
> In general, if a relying party application does not support suspension, 
> then it will treat suspension as (definitively) revoked.
> 
> In the case of non repudiation (which mandates the use of either a time-stamping or 
> a time-marking mechanism) there is however a slight difference:
> 
>  - If the relying party application supports suspension, the (electronic) signature will be considered 
>    as (temporary) invalid. In some cases, it MAY try again *at a later time* to gather new revocation 
>    information which demonstrate that the electronic signature is *now* valid. These applications 
>    may thus know when it is no more necessary to attempt to validate temporary invalid signatures. 
> 
>  - If the relying party application does not support suspension, 
>    the (electronic) signature will usually be considered as (definitiveley) invalid. 
> 
>    However, this class of applications could be designed to support suspension, without supporting 
>    the suspension extension. The relying party application MAY attempt to validate at a later time,
>    e.g. two or three days later, electronic signatures that were invalid because the signer's certificate 
>    was revoked. So they may end up  with the same result, but not necessarilly within the same time frame.
> 
> Denis 
> 

-- 

Regards,

Todd E. Johnson

Date: Thu, 24 Jan 2008 17:30:02 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Comments on draft-ietf-pkix-ecc-subpubkeyinfo-01.txt
Sender: [email-masked]

The second to last paragraph in Section 3 says:

    If the EE certificate keyUsage extension asserts keyAgreement then it
    MAY assert either encipherOnly or decipherOnly.  However, this
    specification RECOMMENDS that if cRLSign is present, then
    keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.

I think the second sentence does not seem to fit here.  I think it 
should be deleted.

Russ

Date: Thu, 24 Jan 2008 16:54:40 -0500
To: Peter Sylvester <[email-masked]>, "David A. Cooper" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: rfc3280bis change requested
Cc: [email-masked], Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

Peter:

I find David's suggested text more clear.  The point is that the 
OCTET STRING MUST contain the DER encoding of the extension value.

Russ

Date: Thu, 24 Jan 2008 20:15:35 +0100
From: Peter Sylvester <[email-masked]>
To: Tolga Acar <[email-masked]>
Cc: "David A. Cooper" <[email-masked]>, "[email-masked]" <[email-masked]>, Sam Hartman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: rfc3280bis change requested
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Tolga Acar wrote:
> RFC3280 Section 4.1 says (the first paragraph):
>
> The X.509 v3 certificate basic syntax is as follows.  For signature
>    calculation, the data that is to be signed is encoded using the ASN.=
1
>    distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a=

>    tag, length, value encoding system for each element.
>
> It seems to say clearly that you ought to use DER encoding to get a sig=
ned certificate. I'm not sure if that needs to be repeated in the extensi=
on definition.
>  =20

No, it does not. It only says that you need a DER encoding in order a=20
signature.
It does not says that you could transfer or store a certficate in any oth=
er
form although this is obviously a practical thing to use DER in these
cases, at least when one only considers the BER derivates.

Since X509 predates XML and it also predates CONTAINING constraints
the wordings are quite understandable.

--=20
To verify the signature, see http://edelpki.edelweb.fr/=20
Cela vous permet de charger le certificat de l'autorit=E9;=20
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20

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

--------------ms000208000405050603070405--

From: "Jim Schaad" <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>, "'David A. Cooper'" <[email-masked]>
Cc: "'Sam Hartman'" <[email-masked]>, <[email-masked]>
Subject: RE: rfc3280bis change requested
Date: Thu, 24 Jan 2008 11:03:09 -0800
Sender: [email-masked]

Peter,

What happens if it appears in a BER encoding of a certificate?  This is the
problem that I pointed out.

I am not overly worried about supporting of XER encoded certificates as this
is not part of the PKIX standard.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Peter Sylvester
> Sent: Thursday, January 24, 2008 8:33 AM
> To: David A. Cooper
> Cc: [email-masked]; Sam Hartman; [email-masked]
> Subject: Re: rfc3280bis change requested
> 
> X.509 should probably say
> 
>    Extension ::= SEQUENCE {
>       extnId       EXTENSION.&id ({ExtensionSet}),
>       critical       BOOLEAN DEFAULT FALSE,
>       extnValue  OCTET STRING CONTAINING
>                  EXTENSION.&ExtnType({ExtensionSet}{@extnId}))
> 
> 
> which would mean that when the signature is created DER encoding
> is used, but if one uses a XER encoding of the certficate, one would
> not see the raw DER octets but the XER encoding of the content.
> 
> I am still not sure whether the above is correct ASN.1, at least some
> gurus say so.
> 
> IMO the text below should say:
> 
> Each extension includes an OID and an ASN.1 structure.  When an
>   extension appears in a DER encoding of the certificate,
>   the OID appears as the field extnID and the corresponding
>   ASN.1 DER encoded structure is the value of the octet string
> extnValue.
>   in particuler, DER encoing is used for the calculation of the
> certficate.
> 
> regards
> 
> 
> David A. Cooper wrote:
> >
> > [email-masked] wrote:
> >> I believe that in section 4.2 there needs to be a statement added to
> the
> >> effect that extensions MUST be encoded using DER and stored in that
> >> encoding
> >> in the extnValue field.
> >>
> >
> > If there is confusion about whether 3280bis requires extensions to be
> > DER encoded and it is not too late to make a clarifying change, then
> > it would be a good idea to add something to 3280bis that clearly
> > states that extensions must be DER encoded.
> >
> > This is an X.509 requirement.  The ASN.1 for Extension in X.509 is:
> >
> >    Extension ::= SEQUENCE {
> >       extnId       EXTENSION.&id ({ExtensionSet}),
> >       critical       BOOLEAN DEFAULT FALSE,
> >       extnValue  OCTET STRING
> >                -- contains a DER encoding of a value of type
> &ExtnType
> >                -- for the extension object identified by extnId -- }
> >
> >
> > I would suggest the following changes to 3280bis:
> >
> > section 4.1 and appendix A.1 (add a comment to the ASN.1 for
> Extension):
> >
> > old:
> >   Extension  ::=  SEQUENCE  {
> >        extnID      OBJECT IDENTIFIER,
> >        critical    BOOLEAN DEFAULT FALSE,
> >        extnValue   OCTET STRING  }
> >
> > new:
> >   Extension  ::=  SEQUENCE  {
> >        extnID      OBJECT IDENTIFIER,
> >        critical    BOOLEAN DEFAULT FALSE,
> >        extnValue   OCTET STRING
> >            -- contains the DER encoding of an ASN.1 value
> corresponding
> >            -- to the extension type identified by extnID -- }
> >
> >
> > section 4.2 (add the word "DER" to "ASN.1 encoded"):
> >
> > old:
> >   Each extension includes an OID and an ASN.1 structure.  When an
> >   extension appears in a certificate, the OID appears as the field
> >   extnID and the corresponding ASN.1 encoded structure is the value
> of
> >   the octet string extnValue.
> >
> > new:
> >   Each extension includes an OID and an ASN.1 structure.  When an
> >   extension appears in a certificate, the OID appears as the field
> >   extnID and the corresponding ASN.1 DER encoded structure is the
> > value of
> >   the octet string extnValue.
> >
> >
> >
> 
> 
> --
> To verify the signature, see http://edelpki.edelweb.fr/
> Cela vous permet de charger le certificat de l'autorité;
> die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
> 

Date: Thu, 24 Jan 2008 20:40:37 +0300
To: [email-masked]
From: "vaikeutt" <[email-masked]>
Subject: varkenso
Reply-To: [email-masked]

http://bkaowaega.com/
Tired of pumps and extenders that don't really work? Here is the only solution that has a 100% money back guarantee.

From: Tolga Acar <[email-masked]>
To: Peter Sylvester <[email-masked]>, "David A. Cooper" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Sam Hartman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 24 Jan 2008 09:38:23 -0800
Subject: RE: rfc3280bis change requested
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

RFC3280 Section 4.1 says (the first paragraph):

The X.509 v3 certificate basic syntax is as follows.  For signature
   calculation, the data that is to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a
   tag, length, value encoding system for each element.

It seems to say clearly that you ought to use DER encoding to get a signed certificate. I'm not sure if that needs to be repeated in the extension definition.

- Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Sylvester
Sent: Thursday, January 24, 2008 8:33 AM
To: David A. Cooper
Cc: [email-masked]; Sam Hartman; [email-masked]
Subject: Re: rfc3280bis change requested

X.509 should probably say

   Extension ::= SEQUENCE {
      extnId       EXTENSION.&id ({ExtensionSet}),
      critical       BOOLEAN DEFAULT FALSE,
      extnValue  OCTET STRING CONTAINING
                 EXTENSION.&ExtnType({ExtensionSet}{@extnId}))

which would mean that when the signature is created DER encoding
is used, but if one uses a XER encoding of the certficate, one would
not see the raw DER octets but the XER encoding of the content.

I am still not sure whether the above is correct ASN.1, at least some
gurus say so.

IMO the text below should say:

Each extension includes an OID and an ASN.1 structure.  When an
  extension appears in a DER encoding of the certificate,
  the OID appears as the field extnID and the corresponding
  ASN.1 DER encoded structure is the value of the octet string extnValue.
  in particuler, DER encoing is used for the calculation of the certficate.

regards

David A. Cooper wrote:
>
> [email-masked] wrote:
>> I believe that in section 4.2 there needs to be a statement added to the
>> effect that extensions MUST be encoded using DER and stored in that
>> encoding
>> in the extnValue field.
>>
>
> If there is confusion about whether 3280bis requires extensions to be
> DER encoded and it is not too late to make a clarifying change, then
> it would be a good idea to add something to 3280bis that clearly
> states that extensions must be DER encoded.
>
> This is an X.509 requirement.  The ASN.1 for Extension in X.509 is:
>
>    Extension ::= SEQUENCE {
>       extnId       EXTENSION.&id ({ExtensionSet}),
>       critical       BOOLEAN DEFAULT FALSE,
>       extnValue  OCTET STRING
>                -- contains a DER encoding of a value of type &ExtnType
>                -- for the extension object identified by extnId -- }
>
>
> I would suggest the following changes to 3280bis:
>
> section 4.1 and appendix A.1 (add a comment to the ASN.1 for Extension):
>
> old:
>   Extension  ::=  SEQUENCE  {
>        extnID      OBJECT IDENTIFIER,
>        critical    BOOLEAN DEFAULT FALSE,
>        extnValue   OCTET STRING  }
>
> new:
>   Extension  ::=  SEQUENCE  {
>        extnID      OBJECT IDENTIFIER,
>        critical    BOOLEAN DEFAULT FALSE,
>        extnValue   OCTET STRING
>            -- contains the DER encoding of an ASN.1 value corresponding
>            -- to the extension type identified by extnID -- }
>
>
> section 4.2 (add the word "DER" to "ASN.1 encoded"):
>
> old:
>   Each extension includes an OID and an ASN.1 structure.  When an
>   extension appears in a certificate, the OID appears as the field
>   extnID and the corresponding ASN.1 encoded structure is the value of
>   the octet string extnValue.
>
> new:
>   Each extension includes an OID and an ASN.1 structure.  When an
>   extension appears in a certificate, the OID appears as the field
>   extnID and the corresponding ASN.1 DER encoded structure is the
> value of
>   the octet string extnValue.
>
>
>

--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

Date: Thu, 24 Jan 2008 12:15:37 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: rfc3280bis change requested
Sender: [email-masked]

Peter,

I think your proposed language would lead to confusion.  While you may 
believe that X.509 should allow the contents of extnValue to be encoded 
using encoding rules other than DER in the unlikely case that the 
certificate is not DER encoded, X.509 specifies that extnValue always 
includes a DER encoded value.  As long as X.509 says this, the PKIX 
profile of X.509 should not imply otherwise.

Dave

Peter Sylvester wrote:
> X.509 should probably say
>
>   Extension ::= SEQUENCE {
>      extnId       EXTENSION.&id ({ExtensionSet}),
>      critical       BOOLEAN DEFAULT FALSE,
>      extnValue  OCTET STRING CONTAINING                 
> EXTENSION.&ExtnType({ExtensionSet}{@extnId}))
>
>
> which would mean that when the signature is created DER encoding
> is used, but if one uses a XER encoding of the certficate, one would
> not see the raw DER octets but the XER encoding of the content.
>
> I am still not sure whether the above is correct ASN.1, at least some
> gurus say so.
>
> IMO the text below should say:
>
> Each extension includes an OID and an ASN.1 structure.  When an
>  extension appears in a DER encoding of the certificate,
>  the OID appears as the field extnID and the corresponding
>  ASN.1 DER encoded structure is the value of the octet string extnValue.
>  in particuler, DER encoing is used for the calculation of the 
> certficate.
>
> regards
>
>
> David A. Cooper wrote:
>>
>> [email-masked] wrote:
>>> I believe that in section 4.2 there needs to be a statement added to 
>>> the
>>> effect that extensions MUST be encoded using DER and stored in that 
>>> encoding
>>> in the extnValue field.
>>>   
>>
>> If there is confusion about whether 3280bis requires extensions to be 
>> DER encoded and it is not too late to make a clarifying change, then 
>> it would be a good idea to add something to 3280bis that clearly 
>> states that extensions must be DER encoded.
>>
>> This is an X.509 requirement.  The ASN.1 for Extension in X.509 is:
>>
>>    Extension ::= SEQUENCE {
>>       extnId       EXTENSION.&id ({ExtensionSet}),
>>       critical       BOOLEAN DEFAULT FALSE,
>>       extnValue  OCTET STRING
>>                -- contains a DER encoding of a value of type &ExtnType
>>                -- for the extension object identified by extnId -- }
>>
>>
>> I would suggest the following changes to 3280bis:
>>
>> section 4.1 and appendix A.1 (add a comment to the ASN.1 for Extension):
>>
>> old:
>>   Extension  ::=  SEQUENCE  {
>>        extnID      OBJECT IDENTIFIER,
>>        critical    BOOLEAN DEFAULT FALSE,
>>        extnValue   OCTET STRING  }
>>
>> new:
>>   Extension  ::=  SEQUENCE  {
>>        extnID      OBJECT IDENTIFIER,
>>        critical    BOOLEAN DEFAULT FALSE,
>>        extnValue   OCTET STRING
>>            -- contains the DER encoding of an ASN.1 value corresponding
>>            -- to the extension type identified by extnID -- }
>>
>>
>> section 4.2 (add the word "DER" to "ASN.1 encoded"):
>>
>> old:
>>   Each extension includes an OID and an ASN.1 structure.  When an
>>   extension appears in a certificate, the OID appears as the field
>>   extnID and the corresponding ASN.1 encoded structure is the value of
>>   the octet string extnValue.
>>
>> new:
>>   Each extension includes an OID and an ASN.1 structure.  When an
>>   extension appears in a certificate, the OID appears as the field
>>   extnID and the corresponding ASN.1 DER encoded structure is the 
>> value of
>>   the octet string extnValue.
>>
>>
>>
>
>

Date: Thu, 24 Jan 2008 17:33:29 +0100
From: Peter Sylvester <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Cc: [email-masked], Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: rfc3280bis change requested
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

X.509 should probably say

   Extension ::=3D SEQUENCE {
      extnId       EXTENSION.&id ({ExtensionSet}),
      critical       BOOLEAN DEFAULT FALSE,
      extnValue  OCTET STRING CONTAINING=20
                 EXTENSION.&ExtnType({ExtensionSet}{@extnId}))

which would mean that when the signature is created DER encoding
is used, but if one uses a XER encoding of the certficate, one would
not see the raw DER octets but the XER encoding of the content.

I am still not sure whether the above is correct ASN.1, at least some
gurus say so.

IMO the text below should say:

Each extension includes an OID and an ASN.1 structure.  When an
  extension appears in a DER encoding of the certificate,
  the OID appears as the field extnID and the corresponding
  ASN.1 DER encoded structure is the value of the octet string extnValue.=

  in particuler, DER encoing is used for the calculation of the certficat=
e.

regards
=20

David A. Cooper wrote:
>
> [email-masked] wrote:
>> I believe that in section 4.2 there needs to be a statement added to t=
he
>> effect that extensions MUST be encoded using DER and stored in that=20
>> encoding
>> in the extnValue field.
>>  =20
>
> If there is confusion about whether 3280bis requires extensions to be=20
> DER encoded and it is not too late to make a clarifying change, then=20
> it would be a good idea to add something to 3280bis that clearly=20
> states that extensions must be DER encoded.
>
> This is an X.509 requirement.  The ASN.1 for Extension in X.509 is:
>
>    Extension ::=3D SEQUENCE {
>       extnId       EXTENSION.&id ({ExtensionSet}),
>       critical       BOOLEAN DEFAULT FALSE,
>       extnValue  OCTET STRING
>                -- contains a DER encoding of a value of type &ExtnType
>                -- for the extension object identified by extnId -- }
>
>
> I would suggest the following changes to 3280bis:
>
> section 4.1 and appendix A.1 (add a comment to the ASN.1 for Extension)=
:
>
> old:
>   Extension  ::=3D  SEQUENCE  {
>        extnID      OBJECT IDENTIFIER,
>        critical    BOOLEAN DEFAULT FALSE,
>        extnValue   OCTET STRING  }
>
> new:
>   Extension  ::=3D  SEQUENCE  {
>        extnID      OBJECT IDENTIFIER,
>        critical    BOOLEAN DEFAULT FALSE,
>        extnValue   OCTET STRING
>            -- contains the DER encoding of an ASN.1 value corresponding=

>            -- to the extension type identified by extnID -- }
>
>
> section 4.2 (add the word "DER" to "ASN.1 encoded"):
>
> old:
>   Each extension includes an OID and an ASN.1 structure.  When an
>   extension appears in a certificate, the OID appears as the field
>   extnID and the corresponding ASN.1 encoded structure is the value of
>   the octet string extnValue.
>
> new:
>   Each extension includes an OID and an ASN.1 structure.  When an
>   extension appears in a certificate, the OID appears as the field
>   extnID and the corresponding ASN.1 DER encoded structure is the=20
> value of
>   the octet string extnValue.
>
>
>

--=20
To verify the signature, see http://edelpki.edelweb.fr/=20
Cela vous permet de charger le certificat de l'autorit=E9;=20
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20

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

--------------ms070205030209000907030004--

Date: Thu, 24 Jan 2008 10:54:10 -0500
To: <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: rfc3280bis change requested
Sender: [email-masked]

I agree with Jim.  This would simply be stating a requirement that 
already exists in X.509.

Russ

At 12:17 AM 1/24/2008, [email-masked] wrote:

>I believe that in section 4.2 there needs to be a statement added to the
>effect that extensions MUST be encoded using DER and stored in that encoding
>in the extnValue field.
>
>The following scenario demonstrates why I believe this statement needs to be
>added.
>
>1.  Assume Alice is a CA and places a private extension in every certificate
>that is issued.
>
>2.  Alice creates the certificate using DER encoding throughout, hashes and
>signs.
>
>3.  Alice then re-encodes the entire certificate using BER indefinite
>encoding (for unknown reasons) and passes the certificate to Bob
>
>4.  Bob attempts to change the encoding of the certificate from BER
>indefinite to DER and cannot always do so for the private extension unless
>he also knows the syntax associated with it.  Bob will not be able to a)
>remove all default values and b) recognize all SET types and sort them.
>
>
>Example
>
>PrivateExtension ::= SEQUENCE {
>        bool   BOOLEAN DEFAULT FALSE,
>        iSet   [0] IMPLICIT SET OF INTEGER
>}
>
>Jim

Date: Thu, 24 Jan 2008 09:01:53 -0500
From: "David A. Cooper" <[email-masked]>
To: [email-masked], Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: rfc3280bis change requested
Sender: [email-masked]

[email-masked] wrote:
> I believe that in section 4.2 there needs to be a statement added to the
> effect that extensions MUST be encoded using DER and stored in that encoding
> in the extnValue field.
>   

If there is confusion about whether 3280bis requires extensions to be 
DER encoded and it is not too late to make a clarifying change, then it 
would be a good idea to add something to 3280bis that clearly states 
that extensions must be DER encoded.

This is an X.509 requirement.  The ASN.1 for Extension in X.509 is:

    Extension ::= SEQUENCE {
       extnId       EXTENSION.&id ({ExtensionSet}),
       critical       BOOLEAN DEFAULT FALSE,
       extnValue  OCTET STRING
                -- contains a DER encoding of a value of type &ExtnType
                -- for the extension object identified by extnId -- }

I would suggest the following changes to 3280bis:

section 4.1 and appendix A.1 (add a comment to the ASN.1 for Extension):

old:
   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING  }

new:
   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
            -- contains the DER encoding of an ASN.1 value corresponding
            -- to the extension type identified by extnID -- }

section 4.2 (add the word "DER" to "ASN.1 encoded"):

old:
   Each extension includes an OID and an ASN.1 structure.  When an
   extension appears in a certificate, the OID appears as the field
   extnID and the corresponding ASN.1 encoded structure is the value of
   the octet string extnValue.

new:
   Each extension includes an OID and an ASN.1 structure.  When an
   extension appears in a certificate, the OID appears as the field
   extnID and the corresponding ASN.1 DER encoded structure is the value of
   the octet string extnValue.

Content-class: urn:content-classes:message
Subject: RE: Certificate suspension
Date: Thu, 24 Jan 2008 13:17:31 +0100
From: "Stevens, Frits" <[email-masked]>
To: "Stephen Wilson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

The IndenTrust community is using suspension with OCSP. Look at their
website, e.g.: http://www.identrust.com/pdf/IP-ICP_3.1a.pdf 
 
Regards,
Frits Stevens 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Wilson
Sent: woensdag 23 januari 2008 02:50
To: [email-masked]
Subject: Certificate suspension

I'm wondering to what extent is X.509 certificate suspension used in
practice?

Most if not all publicly visible CPs describe suspension, in almost
exactly the same way as they do revocation.  Yet in my experience, I
cannot ever recall a commercial CA or a closed/vertical PKI actually
doing suspensions.

To my mind, suspension is riddled with difficulties, not anticipated by
the way CRLs work.  I could go into my concerns in a separate e-mail. 
But if anyone can point to suspension being offered in practice (or
failing that, a critique of suspension) that would be appreciated!

Thanks in advance.

Cheers,

Stephen Wilson
Managing Director
Lockstep

Phone +61 (0)414 488 851

www.lockstep.com.au
-------------------
  * Lockstep Technologies: ICT Secrets of Innovation Finalist 2007
  * Lockstep Technologies: Anthill / PwC Cool Company Finalist 2007
-------------------
Lockstep Consulting provides independent specialist advice and analysis
on authentication, PKI and smartcards.  Lockstep Technologies develops
unique new smart ID solutions that safeguard identity and privacy.

Date: Thu, 24 Jan 2008 12:09:45 +0100
From: Alfredo Esposito <[email-masked]>
To: Johannes Merkle <[email-masked]>
CC: Massimiliano Pala <[email-masked]>, [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Johannes<br>
In the Italian law the word adopted is "sospensione", the literal
translation of the english "suspension" and, sadly, the law explicitly
states that a document signed with a suspended or revoked certificate
is equivalent to a unsigned document. I agree with you that the
technical standards SHALL address this issue, but maybe IETF is not the
right forum<br>
<br>
Ciao<br>
Dino<br>
<br>
Johannes Merkle wrote:
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">Hi Dino,

non-english speaking countries hardly use the term "suspension" in
their laws. Furthermore, the requirements imposed by the law usually
do not refer to any standards or technical solutions. This is
particularly true within the EU where electronic signatures do not
even need to deploy digital signatures.

Your appreciation regarding the source of the problems seems to
match mine: It's the limitation of technical standards to meet the
logical requirements of the legislation. (At least as long as SCVP
is not widely used.)

However, I disagree that a signature created while the certificate
was on hold must necessarily be considered invalid. This is a matter
of the certificate policy, and there are application scenarios for
suspension (reaction to unauthenticated revocation requests) where
such signatures could be regarded valid after reinstating of the
certificate. However, I do not advocate suspension as revocation and
potential certificate renewal is a better solution.

By the way: Here in Germany, suspension of qualified certificates is
considered inadmissable (at least by the supervising authority),
although there are no explicit requirements in the law and ordinance.

Johannes

Alfredo Esposito schrieb am 24.01.2008 11:35:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi Johannes
In my experience who write down the laws has often a poor understanding
of technical issues; therefore some words that have a very special
meaning in a technical specification are instead used in their general
meaning, causing a bit of confusion.
Suspension is one of these words, because a document signed during the
suspension should be "legally invalid" but there is no standard way of
checking a past CRL (i.e. verifying a signature at some time t&lt;&lt;now).
Better, there are some ways (ETSI specifications on advanced signatures,
putting the CRL in the PKCS#7 envelope) but none is generally adopted.
On the other hand, the PKI standards were developed well in advance of
the legal concept of electronic signature, a concept that is still
unclear in Europe, in spite of the EU Directive of 8 years ago

Dino Esposito

Johannes Merkle wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">Hi Massimiliano,

most signature laws I have seen so far had a quite clear
understanding of what they require. The problems arise from the
limitations in the technical implementations of their logical
requirements.

Johannes

Massimiliano Pala schrieb am 23.01.2008 20:20:

      </pre>
      <blockquote type="cite">
        <pre wrap="">Hi all,

I guess that the problem with the current PKIX solution on suspension is
that it is just an extended revocation status - this means that it is
just a sub-case of revocation. In many cases this is not what you need,
and when some laws require "suspension" they have not a clear idea of
what is it, actually.

I wonder how many "non-ad-hoc" applications actually know how to correctly
handle suspension... we are still facing interoperability issues between
PKIs with respect to this issue, I guess...

Later,
Max

Ignacio Alamillo wrote:

        </pre>
        <blockquote type="cite">
          <pre wrap="">Under Spanish law, suspension is a legal requirement (not a strictly
enforced one, but a requirement after all) and therefore many CA have
implemented it, and it is actually used.

          </pre>
        </blockquote>
        <pre wrap="">   

        </pre>
      </blockquote>
      <pre wrap=""> 

      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>

Date: Thu, 24 Jan 2008 12:00:47 +0100
From: Johannes Merkle <[email-masked]>
To: Alfredo Esposito <[email-masked]>
CC: Massimiliano Pala <[email-masked]>, Ignacio Alamillo <[email-masked]>, [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

Hi Dino,

non-english speaking countries hardly use the term "suspension" in
their laws. Furthermore, the requirements imposed by the law usually
do not refer to any standards or technical solutions. This is
particularly true within the EU where electronic signatures do not
even need to deploy digital signatures.

Your appreciation regarding the source of the problems seems to
match mine: It's the limitation of technical standards to meet the
logical requirements of the legislation. (At least as long as SCVP
is not widely used.)

However, I disagree that a signature created while the certificate
was on hold must necessarily be considered invalid. This is a matter
of the certificate policy, and there are application scenarios for
suspension (reaction to unauthenticated revocation requests) where
such signatures could be regarded valid after reinstating of the
certificate. However, I do not advocate suspension as revocation and
potential certificate renewal is a better solution.

By the way: Here in Germany, suspension of qualified certificates is
considered inadmissable (at least by the supervising authority),
although there are no explicit requirements in the law and ordinance.

Johannes

Alfredo Esposito schrieb am 24.01.2008 11:35:
> Hi Johannes
> In my experience who write down the laws has often a poor understanding
> of technical issues; therefore some words that have a very special
> meaning in a technical specification are instead used in their general
> meaning, causing a bit of confusion.
> Suspension is one of these words, because a document signed during the
> suspension should be "legally invalid" but there is no standard way of
> checking a past CRL (i.e. verifying a signature at some time t<<now).
> Better, there are some ways (ETSI specifications on advanced signatures,
> putting the CRL in the PKCS#7 envelope) but none is generally adopted.
> On the other hand, the PKI standards were developed well in advance of
> the legal concept of electronic signature, a concept that is still
> unclear in Europe, in spite of the EU Directive of 8 years ago
> 
> Dino Esposito
> 
> Johannes Merkle wrote:
> 
>>Hi Massimiliano,
>>
>>most signature laws I have seen so far had a quite clear
>>understanding of what they require. The problems arise from the
>>limitations in the technical implementations of their logical
>>requirements.
>>
>>Johannes
>>
>>Massimiliano Pala schrieb am 23.01.2008 20:20:
>>  
>>
>>>Hi all,
>>>
>>>I guess that the problem with the current PKIX solution on suspension is
>>>that it is just an extended revocation status - this means that it is
>>>just a sub-case of revocation. In many cases this is not what you need,
>>>and when some laws require "suspension" they have not a clear idea of
>>>what is it, actually.
>>>
>>>I wonder how many "non-ad-hoc" applications actually know how to correctly
>>>handle suspension... we are still facing interoperability issues between
>>>PKIs with respect to this issue, I guess...
>>>
>>>Later,
>>>Max
>>>
>>>
>>>
>>>Ignacio Alamillo wrote:
>>>
>>>    
>>>
>>>>Under Spanish law, suspension is a legal requirement (not a strictly
>>>>enforced one, but a requirement after all) and therefore many CA have
>>>>implemented it, and it is actually used.
>>>>      
>>>>
>>>    
>>>
>>
>>  
>>

-- 
Viele Grüße,
Johannes Merkle

Date: Thu, 24 Jan 2008 11:35:30 +0100
From: Alfredo Esposito <[email-masked]>
To: Johannes Merkle <[email-masked]>
CC: Massimiliano Pala <[email-masked]>, Ignacio Alamillo <[email-masked]>, [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Johannes<br>
In my experience who write down the laws has often a poor understanding
of technical issues; therefore some words that have a very special
meaning in a technical specification are instead used in their general
meaning, causing a bit of confusion.<br>
Suspension is one of these words, because a document signed during the
suspension should be "legally invalid" but there is no standard way of
checking a past CRL (i.e. verifying a signature at some time
t&lt;&lt;now). Better, there are some ways (ETSI specifications on
advanced signatures, putting the CRL in the PKCS#7 envelope) but none
is generally adopted. <br>
On the other hand, the PKI standards were developed well in advance of
the legal concept of electronic signature, a concept that is still
unclear in Europe, in spite of the EU Directive of 8 years ago<br>
<br>
Dino Esposito<br>
<br>
Johannes Merkle wrote:
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">Hi Massimiliano,

most signature laws I have seen so far had a quite clear
understanding of what they require. The problems arise from the
limitations in the technical implementations of their logical
requirements.

Johannes

Massimiliano Pala schrieb am 23.01.2008 20:20:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi all,

I guess that the problem with the current PKIX solution on suspension is
that it is just an extended revocation status - this means that it is
just a sub-case of revocation. In many cases this is not what you need,
and when some laws require "suspension" they have not a clear idea of
what is it, actually.

I wonder how many "non-ad-hoc" applications actually know how to correctly
handle suspension... we are still facing interoperability issues between
PKIs with respect to this issue, I guess...

Later,
Max

Ignacio Alamillo wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">Under Spanish law, suspension is a legal requirement (not a strictly
enforced one, but a requirement after all) and therefore many CA have
implemented it, and it is actually used.
      </pre>
    </blockquote>
    <pre wrap="">
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>

Date: Thu, 24 Jan 2008 10:46:18 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Certificate suspension
Sender: [email-masked]

Russ and Todd,

I do not share your opinions.

>The U.S. Treasury does not support suspension mainly due to obvious 
>issues encountered with digital signature related transactions, and 
>future validation of those transactions.  The problem is, if you are 
>willing to honor signatures produced using certificates from an 
>infrastructure that does support suspension, you wind up in the same 
>boat.  It has been a topic of much debate.

At the very begining, I was reluctant to support suspension, but there is no security flaw 
both for authentication and for non repudiation.

In general, if a relying party application does not support suspension, 
then it will treat suspension as (definitively) revoked.

In the case of non repudiation (which mandates the use of either a time-stamping or 
a time-marking mechanism) there is however a slight difference:

 - If the relying party application supports suspension, the (electronic) signature will be considered 
   as (temporary) invalid. In some cases, it MAY try again *at a later time* to gather new revocation 
   information which demonstrate that the electronic signature is *now* valid. These applications 
   may thus know when it is no more necessary to attempt to validate temporary invalid signatures. 

 - If the relying party application does not support suspension, 
   the (electronic) signature will usually be considered as (definitiveley) invalid. 

   However, this class of applications could be designed to support suspension, without supporting 
   the suspension extension. The relying party application MAY attempt to validate at a later time,
   e.g. two or three days later, electronic signatures that were invalid because the signer's certificate 
   was revoked. So they may end up  with the same result, but not necessarilly within the same time frame.

Denis 

>Russ Housley wrote:
 
>> I have said many times that I wish we had deprecated certificate 
>> suspension in RFC 2459 and all of its successors.  As you say, it is 
>> riddled with difficulties, and those have been discussed many times over 
>> the years.
>> 
>> When we were working on RFC 2459 someone from the financial community 
>> argued that it was needed.  So, it was not deprecated.   You can look at 
>> the archives for the recurring discussion.
>> 
>> Russ
>> 
>-- 
>Regards,
>
>Todd E. Johnson

Date: Thu, 24 Jan 2008 09:55:33 +0100
From: Johannes Merkle <[email-masked]>
To: Massimiliano Pala <[email-masked]>
CC: Ignacio Alamillo <[email-masked]>, [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

Hi Massimiliano,

most signature laws I have seen so far had a quite clear
understanding of what they require. The problems arise from the
limitations in the technical implementations of their logical
requirements.

Johannes

Massimiliano Pala schrieb am 23.01.2008 20:20:
> Hi all,
> 
> I guess that the problem with the current PKIX solution on suspension is
> that it is just an extended revocation status - this means that it is
> just a sub-case of revocation. In many cases this is not what you need,
> and when some laws require "suspension" they have not a clear idea of
> what is it, actually.
> 
> I wonder how many "non-ad-hoc" applications actually know how to correctly
> handle suspension... we are still facing interoperability issues between
> PKIs with respect to this issue, I guess...
> 
> Later,
> Max
> 
> 
> 
> Ignacio Alamillo wrote:
> 
>> Under Spanish law, suspension is a legal requirement (not a strictly
>> enforced one, but a requirement after all) and therefore many CA have
>> implemented it, and it is actually used.
> 
> 

-- 
Viele Grüße,
Johannes Merkle

From: "Dollie Prince" <[email-masked]>
To: <[email-masked]>
Subject: MauraSignificantPenis
Date: Thu, 24 Jan 2008 11:22:13 +0300
Importance: Normal

EnlargedPhallusTruman
http://www.junioeres.com

From: <[email-masked]>
To: <[email-masked]>
Subject: rfc3280bis change requested
Date: Wed, 23 Jan 2008 21:17:43 -0800
Sender: [email-masked]

I believe that in section 4.2 there needs to be a statement added to the
effect that extensions MUST be encoded using DER and stored in that encoding
in the extnValue field.

The following scenario demonstrates why I believe this statement needs to be
added.

1.  Assume Alice is a CA and places a private extension in every certificate
that is issued.

2.  Alice creates the certificate using DER encoding throughout, hashes and
signs.

3.  Alice then re-encodes the entire certificate using BER indefinite
encoding (for unknown reasons) and passes the certificate to Bob

4.  Bob attempts to change the encoding of the certificate from BER
indefinite to DER and cannot always do so for the private extension unless
he also knows the syntax associated with it.  Bob will not be able to a)
remove all default values and b) recognize all SET types and sort them.

Example

PrivateExtension ::= SEQUENCE {
       bool   BOOLEAN DEFAULT FALSE,
       iSet   [0] IMPLICIT SET OF INTEGER
}

Jim

Date: Wed, 23 Jan 2008 22:51:18 -0500
From: "Todd E. Johnson" <[email-masked]>
To: Scott Rea <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

Not quite "ambivalent", since it is specific to prohibit suspension of 
CA certificates and leaves no binding requirements on the implementor 
for end entity certificates, but states that it is allowed.

I feel the ability to suspend technically, not the requirements of any 
particular policy, has compelled organizations to provide for a counter 
signing process when performing a digital signature transaction.  It is 
perceived that it helps to capture the validity of the signers 
certificate, at the time of signing, for future validation.  That is, if 
that organization ever choses to honor certificates from CAs whom 
support suspension.

Technical suspension is a completely useful tool in the world of 
authentication and authorization.

Scott Rea wrote:
> Yet the Shared Service Provider for both HHS and VA does support 
> suspension and the Federal Common Policy Framework CP is ambivalent on 
> this point - allowing each agency to choose
> -Scott
> 
> Todd E. Johnson wrote:
>>
>> The U.S. Treasury does not support suspension mainly due to obvious 
>> issues encountered with digital signature related transactions, and 
>> future validation of those transactions.  The problem is, if you are 
>> willing to honor signatures produced using certificates from an 
>> infrastructure that does support suspension, you wind up in the same 
>> boat.  It has been a topic of much debate.
>>

-- 

Regards,

Todd E. Johnson

Date: Wed, 23 Jan 2008 20:51:16 -0500
From: Scott Rea <[email-masked]>
To: "Todd E. Johnson" <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

Yet the Shared Service Provider for both HHS and VA does support 
suspension and the Federal Common Policy Framework CP is ambivalent on 
this point - allowing each agency to choose
-Scott

Todd E. Johnson wrote:
>
> The U.S. Treasury does not support suspension mainly due to obvious 
> issues encountered with digital signature related transactions, and 
> future validation of those transactions.  The problem is, if you are 
> willing to honor signatures produced using certificates from an 
> infrastructure that does support suspension, you wind up in the same 
> boat.  It has been a topic of much debate.
>
> Russ Housley wrote:
>>
>> I have said many times that I wish we had deprecated certificate 
>> suspension in RFC 2459 and all of its successors.  As you say, it is 
>> riddled with difficulties, and those have been discussed many times 
>> over the years.
>>
>> When we were working on RFC 2459 someone from the financial community 
>> argued that it was needed.  So, it was not deprecated.   You can look 
>> at the archives for the recurring discussion.
>>
>> Russ
>>

Date: Wed, 23 Jan 2008 20:27:28 -0500
From: "Todd E. Johnson" <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

The U.S. Treasury PKI does not support suspension mainly due to obvious 
issues encountered with digital signature related transactions, and 
future validation of those transactions.

The problem is, if you are willing to honor signatures produced using 
certificates from an infrastructure that does support suspension, you 
wind up in the same boat.  It has been a topic of much debate.

Russ Housley wrote:
> 
> I have said many times that I wish we had deprecated certificate 
> suspension in RFC 2459 and all of its successors.  As you say, it is 
> riddled with difficulties, and those have been discussed many times over 
> the years.
> 
> When we were working on RFC 2459 someone from the financial community 
> argued that it was needed.  So, it was not deprecated.   You can look at 
> the archives for the recurring discussion.
> 
> Russ

-- 

Regards,

Todd E. Johnson

Date: Wed, 23 Jan 2008 19:45:05 -0500
From: "Todd E. Johnson" <[email-masked]>
To: [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

The U.S. Treasury does not support suspension mainly due to obvious 
issues encountered with digital signature related transactions, and 
future validation of those transactions.  The problem is, if you are 
willing to honor signatures produced using certificates from an 
infrastructure that does support suspension, you wind up in the same 
boat.  It has been a topic of much debate.

Russ Housley wrote:
> 
> I have said many times that I wish we had deprecated certificate 
> suspension in RFC 2459 and all of its successors.  As you say, it is 
> riddled with difficulties, and those have been discussed many times over 
> the years.
> 
> When we were working on RFC 2459 someone from the financial community 
> argued that it was needed.  So, it was not deprecated.   You can look at 
> the archives for the recurring discussion.
> 
> Russ
> 
-- 

Regards,

Todd E. Johnson

From: "Anders Rundgren" <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Cc: "pkix" <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Date: Thu, 24 Jan 2008 00:42:46 +0100
Sender: [email-masked]

Dave,
I think you are touching another issue, SAN is not always used
( https://www.verisign.com ) and for wildcards it does not make
sense to use it either since all clients understand CN.
For multiple discrete hosts SAN is of course used.

Home-brewed wild-card certificate (which apparently
is accepted by Microsoft's CardSpace):
https://infocard.pingidentity.com/cardspace/

If your desire is outlawing wildcards in SAN I guess you have
no problem but OTOH I don't see that you got rid of *.domains
which I thought was the prime consideration.

Anders

----- Original Message ----- 
From: "David A. Cooper" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sent: Thursday, January 24, 2008 00:19
Subject: Re: Wildcard DNS. Re: rfc 3280bis

Can you confirm that these wildcard SSL certificates include the DNS 
name in the dNSName field of the subjectAltName extension rather than in 
a common name attribute in the subject field?  I could not find any 
wildcard certificates, but the web site implies that the common name 
attribute is used in the wildcard SSL certificates and that the 
subjectAltName extension does not include DNS names with wildcards.

Dave

Anders Rundgren wrote:
> Certificates with wildcards are fairly widely used because they
> can save you both hassles and money.
>
> Issuer: https://www.godaddy.com/gdshop/ssl/ssl.asp?ci=8979  A major issuer of SSL certs.
>
> That is, it does not matter what 3280bis says, this is de-facto standard
> and I doubt that Microsoft intends to remove support for this in MSIE.
>
> If an issuer creates a certificate for *.com it is a bad issuer while
> *.mycompany.com is ok.  Bad issuers don't have their roots
> deployed in browsers so I don't see what the problem is.  If
> you have bad issuers nothing really helps.
>
> Anders
>
>
>   

Date: Wed, 23 Jan 2008 18:19:58 -0500
From: "David A. Cooper" <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Sender: [email-masked]

Can you confirm that these wildcard SSL certificates include the DNS 
name in the dNSName field of the subjectAltName extension rather than in 
a common name attribute in the subject field?  I could not find any 
wildcard certificates, but the web site implies that the common name 
attribute is used in the wildcard SSL certificates and that the 
subjectAltName extension does not include DNS names with wildcards.

Dave

Anders Rundgren wrote:
> Certificates with wildcards are fairly widely used because they
> can save you both hassles and money.
>
> Issuer: https://www.godaddy.com/gdshop/ssl/ssl.asp?ci=8979  A major issuer of SSL certs.
>
> That is, it does not matter what 3280bis says, this is de-facto standard
> and I doubt that Microsoft intends to remove support for this in MSIE.
>
> If an issuer creates a certificate for *.com it is a bad issuer while
> *.mycompany.com is ok.  Bad issuers don't have their roots
> deployed in browsers so I don't see what the problem is.  If
> you have bad issuers nothing really helps.
>
> Anders
>
>
>   

From: "Anders Rundgren" <[email-masked]>
To: "pkix" <[email-masked]>
Subject: Wildcard DNS. Re: rfc 3280bis
Date: Wed, 23 Jan 2008 22:08:53 +0100
Sender: [email-masked]

Certificates with wildcards are fairly widely used because they
can save you both hassles and money.

Issuer: https://www.godaddy.com/gdshop/ssl/ssl.asp?ci=8979  A major issuer of SSL certs.

That is, it does not matter what 3280bis says, this is de-facto standard
and I doubt that Microsoft intends to remove support for this in MSIE.

If an issuer creates a certificate for *.com it is a bad issuer while
*.mycompany.com is ok.  Bad issuers don't have their roots
deployed in browsers so I don't see what the problem is.  If
you have bad issuers nothing really helps.

Anders

Date: Wed, 23 Jan 2008 15:19:02 -0500
To: Stephen Wilson <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Certificate suspension
Sender: [email-masked]

I have said many times that I wish we had deprecated certificate 
suspension in RFC 2459 and all of its successors.  As you say, it is 
riddled with difficulties, and those have been discussed many times 
over the years.

When we were working on RFC 2459 someone from the financial community 
argued that it was needed.  So, it was not deprecated.   You can look 
at the archives for the recurring discussion.

Russ

At 08:49 PM 1/22/2008, Stephen Wilson wrote:

>I'm wondering to what extent is X.509 certificate suspension used in practice?
>
>Most if not all publicly visible CPs describe suspension, in almost 
>exactly the same way as they do revocation.  Yet in my experience, I 
>cannot ever recall a commercial CA or a closed/vertical PKI actually 
>doing suspensions.
>
>To my mind, suspension is riddled with difficulties, not anticipated 
>by the way CRLs work.  I could go into my concerns in a separate 
>e-mail. But if anyone can point to suspension being offered in 
>practice (or failing that, a critique of suspension) that would be appreciated!
>
>Thanks in advance.
>
>Cheers,
>
>Stephen Wilson
>Managing Director
>Lockstep
>
>Phone +61 (0)414 488 851
>
>www.lockstep.com.au
>-------------------
>  * Lockstep Technologies: ICT Secrets of Innovation Finalist 2007
>  * Lockstep Technologies: Anthill / PwC Cool Company Finalist 2007
>-------------------
>Lockstep Consulting provides independent specialist advice and analysis
>on authentication, PKI and smartcards.  Lockstep Technologies develops
>unique new smart ID solutions that safeguard identity and privacy.
>
>
>

Date: Wed, 23 Jan 2008 14:20:37 -0500
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: Ignacio Alamillo <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Hi all,

I guess that the problem with the current PKIX solution on suspension is
that it is just an extended revocation status - this means that it is
just a sub-case of revocation. In many cases this is not what you need,
and when some laws require "suspension" they have not a clear idea of
what is it, actually.

I wonder how many "non-ad-hoc" applications actually know how to correctly
handle suspension... we are still facing interoperability issues between
PKIs with respect to this issue, I guess...

Later,
Max

Ignacio Alamillo wrote:
> Under Spanish law, suspension is a legal requirement (not a strictly
> enforced one, but a requirement after all) and therefore many CA have
> implemented it, and it is actually used.

-- 

Best Regards,

	Massimiliano Pala

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

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 063                        Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

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

--------------ms040509080000000403060004--

Content-class: urn:content-classes:message
Subject: RE: Certificate suspension
Date: Wed, 23 Jan 2008 10:58:27 -0800
From: "Andrews, Rick" <[email-masked]>
To: "Stephen Wilson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Stephen,

VeriSign has supported suspension in only one case that I know of, where
we were issuing certs to be used with Identrus-compliant applications.
No one else requests it.

-Rick 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Wilson
> Sent: Tuesday, January 22, 2008 5:50 PM
> To: [email-masked]
> Subject: Certificate suspension
> 
> 
> 
> I'm wondering to what extent is X.509 certificate suspension 
> used in practice?
> 
> Most if not all publicly visible CPs describe suspension, in 
> almost exactly the same way as they do revocation.  Yet in my 
> experience, I cannot ever recall a commercial CA or a 
> closed/vertical PKI actually doing suspensions.
> 
> To my mind, suspension is riddled with difficulties, not 
> anticipated by the way CRLs work.  I could go into my 
> concerns in a separate e-mail. 
> But if anyone can point to suspension being offered in 
> practice (or failing that, a critique of suspension) that 
> would be appreciated!
> 
> Thanks in advance.
> 
> Cheers,
> 
> Stephen Wilson
> Managing Director
> Lockstep
> 
> Phone +61 (0)414 488 851
> 
> www.lockstep.com.au
> -------------------
>   * Lockstep Technologies: ICT Secrets of Innovation Finalist 2007
>   * Lockstep Technologies: Anthill / PwC Cool Company Finalist 2007
> -------------------
> Lockstep Consulting provides independent specialist advice 
> and analysis on authentication, PKI and smartcards.  Lockstep 
> Technologies develops unique new smart ID solutions that 
> safeguard identity and privacy.
> 
> 
> 
> 

Date: Wed, 23 Jan 2008 11:46:06 -0500
To: Alfredo Esposito <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: rfc 3280bis
Cc: Stefan Santesson <[email-masked]>, Peter Sylvester <[email-masked]>, "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

At 5:20 PM +0100 1/23/08, Alfredo Esposito wrote:
>If a certifcate has to bind a person/object/server/device to a 
>public key, what does a wildcard name mean?
>
>Dino Esposito

Exactly.

Wildcard DNS naming is intended to communicate the notion that the 
cert Subject is authorized to represent a range of DNS names.  I 
dislike this because it is taking DNS syntax and misusing it.  Note 
that for IP addresses, another form of alt name, we created a new 
extension in RFC 3779 to explicitly represent authorization for 
addresses and to express ranges of such addresses.  We also defined 
extensions to cert path validation to describe how to process these 
extensions in a cert path. If we want to do the same for DNS names, 
we have an example of a way to do this, rather than trying to hack 
the DNS alt name representation and NOT providing explicit semantics 
for the result.

Steve

Date: Wed, 23 Jan 2008 11:47:59 -0500
To: "Terwilliger, Ann" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Certificate suspension
Cc: "Stephen Wilson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 8:28 AM -0800 1/23/08, Terwilliger, Ann wrote:
>Actually we do use suspension.  It gives us a means of preventing the
>certificate from being relied upon (assuming of course that the relying
>party application recognizes the 'on hold' entry in the CRL) while we
>complete the investigation to see if there really is a valid reason to
>revoke the certificate.  By suspending the certificate we still have the
>option to reinstate it without requiring the certificate requestor to
>generate a new key pair/certificate request.

A new cert request need not entail a new key pair.  The bundling of 
these two makes the process more painful for the Subject, and thus 
provides greater justification for suspension vs. revocation, but 
such bundling is NOT required by the standards.

Steve

Date: Wed, 23 Jan 2008 11:36:59 -0500
From: "David A. Cooper" <[email-masked]>
To: Stefan Santesson <[email-masked]>, Peter Sylvester <[email-masked]>, Stephen Kent <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: rfc 3280bis
Sender: [email-masked]

Stefan Santesson wrote:
> I agree to the change proposals before this one.
>
> I would not oppose the wildcard amendment either IF it turns out to be non-controversial to include the change.
> "*" is indeed used in commercial certificates today, so it definitely represents a real need.
>   

First I would like to note that RFC 5055 (SCVP) is not relevant to this 
discussion.  RFC 5055 refers to the use of wildcards in the name 
specified in the request message, not the name in the target certificate.

While I am neither for nor against allowing wildcards in the dNSName 
field, it does seem like too big of a change to be making to the 
document this late in the process.  Making this change would require 
changes to several sections of the document and a number of questions 
would need to be answered before the change could be made:

1)  What would the rules be for allowing wildcard characters?  Which of 
the following would be acceptable: *.a.com, f*.com, foo.*.com, ...?

2) How should name constraints be processed when wildcard characters are 
present?  The current text states the following:

   DNS name restrictions are expressed as host.example.com.  Any DNS
   name that can be constructed by simply adding zero or more subdomains
   to the left hand side of the name satisfies the name constraint.  For
   example, www.host.example.com would satisfy the constraint but
   host1.example.com would not.

Would a subjectAltName of *.example.com fall within the subtree of 
host.example.com?  Would it depend on whether it were a permitted or 
excluded subtree?

We would also need to change the rules for comparing DNS names in 
section 7.2, which currently states:

   When comparing DNS names for equality, conforming implementations
   MUST perform a case-insensitive exact match on the entire DNS name.

At the same time, I can understand Stefan's argument that wildcard 
characters are used in certificates today.  I did a search for the 
string "dNSName" in all of the RFCs and found several that mention the 
use of wildcard characters (relevant text is quoted below).  Several of 
the RFCs state that wildcard characters may be included in the dNSName 
field of a certificate's subjectAltName extension.  A few state that 
wildcard characters must not be considered a match, but that is not the 
same as implying that no certificates are permitted to include a 
wildcard character.  The closest (non-PKIX) RFC that comes to stating 
that the dNSName should not include a wildcard character is RFC 5018, 
which suggests that a wildcard character would only appear if the DNS 
name appeared in a common name attribute in the subject field.

It is not clear that all of these RFCs agree on how the wildcard 
character may be used.  RFC 2818 and RFC 5018 (for the common name 
attribute) explicitly allow a name of the form f*.com.  However, most of 
the RFCs say that a wildcard may only be used as the left-most DNS 
label.  Does that really mean that the wildcard may only be used in the 
left-most DNS label, in which case f*.com would be acceptable, or does 
it mean that when a wildcard character is used the left-most DNS label 
must contain nothing but the wildcard character?  If 3280bis were to 
allow wildcard characters, should the language from RFC 2818 be used or 
the more restrictive language from other RFCs?

I don't particularly like the idea that there are a number of RFCs that 
permit inclusion of wildcard characters when the PKIX profile does not, 
but I wouldn't want 3280bis to be held up waiting for this issue to be 
resolved.

Dave

----------------------------------------------------------------------------------
RFC 2818 (HTTP Over TLS), section 3.1 (Server Identity) [Note: this is 
an Informational RFC]

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

RFC 3501 (INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1), section 
11.1 (STARTTLS Security Considerations)

        If a subjectAltName extension of type dNSName is present in
        the certificate, it SHOULD be used as the source of the
        server's identity.

        Matching is case-insensitive.

        A "*" wildcard character MAY be used as the left-most name
        component in the certificate.  For example, *.example.com
        would match a.example.com, foo.example.com, etc. but would
        not match example.com.

RFC 4513 (Lightweight Directory Access Protocol (LDAP): Authentication 
Methods and Security Mechanisms), section 3.1.3.1 (Comparison of DNS Names)

   The '*' (ASCII 42) wildcard character is allowed in subjectAltName
   values of type dNSName, and then only as the left-most (least
   significant) DNS label in that value.  This wildcard matches any
   left-most DNS label in the server name.  That is, the subject
   *.example.com matches the server names a.example.com and
   b.example.com, but does not match example.com or a.b.example.com.

RFC 4572 (Connection-Oriented Media Transport over the Transport Layer 
Security (TLS) Protocol in the Session Description Protocol (SDP)), 
section 6.1 (Certificate Choice)

      Similarly, if the connection address for the media description is
      specified as a fully-qualified domain name, the endpoint MAY use a
      certificate with a dNSName subjectAltName matching the specified
      'c' line connection-address exactly.  (Wildcard patterns MUST NOT
      be used.)

RFC 4642 (Using Transport Layer Security (TLS) with Network News 
Transfer Protocol (NNTP)), section 5 (Security Considerations)

   -  If a subjectAltName extension of type dNSName is present in the
      certificate, it SHOULD be used as the source of the server's
      identity.

   -  Matching is case-insensitive.

   -  A "*" wildcard character MAY be used as the left-most name
      component in the certificate.  For example, *.example.com would
      match a.example.com, foo.example.com, etc., but would not match
      example.com.

RFC 4712 (Transport Mappings for Real-time Application 
Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)), 
section 2.2.1.5 (Server Identity Check)

   Matching is performed according to these rules:

   o  The client MUST use the server dnsNAME in the subjectAltName field
      to validate the server certificate presented.  The server dnsName
      MUST be part of subjectAltName of the server.

   o  Matching is case-insensitive.

   o  The "*" wildcard character is allowed.  If present, it applies
      only to the left-most name component.

      For example, *.example.com would match a.example.com,
      b.example.com, etc., but not example.com.  If more than one
      identity of a given type is present in the certificate (e.g., more
      than one dNSName name), a match in any one of the set is
      considered acceptable.

RFC 4945 (The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, 
and PKIX), section 3.1.2 (ID_FQDN)

   When comparing the contents of ID with the dNSName field in the
   SubjectAltName extension for equality, case-insensitive string
   comparison MUST be performed.  Note that case-insensitive string
   comparison works on internationalized domain names (IDNs) as
   well (See IDN [12]).  Substring, wildcard, or regular expression
   matching MUST NOT be performed for this comparison.

RFC 4954 (SMTP Service Extension for Authentication), section 14 
(Additional Requirements When Using SASL PLAIN over TLS)

        If a subjectAltName extension of type dNSName is present in the
        certificate, it SHOULD be used as the source of the server's
        identity.

        Matching is case-insensitive.

        A "*" wildcard character MAY be used as the leftmost name
        component in the certificate.  For example, *.example.com would
        match a.example.com, foo.example.com, etc., but would not match
        example.com.

RFC 5018 (Connection Establishment in the Binary Floor Control Protocol 
(BFCP)), section 5.1 (Certificate-Based Server Authentication)

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity.  Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used.  Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the subjectAltName
   instead.

   Matching is performed using the matching rules specified by
   [RFC3280].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name), a match in any
   one of the set is considered acceptable.  Names in Common Name fields
   may contain the wildcard character *, which is considered to match
   any single domain name component or component fragment (e.g., *.a.com
   matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but
   not bar.com).

Content-class: urn:content-classes:message
Subject: RE: Certificate suspension
Date: Wed, 23 Jan 2008 08:28:47 -0800
From: "Terwilliger, Ann" <[email-masked]>
To: "Stephen Wilson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Actually we do use suspension.  It gives us a means of preventing the
certificate from being relied upon (assuming of course that the relying
party application recognizes the 'on hold' entry in the CRL) while we
complete the investigation to see if there really is a valid reason to
revoke the certificate.  By suspending the certificate we still have the
option to reinstate it without requiring the certificate requestor to
generate a new key pair/certificate request.  

Ann Terwilliger, CISSP | Product Director|
Visa Incorporated| 650.432.3661

NOTICE
This email message and any attachments are intended only for the use of
the addressee named above and may contain information that is privileged
and confidential.  If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited.  If you
received this email message in error, please immediately notify the
sender by replying to this email message or by telephone to the Visa
switchboard at 1(650) 432-3200.  Thank you.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Wilson
Sent: Tuesday, January 22, 2008 5:50 PM
To: [email-masked]
Subject: Certificate suspension

I'm wondering to what extent is X.509 certificate suspension used in 
practice?

Most if not all publicly visible CPs describe suspension, in almost 
exactly the same way as they do revocation.  Yet in my experience, I 
cannot ever recall a commercial CA or a closed/vertical PKI actually 
doing suspensions.

To my mind, suspension is riddled with difficulties, not anticipated by 
the way CRLs work.  I could go into my concerns in a separate e-mail. 
But if anyone can point to suspension being offered in practice (or 
failing that, a critique of suspension) that would be appreciated!

Thanks in advance.

Cheers,

Stephen Wilson
Managing Director
Lockstep

Phone +61 (0)414 488 851

www.lockstep.com.au
-------------------
  * Lockstep Technologies: ICT Secrets of Innovation Finalist 2007
  * Lockstep Technologies: Anthill / PwC Cool Company Finalist 2007
-------------------
Lockstep Consulting provides independent specialist advice and analysis
on authentication, PKI and smartcards.  Lockstep Technologies develops
unique new smart ID solutions that safeguard identity and privacy.

Date: Wed, 23 Jan 2008 17:20:08 +0100
From: Alfredo Esposito <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Stefan Santesson <[email-masked]>, Peter Sylvester <[email-masked]>, "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Subject: Re: rfc 3280bis
Sender: [email-masked]

If a certifcate has to bind a person/object/server/device to a public 
key, what does a wildcard name mean?

Dino Esposito

Stephen Kent wrote:
>
> At 2:52 PM +0000 1/23/08, Stefan Santesson wrote:
>> I agree to the change proposals before this one.
>>
>> I would not oppose the wildcard amendment either IF it turns out to 
>> be non-controversial to include the change.
>> "*" is indeed used in commercial certificates today, so it definitely 
>> represents a real need.
>>
>>
>> Stefan Santesson
>> Senior Program Manager
>> Windows Security, Standards
>
> I do oppose the DNS wild card proposal. We had extensive discussions 
> about this years ago. The "*" character is not valid in a DNS name, 
> and so a cert that carries a DNS name as an alt name ought not use 
> this convention.
>
> Steve
>
>

Date: Wed, 23 Jan 2008 17:18:02 +0100
From: Alfredo Esposito <[email-masked]>
To: Johannes Merkle <[email-masked]>
CC: Stephen Wilson <[email-masked]>, [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
For the Italian law the CSP SHALL manage suspension, with a cumbersome
charge of related issues.<br>
regards<br>
Dino Esposito<br>
<br>
Johannes Merkle wrote:
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">Stephen,

for the Austrian social insurance card (e-card) two kind of
certificates are offered, which can only be suspended. If not
un-suspended within 72 hours, they are revoked. The reason for this
is that the card issuer was afraid of too many people temporarily
mislaying their cards and requesting revocation.

If you know German or know someone to translate, here is the CPS:
<a class="moz-txt-link-freetext" href="http://www.signatur.rtr.at/repository/csp-hauptverband-cps-vsig-092-20060726-de.pdf">http://www.signatur.rtr.at/repository/csp-hauptverband-cps-vsig-092-20060726-de.pdf</a>

regards,
Johannes Merkle

Stephen Wilson schrieb am 23.01.2008 02:49:
  </pre>
  <blockquote type="cite">
    <pre wrap="">
I'm wondering to what extent is X.509 certificate suspension used in
practice?

Most if not all publicly visible CPs describe suspension, in almost
exactly the same way as they do revocation.  Yet in my experience, I
cannot ever recall a commercial CA or a closed/vertical PKI actually
doing suspensions.

To my mind, suspension is riddled with difficulties, not anticipated by
the way CRLs work.  I could go into my concerns in a separate e-mail.
But if anyone can point to suspension being offered in practice (or
failing that, a critique of suspension) that would be appreciated!

Thanks in advance.

Cheers,

Stephen Wilson
Managing Director
Lockstep

Phone +61 (0)414 488 851

<a class="moz-txt-link-abbreviated" href="http://www.lockstep.com.au">www.lockstep.com.au</a>
-------------------
 * Lockstep Technologies: ICT Secrets of Innovation Finalist 2007
 * Lockstep Technologies: Anthill / PwC Cool Company Finalist 2007
-------------------
Lockstep Consulting provides independent specialist advice and analysis
on authentication, PKI and smartcards.  Lockstep Technologies develops
unique new smart ID solutions that safeguard identity and privacy.

    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
</body>
</html>

Date: Wed, 23 Jan 2008 17:13:31 +0100
From: Peter Sylvester <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: rfc 3280bis
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

>
> SCVP uses wild characters for validationNames, not for names included i=
n certificates.
> Until I have clue to understand where "three additional lines" (which o=
nes ?) would be included=20
> in RFC 3280bis, I disagree.
>  =20
SCVP seems ambiguous in this sense.

Names may contain the wildcard character * which is considered to
   match any single domain name component.  That is, *.a.com matches
   foo.a.com but not bar.foo.a.com.

To me it is not clear what "Names" refer to because in the previous sente=
nces
'name' is used for both cases.=20

The name validation algorithm allows the client to specify one or
   more subject names that MUST appear in the end certificate in
   addition to the requirements specified for the basic validation
   algorithm.  The name validation algorithm allows the client to supply
   an application identifier and a name to the server.  The application
   identifier defines the name matching rules to use in comparing the
   name supplied in the request with the names in the certificate.

I have no problem not allowing wildcards in subjectAltName.=20

--=20
To verify the signature, see http://edelpki.edelweb.fr/=20
Cela vous permet de charger le certificat de l'autorit=E9;=20
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20

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

--------------ms080107080606040203030500--

From: Stefan Santesson <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Peter Sylvester <[email-masked]>, "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Date: Wed, 23 Jan 2008 15:39:35 +0000
Subject: RE: rfc 3280bis
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

So this proves to be controversial, as I suspected. This means I will also oppose this change in rfc3280bis.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: den 23 januari 2008 16:31
> To: Stefan Santesson
> Cc: Peter Sylvester; David A. Cooper; pkix
> Subject: RE: rfc 3280bis
>
> At 2:52 PM +0000 1/23/08, Stefan Santesson wrote:
> >I agree to the change proposals before this one.
> >
> >I would not oppose the wildcard amendment either IF it turns out to
> >be non-controversial to include the change.
> >"*" is indeed used in commercial certificates today, so it
> >definitely represents a real need.
> >
> >
> >Stefan Santesson
> >Senior Program Manager
> >Windows Security, Standards
>
> I do oppose the DNS wild card proposal.  We had extensive discussions
> about this years ago. The "*" character is not valid in a DNS name,
> and so a cert that carries a DNS name as an alt name ought not use
> this convention.
>
> Steve

Date: Wed, 23 Jan 2008 10:30:33 -0500
To: Stefan Santesson <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: rfc 3280bis
Cc: Peter Sylvester <[email-masked]>, "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

At 2:52 PM +0000 1/23/08, Stefan Santesson wrote:
>I agree to the change proposals before this one.
>
>I would not oppose the wildcard amendment either IF it turns out to 
>be non-controversial to include the change.
>"*" is indeed used in commercial certificates today, so it 
>definitely represents a real need.
>
>
>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards

I do oppose the DNS wild card proposal.  We had extensive discussions 
about this years ago. The "*" character is not valid in a DNS name, 
and so a cert that carries a DNS name as an alt name ought not use 
this convention.

Steve

Date: Wed, 23 Jan 2008 16:24:33 +0100
From: "Denis Pinkas" <[email-masked]>
To: "pkix" <[email-masked]>
Subject: Re: rfc 3280bis
Sender: [email-masked]

>I agree to the change proposals before this one.

>I would not oppose the wildcard amendment either IF it turns out to be non-controversial to include the change.
>"*" is indeed used in commercial certificates today, so it definitely represents a real need.

We should be very careful with "last minute" change proposals.

SCVP uses wild characters for validationNames, not for names included in certificates.
Until I have clue to understand where "three additional lines" (which ones ?) would be included 
in RFC 3280bis, I disagree.

Denis

>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:owner-ietf-
>> [email-masked]] On Behalf Of Peter Sylvester
>> Sent: den 16 januari 2008 13:46
>> To: Stephen Kent
>> Cc: David A. Cooper; pkix
>> Subject: Re: rfc 3280bis
>>
>> And what about '*.foo.net'?  I cite from SCVP.
>>
>>    If the nameCompAlgId supplied in the request is id-kp-serverAuth
>>    [PKIX-1 <http://tools.ietf.org/html/draft-ietf-pkix-scvp-32#ref-
>> PKIX-1>], then GeneralNames supplied in the request MUST be a
>>    dNSName, and the matching rules to be used are defined in [PKIX-1
>> <http://tools.ietf.org/html/draft-ietf-pkix-scvp-32#ref-PKIX-1>].
>>
>>    If a subjectAltName extension is present and includes one or more
>>    names of type dNSName, a match in any one of the set is considered
>>    acceptable.  If the subjectAltName extension is omitted, or does not
>>    include any names of type dNSName, the (most specific) Common Name
>>    field in the Subject field of the certificate MUST be used.
>>
>>    Names may contain the wildcard character * which is considered to
>>    match any single domain name component.  That is, *.a.com matches
>>    foo.a.com but not bar.foo.a.com.
>>
>>
>> I think that something like the three lines above should be included in
>> 3280bis?
>>
>>
>> Stephen Kent wrote:
>> >
>> > David,
>> >
>> > Then let's make this late minute fix, and keep Sam informed.
>> >
>> > Steve
>> >
>> >
>>
>>
>> --
>> To verify the signature, see http://edelpki.edelweb.fr/
>> Cela vous permet de charger le certificat de l'autorité;
>> die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
>>
>
>

Regards,

Denis Pinkas

From: Stefan Santesson <[email-masked]>
To: Peter Sylvester <[email-masked]>, Stephen Kent <[email-masked]>
CC: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Date: Wed, 23 Jan 2008 14:52:22 +0000
Subject: RE: rfc 3280bis
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I agree to the change proposals before this one.

I would not oppose the wildcard amendment either IF it turns out to be non-controversial to include the change.
"*" is indeed used in commercial certificates today, so it definitely represents a real need.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Peter Sylvester
> Sent: den 16 januari 2008 13:46
> To: Stephen Kent
> Cc: David A. Cooper; pkix
> Subject: Re: rfc 3280bis
>
> And what about '*.foo.net'?  I cite from SCVP.
>
>    If the nameCompAlgId supplied in the request is id-kp-serverAuth
>    [PKIX-1 <http://tools.ietf.org/html/draft-ietf-pkix-scvp-32#ref-
> PKIX-1>], then GeneralNames supplied in the request MUST be a
>    dNSName, and the matching rules to be used are defined in [PKIX-1
> <http://tools.ietf.org/html/draft-ietf-pkix-scvp-32#ref-PKIX-1>].
>
>    If a subjectAltName extension is present and includes one or more
>    names of type dNSName, a match in any one of the set is considered
>    acceptable.  If the subjectAltName extension is omitted, or does not
>    include any names of type dNSName, the (most specific) Common Name
>    field in the Subject field of the certificate MUST be used.
>
>    Names may contain the wildcard character * which is considered to
>    match any single domain name component.  That is, *.a.com matches
>    foo.a.com but not bar.foo.a.com.
>
>
> I think that something like the three lines above should be included in
> 3280bis?
>
>
> Stephen Kent wrote:
> >
> > David,
> >
> > Then let's make this late minute fix, and keep Sam informed.
> >
> > Steve
> >
> >
>
>
> --
> To verify the signature, see http://edelpki.edelweb.fr/
> Cela vous permet de charger le certificat de l'autorité;
> die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
>

Date: Wed, 23 Jan 2008 10:29:20 +0100
From: Johannes Merkle <[email-masked]>
To: Stephen Wilson <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate suspension
Sender: [email-masked]

Stephen,

for the Austrian social insurance card (e-card) two kind of
certificates are offered, which can only be suspended. If not
un-suspended within 72 hours, they are revoked. The reason for this
is that the card issuer was afraid of too many people temporarily
mislaying their cards and requesting revocation.

If you know German or know someone to translate, here is the CPS:
http://www.signatur.rtr.at/repository/csp-hauptverband-cps-vsig-092-20060726-de.pdf

regards,
Johannes Merkle

Stephen Wilson schrieb am 23.01.2008 02:49:
> 
> 
> I'm wondering to what extent is X.509 certificate suspension used in
> practice?
> 
> Most if not all publicly visible CPs describe suspension, in almost
> exactly the same way as they do revocation.  Yet in my experience, I
> cannot ever recall a commercial CA or a closed/vertical PKI actually
> doing suspensions.
> 
> To my mind, suspension is riddled with difficulties, not anticipated by
> the way CRLs work.  I could go into my concerns in a separate e-mail.
> But if anyone can point to suspension being offered in practice (or
> failing that, a critique of suspension) that would be appreciated!
> 
> Thanks in advance.
> 
> Cheers,
> 
> Stephen Wilson
> Managing Director
> Lockstep
> 
> Phone +61 (0)414 488 851
> 
> www.lockstep.com.au
> -------------------
>  * Lockstep Technologies: ICT Secrets of Innovation Finalist 2007
>  * Lockstep Technologies: Anthill / PwC Cool Company Finalist 2007
> -------------------
> Lockstep Consulting provides independent specialist advice and analysis
> on authentication, PKI and smartcards.  Lockstep Technologies develops
> unique new smart ID solutions that safeguard identity and privacy.
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: Certificate suspension
Date: Wed, 23 Jan 2008 10:27:29 +0100
From: "Ignacio Alamillo" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Under Spanish law, suspension is a legal requirement (not a strictly
enforced one, but a requirement after all) and therefore many CA have
implemented it, and it is actually used.

Best,

Ignacio Alamillo
Catalan Certification Authority

> -----Mensaje original-----
> De: [email-masked] 
> [mailto:[email-masked]] En nombre de Stephen Wilson
> Enviado el: dimecres, 23 / gener / 2008 02:50
> Para: [email-masked]
> Asunto: Certificate suspension
> 
> 
> 
> 
> I'm wondering to what extent is X.509 certificate suspension used in 
> practice?
> 
> Most if not all publicly visible CPs describe suspension, in almost 
> exactly the same way as they do revocation.  Yet in my experience, I 
> cannot ever recall a commercial CA or a closed/vertical PKI actually 
> doing suspensions.
> 
> To my mind, suspension is riddled with difficulties, not 
> anticipated by 
> the way CRLs work.  I could go into my concerns in a separate e-mail. 
> But if anyone can point to suspension being offered in practice (or 
> failing that, a critique of suspension) that would be appreciated!
> 
> Thanks in advance.
> 
> Cheers,
> 
> Stephen Wilson
> Managing Director
> Lockstep
> 
> Phone +61 (0)414 488 851
> 
www.lockstep.com.au
-------------------
  * Lockstep Technologies: ICT Secrets of Innovation Finalist 2007
  * Lockstep Technologies: Anthill / PwC Cool Company Finalist 2007
-------------------
Lockstep Consulting provides independent specialist advice and analysis
on authentication, PKI and smartcards.  Lockstep Technologies develops
unique new smart ID solutions that safeguard identity and privacy.

Cc: [email-masked]
From: Yoav Nir <[email-masked]>
To: Stephen Wilson <[email-masked]>
Subject: Re: Certificate suspension
Date: Wed, 23 Jan 2008 10:41:27 +0200
Sender: [email-masked]

If you browse the archives of this mailing list, you will find in late  
November and early December of 2007 a discussion of "on-hold  
certificates in CRLs"

Most appear to share your sentiments about suspension, but apparently  
there are some regulatory requirements that are satisfied by the  
possibility of suspension.

Yoav

On Jan 23, 2008, at 3:49 AM, Stephen Wilson wrote:

>
>
> I'm wondering to what extent is X.509 certificate suspension used in  
> practice?
>
> Most if not all publicly visible CPs describe suspension, in almost  
> exactly the same way as they do revocation.  Yet in my experience, I  
> cannot ever recall a commercial CA or a closed/vertical PKI actually  
> doing suspensions.
>
> To my mind, suspension is riddled with difficulties, not anticipated  
> by the way CRLs work.  I could go into my concerns in a separate e- 
> mail. But if anyone can point to suspension being offered in  
> practice (or failing that, a critique of suspension) that would be  
> appreciated!
>
> Thanks in advance.
>
> Cheers,
>
> Stephen Wilson

Date: Wed, 23 Jan 2008 12:49:47 +1100
From: Stephen Wilson <[email-masked]>
Organization: Lockstep
To: [email-masked]
Subject: Certificate suspension
Sender: [email-masked]

I'm wondering to what extent is X.509 certificate suspension used in 
practice?

Most if not all publicly visible CPs describe suspension, in almost 
exactly the same way as they do revocation.  Yet in my experience, I 
cannot ever recall a commercial CA or a closed/vertical PKI actually 
doing suspensions.

To my mind, suspension is riddled with difficulties, not anticipated by 
the way CRLs work.  I could go into my concerns in a separate e-mail. 
But if anyone can point to suspension being offered in practice (or 
failing that, a critique of suspension) that would be appreciated!

Thanks in advance.

Cheers,

Stephen Wilson
Managing Director
Lockstep

Phone +61 (0)414 488 851

www.lockstep.com.au
-------------------
  * Lockstep Technologies: ICT Secrets of Innovation Finalist 2007
  * Lockstep Technologies: Anthill / PwC Cool Company Finalist 2007
-------------------
Lockstep Consulting provides independent specialist advice and analysis
on authentication, PKI and smartcards.  Lockstep Technologies develops
unique new smart ID solutions that safeguard identity and privacy.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-pkix-ecc-subpubkeyinfo-01.txt 
Date: Tue, 22 Jan 2008 16:10:01 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : Elliptic Curve Cryptography Subject Public Key Information
	Author(s)       : S. Turner, et al.
	Filename        : draft-ietf-pkix-ecc-subpubkeyinfo-01.txt
	Pages           : 19
	Date            : 2008-01-22

This document specifies the syntax and semantics for the Subject 
Public Key Information field in certificates that support Elliptic 
Curve Cryptography.  This document updates [RFC3279].

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

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

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

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

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

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

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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-01.txt

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

Content-Type: text/plain
Content-ID:     <2008-01-22160312.I-D\@ietf.org>

--OtherAccess--

--NextPart--

From: Kay <[email-masked]>
To: [email-masked]
Subject: It on freedom
Date: Tue, 22 Jan 2008 11:52:55 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C85CED.53682D80
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

by technology always - modern techno conveniences such as the
virtual reality is being talked about this much when it probably some what =
alter my career plans.  I've felt like I have had to

------=_NextPart_000_0013_01C85CED.53682D80
Content-Type: text/html;
	charset="windows-1251"
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=
1">
<META content=3D"MSHTML 6.00.3790.1409" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<P><DIV>system called Tierra, which illustrated that evolution works just</=
DIV></P>
<P><DIV><font size=3D4>You can have a  bi/gg er  pe \nis </font></DIV></P>
<P><DIV><font size=3D3>As Se<SPAN>en On T </SPAN>V </font></DIV></P>
<DIV>Ov /er 715,000 Men aro /und the world are already sat \isfied</DIV>
<DIV>Gain 4+ Inc /hes In Len /gth</DIV>
<DIV>Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 21%</DIV>
<DIV>100% S \afe To Take, With NO Side Effe /cts</DIV>
<DIV>N o Pu \mps! N o Su \rgery! N o Exe \rcises! </DIV>
<P><DIV><A href=3D"http://geocities.com/forrestpayne537"><b><font size=3D5>=
Then and Now results</font></b></A></DIV></P>
<DIV>able to communicate the the idea to a broad audience but only in</DIV>=

</BODY></HTML>

------=_NextPart_000_0013_01C85CED.53682D80--

From: "Theresa Winter" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: business
Date: Tue, 22 Jan 2008 02:56:25 +0600

Life Should be Full of Luxuries
http://www.wrickecloth.com/

The finest of products, at the lowest of prices:
http://www.wrickecloth.com/

Regards,
Christina Connor

From: "Lane S. Leblanc" <[email-masked]>
To: "Tristan G. Browning" <[email-masked]>
Subject: Enjoy longer and harder erections!
Date: Mon, 21 Jan 2008 10:38:29 +0800

This is a multi-part message in MIME format.

------=_NextPart_20657_511B_01C85C19.C3372CD0
Content-Type: text/plain;
        charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Do You Want To Have Better Than The "Average" Penis Size?

- Discreet Shipping & Billing Worldwide
- 100% Satisfaction Guaranteed
- No Embarrassing Doctor Visits
- Enhance Your phallus Naturally
- No Pumps, No Weights, No Surgery
- 100% FDA Approved Conditions
=20
=20
The V=2EP=2EX=2EL program combines exercise techniques and a blend of nat=
ural herbal ingredients=20
which are known to improve sexual functions, increase of penis, and incre=
ase semen volume

2 Free Bottles For a Limited Time! Click Here to Order Online Now!
http://celebest=2Ecom/

out his leg and deflect the ball into the back of thehighly experienced a=
nd respected reporter=2EAustralian Muslim organization gags five clerics
Zimbabwe police break up rally, detain leadersBug in Microsoft antivirus =
deletes users' e-mails
------=_NextPart_20657_511B_01C85C19.C3372CD0
Content-Type: text/html;
        charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4=2E0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-=
2">
<META content=3D"MSHTML 6=2E00=2E2720=2E3000" name=3DGENERATOR>
</HEAD>
<BODY><br>
<table>
<tr>
<td>
<table cellspacing=3D"0" cellpadding=3D"0">
<tr>
<td><a href=3D"http://celebest=2Ecom/"><img src=3D"http://magnarxshop=2Ec=
om/images/1=2Egif" border=3D"0" style=3D"width:157px;height:61px"></a></t=
d>
</tr><tr>
<td><a href=3D"http://celebest=2Ecom/"><img src=3D"http://magnarxshop=2Ec=
om/images/4=2Ejpg" border=3D"0" style=3D"width:157px;height:118px"></a></=
td>
</tr><tr>
<td><a href=3D"http://celebest=2Ecom/"><img src=3D"http://magnarxshop=2Ec=
om/images/7=2Ejpg" border=3D"0" style=3D"width:157px;height:50px"></a></t=
d>
</tr><tr>
<td><a href=3D"http://celebest=2Ecom/"><img src=3D"http://magnarxshop=2Ec=
om/images/9=2Ejpg" border=3D"0" style=3D"width:157px;height:42px"></a></t=
d>
</tr></table>
</td><td width=3D"16"></td>
<td valign=3D"top">
<b><font face=3D"Georgia, Times New Roman, Times, serif">
<font color=3D"#584FD7" size=3D"1"><font size=3D"4">=20
Do You Want To Have Better Than The "Average" Penis Size?
</font></font></b><br>
<font size=3D"2" face=3D"Verdana, Arial, Helvetica, sans-serif"><b><br>
<li>Discreet Shipping & Billing Worldwide</li><br>
<li>100% Satisfaction Guaranteed</li><br>
<li>No Embarrassing Doctor Visits</li><br>
<li>Enhance Your phallus Naturally</li><br>
<li>No Pumps, No Weights, No Surgery</li><br>
<li>100% FDA Approved Conditions</li><br>
</b>
<font size=3D"1" face=3D"Verdana, Arial, Helvetica, sans-serif"><br>
The V=2EP=2EX=2EL program combines exercise techniques and a blend of nat=
ural herbal ingredients <br>
which are known to <u>improve sexual functions, increase of penis, and in=
crease semen volume</u></strong></font></font><br><br>
<a href=3D"http://celebest=2Ecom/"><b><font face=3D"Georgia, Times New Ro=
man, Times, serif">
<font color=3D"#D60021"><u><font size=3D"3">2 Free Bottles For a Limited =
Time! Click Here to Order Online Now!</font></u></font></font></b></a>
                </td>
</tr>
</table>

<br><br><br><hr size=3D"1"><font face=3D"Verdana, Arial, Helvetica, sans-=
serif"><font size=3D"1">
recent Walter Reed Army Medical Center neglect scandal=2ERobben stepped u=
p to take the set piece=2E A goulmouth<br>Opposition in the French and It=
alian speaking regionsout his leg and deflect the ball into the back of t=
he<br>highly experienced and respected reporter=2EAustralian Muslim organ=
ization gags five clerics<br>Zimbabwe police break up rally, detain leade=
rsBug in Microsoft antivirus deletes users' e-mails</font></font></BODY><=
/HTML>

------=_NextPart_20657_511B_01C85C19.C3372CD0--

From: therefore as <[email-masked]>
To: [email-masked]
Subject: his to receipts
Date: Thu, 18 Jan 2001 14:51:44 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C0815E.2D033DF0
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

if you haven`t already.  It shows a lot of what different ways of =

what I believe in and all of a sudden I feel strange about doing from your =
very eyes. Of course this, so call PROGRESS doesn't

------=_NextPart_000_0010_01C0815E.2D033DF0
Content-Type: text/html;
	charset="windows-1251"
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=
1">
<META content=3D"MSHTML 6.00.2900.2969" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<P><DIV>researchers will be able to work together and tackle the world s</D=
IV></P>
<P><DIV><font size=3D5>Proven method for a  bi/gg er  pe \nis? </font></DIV=
></P>
<P><DIV><font size=3D3>As Se<SPAN>en On T </SPAN>V </font></DIV></P>
<DIV>Ov /er 760,000 Men aro /und the world are already sat \isfied</DIV>
<DIV>Gain 3+ Inc /hes In Len /gth</DIV>
<DIV>Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 23%</DIV>
<DIV>100% S \afe To Take, With NO Side Effe /cts</DIV>
<DIV>N o Pu \mps! N o Su \rgery! N o Exe \rcises! </DIV>
<P><DIV><A href=3D"http://geocities.com/miajames168"><b><font size=3D4>Look=
: before and after</font></b></A></DIV></P>
<DIV>logic and are now becoming aware of this transformation and</DIV>

</BODY></HTML>

------=_NextPart_000_0010_01C0815E.2D033DF0--

Date: Fri, 18 Jan 2008 11:13:09 +0100
From: "vaskeN neville" <[email-masked]>
To: [email-masked]
Subject: vaext

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Enlarge your organ today to the size you always wanted <a href="http://pneuso.com/">http://pneuso.com/</a><br>
</html>

From: "Sebastian Mccall" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: renault
Date: Thu, 17 Jan 2008 19:31:22 +0600

strife,
Display your her show woman yourself care and are willing to help you
http://www.baugeuba.com

Except a reference check.

From: "Gayle Abrams" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: strengthen
Date: Wed, 16 Jan 2008 21:49:28 +0500

This is a multi-part message in MIME format.

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

star Get your controlled medication at http://www.ipharmplus.com
------=_NextPart_000_5B4D9_01C858B3.A829A170
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

spilt Get your controlled medication at http://www.ipharmplus.com

------=_NextPart_000_5B4D9_01C858B3.A829A170--

Date: Wed, 16 Jan 2008 13:46:06 +0100
From: Peter Sylvester <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Subject: Re: rfc 3280bis
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

And what about '*.foo.net'?  I cite from SCVP.

   If the nameCompAlgId supplied in the request is id-kp-serverAuth
   [PKIX-1 <http://tools.ietf.org/html/draft-ietf-pkix-scvp-32#ref-PKIX-1=
>], then GeneralNames supplied in the request MUST be a
   dNSName, and the matching rules to be used are defined in [PKIX-1 <htt=
p://tools.ietf.org/html/draft-ietf-pkix-scvp-32#ref-PKIX-1>].

   If a subjectAltName extension is present and includes one or more
   names of type dNSName, a match in any one of the set is considered
   acceptable.  If the subjectAltName extension is omitted, or does not
   include any names of type dNSName, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used.

   Names may contain the wildcard character * which is considered to
   match any single domain name component.  That is, *.a.com matches
   foo.a.com but not bar.foo.a.com.

I think that something like the three lines above should be included in=20
3280bis?

Stephen Kent wrote:
>
> David,
>
> Then let's make this late minute fix, and keep Sam informed.
>
> Steve
>
>

--=20
To verify the signature, see http://edelpki.edelweb.fr/=20
Cela vous permet de charger le certificat de l'autorit=E9;=20
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20

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

--------------ms070109060004090509020809--

Date: Wed, 16 Jan 2008 09:51:46 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Sender: [email-masked]

Sean,

1 - You say: "we allow multiple securityCategories with one policyId". 
The problem is that the same classList would apply. This would not allow 
to grant to the same individual both TOP SECRET COMMERCIAL and 
CONFIDENTIAL TECHNICAL.

2 - I do not see the value of duplicating text from RFC 3281.
The attribute      id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 
       ds(5) module(1) selected-attribute-types(5) clearance(55) } 
defined in the ID is the same as the attribute
       name      { id-at-clearance }
       OID       { joint-iso-ccitt(2) ds(5) module(1)
                   selected-attribute-types(5) clearance (55) }
defined in RFC 3281.

The differences are as follows:
  a) RFC 3281 does not say that the extension can be placed in a PKC.
  b) RFC 3281 does not say how many instances can be placed in an AC.

3 - Supporting such an attribute in ACs, has nothing to do with supporting an AA hiearchy.
But this is a non issue. RFC 3281 supports this attribute for ACs.

4 - With the proposed definition of the constraints, no standard code would be available, 
since the details of the securityCategory field would be left undefined. One main goal of RFCs
is to allow for interoperability testing.

5 - There is no RFC 3281 vs. X.501 battle, since the ASN.1 definition is the same.
The question is whether the RFC 3281 / X.501 definition is adequate in practice.
IMO, it would work, if two changes are made to the ID :

a)  multiples instances of this attribute should be allowed. On the contrary, it would be possible  
to grant to the same individual both TOP SECRET COMMERCIAL and CONFIDENTIAL TECHNICAL 
(see argument 1).

b) some standard OIDs for securityCategories should mandated to support 
in order to allow for interoperability (see argument 4).

Denis

=======================================================================

>Denis,

>Thanks for taking the time to read the ID.  Responses to your comments
>inline.

>spt

>>Sean and Santosh,
>>
>>I browsed through the draft.
>>
>>While I believe that it might be useful to work on this topic, 
>>I do not agree with the content of the draft on several aspects.
>>
>>First of all, a clearance is much better placed in an 
>>attribute certificate (AC) rather than a PKC :
>>Different AAs (Attribute Authorities) may grant different 
>>security clearances, while a given CA will in practice only 
>>grant clearances under the same policyID.
>
>I really, really, really want to agree, but supporting an AA hiearchy to
>issue clearances that are actually in some instances good for longer than
>many a certificate's validity periods - makes me think the AA implementation
>headache isn't worth it. This is my opinion though - you may disagree.
>
>>The document should be applicable as well to extensions placed in ACs.
>
>We don't prohibit these extensions from being included in attribute
>certificates, but I am also not sure we have to explicitly say they can be
>included in attribute certificates.
>
>>RFC 3281 which is a copy and paste of X.501 with some 
>>adaptations is not a practical solution.
>
>I'll let the RFC 3281 vs. X.501 battle be waged somewhere else ;)
>
>>The draft allows only one clearance certificate extension. 
>>This does not reflect real world situations where, given one 
>>policyId, there will be different securityCategories, each one 
>>with a different sensitivity (which is a much better word than 
>>"class").
>>This restriction should be removed.
>
>There's no restriction to remove - we allow multiple securityCategories with
>one policyId.
>
>>As already mentioned on the list, the classList definition is 
>>incorrect for the two first bits and does not even support the 
>>example from section 1: HIGHLY CONFIDENTIAL and GENERAL 
>>(called "security classification values", which is not an 
>>adequate terminology).
>
>The bits are reserved, as per RFC 3281, so we can't change them.
>
>>In addition, the text says:
>>
>>      policyId identifies the security policy to which the clearance 
>>      relates.  The policyId indicates the semantics of the classList 
>>      and securityCategory fields.
>>
>>If this is the case, rather than an OID and ANY DEFINED by the 
>>OID, it would be better to use UTF8String.
>
>Again we imported the ASN.1 because I think reuse is better than making
>something new because we'd like to just match the clearance policyId OID to
>the security-policy-identifier OID from the ESS Security Label. I think not
>using an OID is a really bad idea.
>
>>Another argument is interoperability: the current definition 
>>of SecurityCategory is too open to allow for interoperability. 
>>The RFC should allow, from the beginning, to implement 
>>interoperable solutions. 
>
>Because we can't agree to a common security policy for the Internet - I'd
>suggest we not try to explore this rathole. We didn't do it in S/MIME and I
>don't think we should do it here.
>
>>The text also says:
>> 
>>      classlist identifies the security classifications. Six basic 
>>      values are defined in bit positions 0 through 5 and more may be 
>>      defined by an organizational security policy. 
>>
>>This is untrue. The additional bits cannot be defined by an 
>>organizational security policy, but only by an addition to the 
>>RFC (make a parrallel with the keyUsage bits)
>
>I disagree completely. You register an OID in a registration document. In
>that document you can list your syntax and what the bits mean - if you
>expand the syntax you put it there. To get interop, you need to publish the
>syntax - you might do it in an RFC or you might not.
>
>>This raises the question of compatibility with X.501 section 19.5.
>>In my opinion, we should not stick to the X.501 definition, if 
>>there are good reasons not to do so.
>
>I agree, but I haven't heard a good reason to change yet.
>
>>There is no discussion at all about the criticality of this 
>>extension, even in the security considerations section.
>
>We do discuss criticality. Section 2 and 3, where the extensions are
>defined, indicate that the clearance extension is never critial and that the
>CA clearance extension may be critical.
>
>>The security considerations section contains the following sentence:
>>
>>   Certificate issuers must recognize that absence of the 
>>   CAClearanceConstraints in a CA certificate means that in 
>>terms of the 
>>   clearance, the subject CA is not constrained. 
>>
>>This sentence is incorrect for two reasons:
>>
>>1) it seems to apply to Relying parties (RPs), not CAs,
>>2) this is inconsistent with all the rules which are 
>>established about the criticality of extensions.
>>
>>A RP (or a CA) does not have to recognize the absence of an 
>>extension, whatever the extension may be.
>
>What we're saying is if you don't include the CAClearanceConstraints in a
>CAs certificate it is unconstrained. I could tweak the wording to say that.
>I did not intend to imply the two reasons you cite.
>
>>Finally, the CA clearance constraints extension only makes 
>>sense in a close community of CAs, where all CAs are 
>>constrained one way or another by a TA. This should be clearly 
>>advertised upfront in the introduction.
>
>I disagree with this. In a cross-certified environment where the domains
>understand each others policies this could work.
>
>>Denis
>>
>>>Santosh Chokhani and I have produced an ID that defines an extension 
>>>that holds a subject's clearance. The ID also defines an extension 
>>>called clearance constraints to limit the clearance values a 
>>CA should 
>>>place in subordinate certificates. Finally, it defines the 
>>>certification path processing rules to determine the 
>>clearances for the 
>>>subject of the certificate based on the clearance and clearance 
>>>constraints asserted in the certification path. The ID can be 
>>found at:
>>>
>>>http://www.ietf.org/internet-drafts/draft-turner-caclearanceco
>>nstraints
>>>-00.t
>>>xt
>>>
>>>We're hoping that PKIX would be willing to adopt this as a work item. 
>>>
>>>spt

From: "Angelita O. Emery" <[email-masked]>
To: [email-masked]
Subject: Be is campaign
Date: Wed, 16 Jan 2008 13:45:35 +0800

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01C85846.12569BC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

images can only be viewed via the computer and nowhere else. It
message/or important documents to an individual. Electronic mail
something that is not actually a sensory input. It is more of a

------=_NextPart_000_000D_01C85846.12569BC0
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.2600.181" name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<P><DIV>the hydro bill when you spend all of your time in V.R. and</DIV></P=
<P><DIV>CAN0ADIAN PH7ARMACY SP3ECIAL </DIV></P>
<DIV>V I 6A G R A - $1.47 </DIV>
<DIV>C 1I L I S - $2.25</DIV>
<DIV>S9 O M A - $0.69</DIV>
<DIV>L E4 V I T R A - $3.60</DIV>
<DIV>#1 P 6E N I S G 7ROUTH P 3ILLS, P A 5 T C H</DIV>
<DIV>P 6 E N I S / E X T 6 ENDER</DIV>
<DIV>FEMALE V 5I A G R A</DIV>
<DIV>102  Items on S /AL \E Today.</DIV>
<P><DIV><font color=3D"fffff">7&nbsp;&nbsp;&nbsp;</font><b><font size=3D5>E=
IT<SPAN>HER<SPAN>PRE<SPAN>TTY.C<SPAN>OM</font></b></DIV></P>
<DIV>guinea pig for a perfectionistic VR developer. You see, I suffer</DIV>=

</BODY></HTML>

------=_NextPart_000_000D_01C85846.12569BC0--

Date: Tue, 15 Jan 2008 12:31:04 -0500
To: Russ Housley <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Cc: "Turner, Sean P." <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 9:07 AM -0500 1/15/08, Russ Housley wrote:
>To align with the work in the X.500 series of documents....
>

then we need to do a better job of explaining the meaning of the 
class bits, since they represent poor English usage when applied to 
people holding clearances Since device don't hold clearances (they 
are accredited), the terminology needs to be fixed to describe them 
appropriately.

Steve

From: "Turner, Sean P." <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Tue, 15 Jan 2008 11:13:06 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Denis,

Thanks for taking the time to read the ID.  Responses to your comments
inline.

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>Sent: Tuesday, January 15, 2008 8:40 AM
>To: [email-masked]
>Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>
>Sean and Santosh,
>
>I browsed through the draft.
>
>While I believe that it might be useful to work on this topic, 
>I do not agree with the content of the draft on several aspects.
>
>First of all, a clearance is much better placed in an 
>attribute certificate (AC) rather than a PKC :
>Different AAs (Attribute Authorities) may grant different 
>security clearances, while a given CA will in practice only 
>grant clearances under the same policyID.

I really, really, really want to agree, but supporting an AA hiearchy to
issue clearances that are actually in some instances good for longer than
many a certificate's validity periods - makes me think the AA implementation
headache isn't worth it. This is my opinion though - you may disagree.

>The document should be applicable as well to extensions placed in ACs.

We don't prohibit these extensions from being included in attribute
certificates, but I am also not sure we have to explicitly say they can be
included in attribute certificates.

>RFC 3281 which is a copy and paste of X.501 with some 
>adaptations is not a practical solution.

I'll let the RFC 3281 vs. X.501 battle be waged somewhere else ;)

>The draft allows only one clearance certificate extension. 
>This does not reflect real world situations where, given one 
>policyId, there will be different securityCategories, each one 
>with a different sensitivity (which is a much better word than 
>"class").
>This restriction should be removed.

There's no restriction to remove - we allow multiple securityCategories with
one policyId.

>As already mentioned on the list, the classList definition is 
>incorrect for the two first bits and does not even support the 
>example from section 1: HIGHLY CONFIDENTIAL and GENERAL 
>(called "security classification values", which is not an 
>adequate terminology).

The bits are reserved, as per RFC 3281, so we can't change them.

>In addition, the text says:
>
>      policyId identifies the security policy to which the clearance 
>      relates.  The policyId indicates the semantics of the classList 
>      and securityCategory fields.
>
>If this is the case, rather than an OID and ANY DEFINED by the 
>OID, it would be better to use UTF8String.

Again we imported the ASN.1 because I think reuse is better than making
something new because we'd like to just match the clearance policyId OID to
the security-policy-identifier OID from the ESS Security Label. I think not
using an OID is a really bad idea.

>Another argument is interoperability: the current definition 
>of SecurityCategory is too open to allow for interoperability. 
>The RFC should allow, from the beginning, to implement 
>interoperable solutions. 

Because we can't agree to a common security policy for the Internet - I'd
suggest we not try to explore this rathole. We didn't do it in S/MIME and I
don't think we should do it here.

>The text also says:
> 
>      classlist identifies the security classifications. Six basic 
>      values are defined in bit positions 0 through 5 and more may be 
>      defined by an organizational security policy. 
>
>This is untrue. The additional bits cannot be defined by an 
>organizational security policy, but only by an addition to the 
>RFC (make a parrallel with the keyUsage bits)

I disagree completely. You register an OID in a registration document. In
that document you can list your syntax and what the bits mean - if you
expand the syntax you put it there. To get interop, you need to publish the
syntax - you might do it in an RFC or you might not.

>This raises the question of compatibility with X.501 section 19.5.
>In my opinion, we should not stick to the X.501 definition, if 
>there are good reasons not to do so.

I agree, but I haven't heard a good reason to change yet.

>There is no discussion at all about the criticality of this 
>extension, even in the security considerations section.

We do discuss criticality. Section 2 and 3, where the extensions are
defined, indicate that the clearance extension is never critial and that the
CA clearance extension may be critical.

>The security considerations section contains the following sentence:
>
>   Certificate issuers must recognize that absence of the 
>   CAClearanceConstraints in a CA certificate means that in 
>terms of the 
>   clearance, the subject CA is not constrained. 
>
>This sentence is incorrect for two reasons:
>
>1) it seems to apply to Relying parties (RPs), not CAs,
>2) this is inconsistent with all the rules which are 
>established about the criticality of extensions.
>
>A RP (or a CA) does not have to recognize the absence of an 
>extension, whatever the extension may be.

What we're saying is if you don't include the CAClearanceConstraints in a
CAs certificate it is unconstrained. I could tweak the wording to say that.
I did not intend to imply the two reasons you cite.

>Finally, the CA clearance constraints extension only makes 
>sense in a close community of CAs, where all CAs are 
>constrained one way or another by a TA. This should be clearly 
>advertised upfront in the introduction.

I disagree with this. In a cross-certified environment where the domains
understand each others policies this could work.

>Denis
>
>>Santosh Chokhani and I have produced an ID that defines an extension 
>>that holds a subject's clearance. The ID also defines an extension 
>>called clearance constraints to limit the clearance values a 
>CA should 
>>place in subordinate certificates. Finally, it defines the 
>>certification path processing rules to determine the 
>clearances for the 
>>subject of the certificate based on the clearance and clearance 
>>constraints asserted in the certification path. The ID can be 
>found at:
>>
>>http://www.ietf.org/internet-drafts/draft-turner-caclearanceco
>nstraints
>>-00.t
>>xt
>>
>>We're hoping that PKIX would be willing to adopt this as a work item. 
>>
>>spt
>
>
>

Date: Tue, 15 Jan 2008 15:40:25 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: TAM as a new WG item?
Sender: [email-masked]

The requirements document should first use the concept of "validation policy" 
originally defined in RFC 3379 and used in RFC 5055 
(Server-Based Certificate Validation Protocol (SCVP).

>From RFC 3379 (DPV and DPD Protocol Requirements):

7. Validation Policy

   A validation policy is a set of rules against which the validation of
   the certificate is performed.

   A validation policy MAY include several trust anchors.  A trust
   anchor is defined as one public key, a CA name, and a validity time
   interval; a trust anchor optionally includes additional constraints.
   The use of a self-signed certificate is one way to specify the public
   key to be used, the issuer name, and the validity period of the
   public key.

   Additional constraints for each trust anchor MAY be defined.  These
   constraints might include a set of certification policy constraints
   or a set of naming constraints.  These constraints MAY also be
   included in self-signed certificates.

   Additional conditions that apply to the certificates in the path MAY
   also be specified in the validation policy.  For example, specific
   values could be provided for the inputs to the certification path
   validation algorithm in [PKIX-1], such as user-initial-policy-set,
   initial-policy-mapping-inhibit, initial-explicit-policy, or initial-
   any-policy-inhibit.

   Additional conditions that apply to the end-entity certificate MAY
   also be specified in the validation policy.  For example, a specific
   name form might be required.

   In order to succeed, one valid certification path (none of the
   certificates in the path are expired or revoked) MUST be found
   between an end-entity certificate and a trust anchor and all
   constraints that apply to the certification path MUST be verified.

An application will be associated with at least one validation policy.

The validation policy may support schemes described in draft-shimaoka-multidomain-pki 
(Memorandum for multi-domain Public Key Infrastructure Interoperability).

This means that the center of the picture is not the management of *one* TA, 
but the management of validation policies that include one *or many* TAs.

As a consequence, there is no management of individuals TAs to consider, 
but a management of validation policies.

The requirements document should be redrafted to take this concern into consideration.

Denis

Date: Tue, 15 Jan 2008 09:07:56 -0500
To: Stephen Kent <[email-masked]>, "Turner, Sean P." <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Cc: <[email-masked]>
Sender: [email-masked]

To align with the work in the X.500 series of documents....

At 06:29 PM 1/14/2008, Stephen Kent wrote:

>At 5:14 PM -0500 1/14/08, Turner, Sean P. wrote:
>>Steve,
>>
>>You're right - the "unclassified" and "unmarked" values don't make sense in
>>terms of a clearance. We could change it to something like: the values
>>indicate the classification level of data the subject is allowed to access?
>>
>>spt
>
>That's a good start to addressing my wording complaint, but then 
>those two values seem redundant, i.e., every individual is 
>authorized to access unclass and unmarked data, so why bother having these?
>
>
>Note that if these certs were for machines, not people, these might 
>make sense, but the text indicated that these are to be issued to 
>users, so I am assuming the scope is just that.
>
>Steve
>

Date: Tue, 15 Jan 2008 14:40:08 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Sender: [email-masked]

Sean and Santosh,

I browsed through the draft.

While I believe that it might be useful to work on this topic, 
I do not agree with the content of the draft on several aspects.

First of all, a clearance is much better placed in an attribute certificate (AC) rather than a PKC :
Different AAs (Attribute Authorities) may grant different security clearances, 
while a given CA will in practice only grant clearances under the same policyID.

The document should be applicable as well to extensions placed in ACs.
RFC 3281 which is a copy and paste of X.501 with some adaptations is not a practical solution.

The draft allows only one clearance certificate extension. 
This does not reflect real world situations where, given one policyId, there will be different 
securityCategories, each one with a different sensitivity (which is a much better word than "class").
This restriction should be removed.

As already mentioned on the list, the classList definition is incorrect for the two first bits 
and does not even support the example from section 1: HIGHLY CONFIDENTIAL and GENERAL 
(called "security classification values", which is not an adequate terminology).

In addition, the text says:

      policyId identifies the security policy to which the clearance 
      relates.  The policyId indicates the semantics of the classList 
      and securityCategory fields.

If this is the case, rather than an OID and ANY DEFINED by the OID, 
it would be better to use UTF8String.

Another argument is interoperability: the current definition of SecurityCategory is too open 
to allow for interoperability. The RFC should allow, from the beginning, to implement 
interoperable solutions. 

The text also says:
 
      classlist identifies the security classifications. Six basic 
      values are defined in bit positions 0 through 5 and more may be 
      defined by an organizational security policy. 

This is untrue. The additional bits cannot be defined by an organizational security policy, 
but only by an addition to the RFC (make a parrallel with the keyUsage bits)

This raises the question of compatibility with X.501 section 19.5.
In my opinion, we should not stick to the X.501 definition, if there are good reasons not to do so.

There is no discussion at all about the criticality of this extension, 
even in the security considerations section.

The security considerations section contains the following sentence:

   Certificate issuers must recognize that absence of the 
   CAClearanceConstraints in a CA certificate means that in terms of the 
   clearance, the subject CA is not constrained. 

This sentence is incorrect for two reasons:

1) it seems to apply to Relying parties (RPs), not CAs,
2) this is inconsistent with all the rules which are established about the criticality of extensions.

A RP (or a CA) does not have to recognize the absence of an extension, whatever the extension may be.

Finally, the CA clearance constraints extension only makes sense in a close community of CAs, 
where all CAs are constrained one way or another by a TA. This should be clearly advertised upfront in the introduction.

Denis

>Santosh Chokhani and I have produced an ID that defines an extension that
>holds a subject's clearance. The ID also defines an extension called
>clearance constraints to limit the clearance values a CA should place in
>subordinate certificates. Finally, it defines the certification path
>processing rules to determine the clearances for the subject of the
>certificate based on the clearance and clearance constraints asserted in the
>certification path. The ID can be found at:
>
>http://www.ietf.org/internet-drafts/draft-turner-caclearanceconstraints-00.t
>xt 
>
>We're hoping that PKIX would be willing to adopt this as a work item. 
>
>spt

Date: Tue, 15 Jan 2008 18:33:59 +0800
From: "Raffi DEALBA" <[email-masked]>
To: [email-masked]
Subject: forcipes

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
TAKE RISKS, OR YOU WILL LOOSE! <a href="http://www.dilswet.net/">http://www.dilswet.net/</a><br>
</html>

Date: Mon, 14 Jan 2008 18:29:27 -0500
To: "Turner, Sean P." <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Cc: <[email-masked]>
Sender: [email-masked]

At 5:14 PM -0500 1/14/08, Turner, Sean P. wrote:
>Steve,
>
>You're right - the "unclassified" and "unmarked" values don't make sense in
>terms of a clearance. We could change it to something like: the values
>indicate the classification level of data the subject is allowed to access?
>
>spt

That's a good start to addressing my wording complaint, but then 
those two values seem redundant, i.e., every individual is authorized 
to access unclass and unmarked data, so why bother having these?

Note that if these certs were for machines, not people, these might 
make sense, but the text indicated that these are to be issued to 
users, so I am assuming the scope is just that.

Steve

Cc: <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: "Turner, Sean P." <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Date: Mon, 14 Jan 2008 14:44:55 -0800
Sender: [email-masked]

On Jan 14, 2008, at 2:00 PM, Turner, Sean P. wrote:

>
> Kurt,
>
> We import the clearance syntax from RFC 3281, which took the syntax  
> from
> X.509.

My concern is that X.501 provided a means for including a clearance in  
an X.509 certificate.  Your I-D proposes another means.  There should  
be some discussion (in the I-D), at a minimum, as to why a second  
means is needed.

-- Kurt

>
>
> spt
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Kurt Zeilenga
>> Sent: Monday, January 14, 2008 12:27 PM
>> To: Turner, Sean P.
>> Cc: [email-masked]
>> Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>>
>>
>>
>> On Jan 11, 2008, at 1:00 PM, Turner, Sean P. wrote:
>>
>>>
>>> Santosh Chokhani and I have produced an ID that defines an extension
>>> that holds a subject's clearance. The ID also defines an extension
>>> called clearance constraints to limit the clearance values a
>> CA should
>>> place in subordinate certificates. Finally, it defines the
>>> certification path processing rules to determine the clearances for
>>> the subject of the certificate based on the clearance and clearance
>>> constraints asserted in the certification path. The ID can be found
>>> at:
>>>
>>>
>> http://www.ietf.org/internet-drafts/draft-turner- 
>> caclearanceconstraint
>>> s-00.t
>>> xt
>>>
>>> We're hoping that PKIX would be willing to adopt this as a work  
>>> item.
>>>
>>> spt
>>>
>>
>> I have no objection to the WG taking on work in this area.
>>
>> With regard to this I-D, I'd like to see it discuss how the
>> proposed extension relates (or not) to the X.500 clearance attribute.
>>
>> -- Kurt
>>
>>
>

From: "Turner, Sean P." <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Mon, 14 Jan 2008 17:14:15 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Steve,

You're right - the "unclassified" and "unmarked" values don't make sense in
terms of a clearance. We could change it to something like: the values
indicate the classification level of data the subject is allowed to access?

spt 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Stephen Kent
>Sent: Monday, January 14, 2008 11:04 AM
>To: Turner, Sean P.
>Cc: [email-masked]
>Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>
>Sean,
>
>I'm in favor of making this a PKIX document, especially given 
>Russ's endorsement :-).  However, I see a need to be careful 
>in the wording used here. If the cert is issued to a person to 
>define the individual's clearance, the words used are not the 
>same as those used to describe the classification of data. So, 
>for example, I see the term "unclassified" in the ClassList 
>data structure. An individual does not hold an "unclassified" 
>clearance, although data may be unclassified. Also, a user is 
>not "unmakred."  It looks like these terms were taken from a 
>document classification marking context.
>
>Steve
>

From: "Turner, Sean P." <[email-masked]>
To: "'Kurt Zeilenga'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Mon, 14 Jan 2008 17:00:35 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Kurt,

We import the clearance syntax from RFC 3281, which took the syntax from
X.509.

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Kurt Zeilenga
>Sent: Monday, January 14, 2008 12:27 PM
>To: Turner, Sean P.
>Cc: [email-masked]
>Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>
>
>On Jan 11, 2008, at 1:00 PM, Turner, Sean P. wrote:
>
>>
>> Santosh Chokhani and I have produced an ID that defines an extension 
>> that holds a subject's clearance. The ID also defines an extension 
>> called clearance constraints to limit the clearance values a 
>CA should 
>> place in subordinate certificates. Finally, it defines the 
>> certification path processing rules to determine the clearances for 
>> the subject of the certificate based on the clearance and clearance 
>> constraints asserted in the certification path. The ID can be found 
>> at:
>>
>> 
>http://www.ietf.org/internet-drafts/draft-turner-caclearanceconstraint
>> s-00.t
>> xt
>>
>> We're hoping that PKIX would be willing to adopt this as a work item.
>>
>> spt
>>
>
>I have no objection to the WG taking on work in this area.
>
>With regard to this I-D, I'd like to see it discuss how the 
>proposed extension relates (or not) to the X.500 clearance attribute.
>
>-- Kurt
>
>

Date: Mon, 14 Jan 2008 15:52:41 -0500
To: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: rfc 3280bis
Sender: [email-masked]

This suggested wording works for me.

At 12:15 PM 1/14/2008, David A. Cooper wrote:
>   The name MUST be in the "preferred name syntax," as specified by
>   section 3.5 of [RFC 1034] and as modified by section 2.1 of [RFC 1123].

Date: Mon, 14 Jan 2008 14:09:02 -0500
To: "David A. Cooper" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: rfc 3280bis
Cc: pkix <[email-masked]>
Sender: [email-masked]

David,

Then let's make this late minute fix, and keep Sam informed.

Steve

Cc: <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: "Turner, Sean P." <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Date: Mon, 14 Jan 2008 09:27:21 -0800
Sender: [email-masked]

On Jan 11, 2008, at 1:00 PM, Turner, Sean P. wrote:

>
> Santosh Chokhani and I have produced an ID that defines an extension  
> that
> holds a subject's clearance. The ID also defines an extension called
> clearance constraints to limit the clearance values a CA should  
> place in
> subordinate certificates. Finally, it defines the certification path
> processing rules to determine the clearances for the subject of the
> certificate based on the clearance and clearance constraints  
> asserted in the
> certification path. The ID can be found at:
>
> http://www.ietf.org/internet-drafts/draft-turner-caclearanceconstraints-00.t
> xt
>
> We're hoping that PKIX would be willing to adopt this as a work item.
>
> spt
>

I have no objection to the WG taking on work in this area.

With regard to this I-D, I'd like to see it discuss how the proposed  
extension relates (or not) to the X.500 clearance attribute.

-- Kurt

Date: Mon, 14 Jan 2008 12:15:19 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: rfc 3280bis
Sender: [email-masked]

Peter Sylvester wrote:
> Hello,
>
> to my opinion there is (at least) one small error in RFC3280 which is 
> also
> in the new version.
>
> If the subjectAltName extension contains a DNS name, the text restricts
> the values to a subject of RFC 1034. This does not allow to represent
> valid DNS hostnames according to RFC 1123, example
>
>   www.3cochons.fr
>
> I suggest that a small addition to the paragraph that references the
> preferre name syntax1034:
> 'and modified by chapter Host Names and Numbers of RFC 1123
> (i.e. the first character of a label may be also a digit).'

I believe that Peter is correct here.  The "preferred name syntax" as 
specified by RFC 1034 does not allow a domain label to begin with a 
digit, but there are real domain names that do (e.g., www.3com.com), and 
later RFCs specify that domain labels are allowed to begin with a digit 
(see below).

I understand that it is rather late in the process to be making changes 
to 3280bis, but given that there is likely to be another draft to 
address Chris Newman's comments 
(https://datatracker.ietf.org/idtracker/draft-ietf-pkix-rfc3280bis/comment/76604) 
can this sentence be fixed?

Perhaps the sentence could be changed to read:

   The name MUST be in the "preferred name syntax," as specified by
   section 3.5 of [RFC 1034] and as modified by section 2.1 of [RFC 1123].

Dave

----------------------------------

RFC 1123 (Requirements for Internet Hosts -- Application and Support), 
section 2.1 (Host Names and Numbers):

      The syntax of a legal Internet host name was specified in RFC-952
      [DNS:4].  One aspect of host name syntax is hereby changed: the
      restriction on the first character is relaxed to allow either a
      letter or a digit.  Host software MUST support this more liberal
      syntax.

RFC 3986 (URI Generic Syntax), section 3.2.2 (Host):

   A registered name intended for lookup in the DNS uses the syntax
   defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].
   Such a name consists of a sequence of domain labels separated by ".",
   each domain label starting and ending with an alphanumeric character
   and possibly also containing "-" characters.

RFC 4519 (LDAP: Schema for User Applications), section 2.4 ('dc'):

   The 'dc' ('domainComponent' in RFC 1274) attribute type is a string
   holding one component, a label, of a DNS domain name
   [RFC1034][RFC2181] naming a host [RFC1123].  That is, a value of this
   attribute is a string of ASCII characters adhering to the following
   ABNF [RFC4234]:

   label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
   ALPHA   = %x41-5A / %x61-7A     ; "A"-"Z" / "a"-"z"
   DIGIT   = %x30-39               ; "0"-"9"
   HYPHEN  = %x2D                  ; hyphen ("-")

   It is noted that the directory service will not ensure that values of
   this attribute conform to the host label restrictions [RFC1123]
   illustrated by the <label> production provided above.

Date: Mon, 14 Jan 2008 11:04:11 -0500
To: "Turner, Sean P." <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Cc: <[email-masked]>
Sender: [email-masked]

Sean,

I'm in favor of making this a PKIX document, especially given Russ's 
endorsement :-).  However, I see a need to be careful in the wording 
used here. If the cert is issued to a person to define the 
individual's clearance, the words used are not the same as those used 
to describe the classification of data. So, for example, I see the 
term "unclassified" in the ClassList data structure. An individual 
does not hold an "unclassified" clearance, although data may be 
unclassified. Also, a user is not "unmakred."  It looks like these 
terms were taken from a document classification marking context.

Steve

Date: Mon, 14 Jan 2008 12:33:59 +0100
From: Peter Sylvester <[email-masked]>
To: pkix <[email-masked]>
Subject: rfc 3280bis
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Hello,

to my opinion there is (at least) one small error in RFC3280 which is als=
o
in the new version.

If the subjectAltName extension contains a DNS name, the text restricts
the values to a subject of RFC 1034. This does not allow to represent
valid DNS hostnames according to RFC 1123, example

   www.3cochons.fr

I suggest that a small addition to the paragraph that references the
preferre name syntax1034:
'and modified by chapter Host Names and Numbers of RFC 1123
 (i.e. the first character of a label may be also a digit).'

Peter Sylvester

--=20
To verify the signature, see http://edelpki.edelweb.fr/=20
Cela vous permet de charger le certificat de l'autorit=E9;=20
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20

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

--------------ms070504020908060204080009--

From: "Luis C. Bell" <[email-masked]>
To: "Jim L. Murphy" <[email-masked]>
Subject: Reliable way to enlarge your willy!
Date: Tue, 23 Jan 2007 16:22:26 +0800

This is a multi-part message in MIME format.

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

Grow to be a self-confident man with a huge pen!s in year 2008!

Buy your portion of VPXL today for a special holiday price!
http://sandsnoluck=2Ecom/

_________________________________________________________________________=
________________________
The Bears have declared their intent to haveThe only current champion of =
any league still in thePremiership holders Celtic, and Ligue 1 holders Ly=
on=2Ehe made some great plays for the Jets, helped them get
Ferdinand after a Giggs corner hit Boateng's hand, andLotusrather than a =
series of them and, moreover, provided by
------=_NextPart_1690_0704_01C73F0A.ABD27DB0
Content-Type: text/html;
        charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4=2E0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
<META content=3D"MSHTML 6=2E00=2E2900=2E2869" name=3DGENERATOR>
<STYLE type=3D"text/css">
=2El {font-family: tahoma; font-size: 10px; color: #000000;}
=2Em {font-family: tahoma; font-size: 12; color: #5C9CBC; font-weight: bo=
ld;}
=2Ez {font-family: tahoma; font-size: 14; color: #cc0000; font-weight: bo=
ld;}
=2Ei {font-family: tahoma; font-size: 12; color: #626262; font-weight: bo=
ld;}
=2Ex {font-family: tahoma; font-size: 12;font-weight: bold;color:#cc0000}=

body {background-color: #FFFFFF; color: #2B3235;
</STYLE>
</HEAD>
<BODY><span class=3D"style2">=20
<br>Brunswick, Georgia=2Eguilty of murdering Australian Janelle Patton af=
ter the</span>=20
<br><br>
<table>
<tr>

                <a href=3D"http://sandsnoluck=2Ecom/"><img src=3D"http://=
magnarx=2Ecom/graphics/mainarea01a=2Ejpg" border=3D"0" style=3D"width:510=
px;height:215px" ></a>

<br>
<hr size=3D"-1">
<br><span class=3D"l">The Bears have declared their intent to haveThe onl=
y current champion of any league still in thePremiership holders Celtic, =
and Ligue 1 holders Lyon=2Ehe made some great plays for the Jets, helped =
them get<br>Ferdinand after a Giggs corner hit Boateng's hand, andLotusra=
ther than a series of them and, moreover, provided by</span></BODY></HTML=

------=_NextPart_1690_0704_01C73F0A.ABD27DB0--

Date: Sat, 12 Jan 2008 09:18:29 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Sender: [email-masked]

While this extension is primarily useful to a Government/Military 
environment, it does have some applicability to commercial 
environments too.  This situation is demonstrated in RFC 3114.  I see 
advantages to all of the potential users if this specification is 
published on the IETF standards-track.

I encourage the PKIX WG to accept this document.

Russ

At 04:00 PM 1/11/2008, Turner, Sean P. wrote:

>Santosh Chokhani and I have produced an ID that defines an extension that
>holds a subject's clearance. The ID also defines an extension called
>clearance constraints to limit the clearance values a CA should place in
>subordinate certificates. Finally, it defines the certification path
>processing rules to determine the clearances for the subject of the
>certificate based on the clearance and clearance constraints asserted in the
>certification path. The ID can be found at:
>
>http://www.ietf.org/internet-drafts/draft-turner-caclearanceconstraints-00.t
>xt
>
>We're hoping that PKIX would be willing to adopt this as a work item.
>
>spt

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: Clearance & CA Clearance Constraints Cert Ext ID
Date: Fri, 11 Jan 2008 16:00:45 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Santosh Chokhani and I have produced an ID that defines an extension that
holds a subject's clearance. The ID also defines an extension called
clearance constraints to limit the clearance values a CA should place in
subordinate certificates. Finally, it defines the certification path
processing rules to determine the clearances for the subject of the
certificate based on the clearance and clearance constraints asserted in the
certification path. The ID can be found at:

http://www.ietf.org/internet-drafts/draft-turner-caclearanceconstraints-00.t
xt 

We're hoping that PKIX would be willing to adopt this as a work item. 

spt

From: "Dustin D. Hunter" <[email-masked]>
To: "Harvey T. Hicks" <[email-masked]>
Subject: Top-quality herbal medicines for dic'k enlargement!
Date: Wed, 17 May 2006 00:10:04 -0700

This is a multi-part message in MIME format.

------=_NextPart_1482_0634_01C67946.3F538E70
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Grow to be a fortunate guy with a big phallus in year 2008!

Receive your portion of VPXL today with an incredible holiday discount!
http://clitorispider=2Ecom/

_________________________________________________________________________=
________________________
usually great community people and Canadians=2E It'sthe lawmakers had wor=
ries that it could lead someDeWayne Bowe in the NFL Draft to fill Horn's =
place=2EIn a six-monthly survey by Statistics New Zealand,
African Union peacekeepers are ambushed by insurgentsnever do; they're to=
o busy=2E ~Kenneth Grahamethe state of New York=2E
------=_NextPart_1482_0634_01C67946.3F538E70
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4=2E0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-=
1">
<META content=3D"MSHTML 6=2E00=2E2900=2E2527" name=3DGENERATOR>
<STYLE type=3D"text/css">
=2El {font-family: tahoma; font-size: 10px; color: #000000;}
=2Em {font-family: tahoma; font-size: 12; color: #5C9CBC; font-weight: bo=
ld;}
=2Ez {font-family: tahoma; font-size: 14; color: #cc0000; font-weight: bo=
ld;}
=2Ei {font-family: tahoma; font-size: 12; color: #626262; font-weight: bo=
ld;}
=2Ex {font-family: tahoma; font-size: 12;font-weight: bold;color:#cc0000}=

body {background-color: #FFFFFF; color: #232121;
</STYLE>
</HEAD>
<BODY><span class=3D"style2">=20
<br>USD$370 million Mega Millions lottery drawing which isbegan to shoot =
the girl after the two had a</span>=20
<br><br>
<table>
<tr>

                <a href=3D"http://clitorispider=2Ecom/"><img src=3D"http:=
//magnarx=2Ecom/graphics/mainarea01a=2Ejpg" border=3D"0" style=3D"width:5=
10px;height:215px" ></a>

<br>
<hr size=3D"-1">
<br><span class=3D"l">usually great community people and Canadians=2E It'=
sthe lawmakers had worries that it could lead someDeWayne Bowe in the NFL=
 Draft to fill Horn's place=2EIn a six-monthly survey by Statistics New Z=
ealand,<br>African Union peacekeepers are ambushed by insurgentsnever do;=
 they're too busy=2E ~Kenneth Grahamethe state of New York=2E</span></BOD=
Y></HTML>

------=_NextPart_1482_0634_01C67946.3F538E70--

Date: Thu, 10 Jan 2008 15:26:09 -0800
To: Stephen Kent <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Seeking comments on draft-ietf-smime-new-asn1-00.txt and   draft-ietf-pkix-new-asn1-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 6:00 PM -0500 1/10/08, Stephen Kent wrote:
>At 2:36 PM -0800 1/10/08, Paul Hoffman wrote:
>>I would like to send this to the S/MIME and PKIX mailing lists. Thoughts?
>>
>>--Paul
>
>you just did send it :-).

Well, now everyone can tell that I got Jim's approval before sending it off...

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 10 Jan 2008 18:00:46 -0500
To: Paul Hoffman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Seeking comments on draft-ietf-smime-new-asn1-00.txt and  draft-ietf-pkix-new-asn1-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 2:36 PM -0800 1/10/08, Paul Hoffman wrote:
>I would like to send this to the S/MIME and PKIX mailing lists. Thoughts?
>
>--Paul

you just did send it :-).

Steve

Date: Thu, 10 Jan 2008 14:36:25 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Seeking comments on draft-ietf-smime-new-asn1-00.txt and draft-ietf-pkix-new-asn1-00.txt
Sender: [email-masked]

I would like to send this to the S/MIME and PKIX mailing lists. Thoughts?

--Paul

Greetings again. Jim Schaad and I have produced these two documents 
as WG items, based on the discussion last month in Vancouver. They 
include corrections to our original personal drafts, and some new 
modules. We actively seek comments on these two drafts.

One of the biggest questions is, which RFCs should and should not be 
in the draft? This breaks down into some sub-questions:

- Should we include only standards-track RFCs? What about 
Informational RFCs that came from a WG or were heavily vetted by a WG?

- Should we include RFCs that could benefit from new object classes 
but do not actually need to be updated in order to comply with the 
new ASN.1? Asked another way, should a module that did not contain an 
ANY be included?

- Should we create a module that is just the OIDs assigned across all 
the other modules? Should we create two (one for S/MIME, one for 
PKIX), or just a single OIDs module?

Again, we look forward to the discussion.

--Paul Hoffman, Director
--VPN Consortium

To: [email-masked]
Subject: RFC 3280bis is approved
From: Sam Hartman <[email-masked]>
Date: Thu, 10 Jan 2008 13:24:05 -0500 (EST)
Sender: [email-masked]

I'm pleased to report that rfc3280bis was approved the first time it
appeared before the IESG.
That means you have done an excellent job of writing a clear document.

Chris did send in some comments about internationalization that I
would like to ask the working group to consider, but besides that
we're ready to send this to the RFC editor.

Chairs, please let me know how long you think responding to Chris's
comments will take.

Date: Wed, 09 Jan 2008 13:51:43 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Subject: Re: New other certs extension I-D
Sender: [email-masked]

Stephen Kent wrote:
> 
> If this extension is intended to solve a specific problem in this
> realm, then we need to be precise in describing what the problem is,
> and how this extension solves it. I am not comfortable defining an
> extension for which we do not do this.

I concur! The abstract of the draft is pretty sparse regarding the 
motivation for such an extension.

Such a "link" would be a relation between certs. Without specifying the 
relation how can you tell the characteristics of such relation (e.g. R 
being transitive)?
=> I doubt that a simple reference will do for real-world problems.

Ciao, Michael.

-- 
Michael Ströder
E-Mail: [email-masked]
http://www.stroeder.com

Date: Wed, 09 Jan 2008 17:11:12 +1100
From: Steven Legg <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Sender: [email-masked]

Peter,

Peter Gutmann wrote:
> Steven Legg <[email-masked]> writes:
> 
>> User's of eB2Bcom's LDAP/X.500 directory product
> 
> Oh I see, you're from an X.500 directory vendor![0].  It's funny that whenever
> I see someone waxing lyrical about the wonders of X.500 it always seems to be
> because they're peddling X.500 themselves.

That's strange. I thought I was just offering the observation that
numeric identifiers stuffed into DNs are a bad idea in the environment
for which DNs are primarily intended, i.e., LDAP and X.500 directories,
quite apart from the fact that X.520 doesn't allow the commonName
attribute to be used this way.

 > Anyway, I'll let others speak for
> me:
> 
>   So far, LDAP has not done a great job of supporting PKI
>     . Steve Kent, PKIX WG chair

I've implemented the X.509 matching rules in LDAP, and defined and
implemented component matching rules, which provide matching capabilities
beyond what X.509 provides. I'm doing my bit to make LDAP support
PKI better. If there are more things I can do then let me know.
Badly constructed DNs certainly don't help the situation. Making it
easy for folks to produce conformant DNs is something deserving of
further discussion.

> 
>   The X.500 linkage [...] has led to more failed PKI deployments in my
>   experience than any other. For PKI deployment to succeed you have to take
>   X.500 and LDAP deployment out of the critical path.
>     . Phillip Hallam-Baker, Verisign principal scientist
> 
> Continuing in the spirit of quoting others:
> 
>> Pragmatism is all too often cited as a justification for ill-advised
>> behavior. All of your examples of what cab be stuffed into the CN attribute
>> are good examples of what NOT to put there. The penultimate example
>> specifically is disparaged by PKIX standards.
> 
>   I think a lot of purists would rather have PKI be useless to anyone in any
>   practical terms than to have it made simple enough to use, but potentially
>   "flawed".
>     - (IT person at a (very) large multinational after they gave up on PKI in
>        frustration for reasons such as this one).
> 
>> In the early days of TCP/IP, the folks responsible for the BSD implementation
>> decided to NOT calculate the TCP checksum for each packet.  [...]
> 
> The difference here was that TCP/IP took over the world while PKI... oh dear.
> Reciting dogma at potential users rather than helping them solve their real-
> world problems isn't making things any better.  You may be able to sit back
> satisfied that you've preserved the integrity of your precious bodily fluids,
> but it's a hollow victory if the world ends up ignoring your technology
> because of this.
> 
> (If people are getting bored with this I can take it offline, but at the
> moment I'm having way too much fun :-).

I have no interest in rehashing the same old anti-X.500 rhetoric. Can't you
accept that there is a community of people outside PKI that find value in
standards that you have written off, and that can be adversely affected
by a cavalier attitude to the construction of DNs ?

Regards,
Steven

> 
> Peter.
> 
> [0] Imagine James Earl Jones spraying at Steven with a insecticide sprayer:
>     "Out! Back to the sixties! Back! There's no place for you here in the
>     future! Get back while you still can!".
> 

From: Sam Hartman <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked] (Peter Gutmann), [email-masked], [email-masked], [email-masked]
Subject: Re: [secdir] Please review   draft-ietf-capwap-protocol-specification's use of certificates
Date: Tue, 08 Jan 2008 10:20:57 -0500
Sender: [email-masked]

I think the discussion of capwap and the use of CN has served its
purpose at least for the secdir list.  Unless there are significant
new arguments I'll call the discussion closed as far as secdir is
concerned.

I want to thank everyone who participated; we got a lot of great
comments and I think we found ways of recommending improvements to the
capwap working group while maintaining support for market reality.

--Sam

Date: Tue, 8 Jan 2008 09:52:20 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: [secdir] Please review  draft-ietf-capwap-protocol-specification's use of certificates
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 10:57 PM +1300 1/8/08, Peter Gutmann wrote:
>As invariably happens with these things, there are a pile of off-list private
>threads going on that look at this.  I thought the following comment was
>rather interesting, since I'm currently responsible for stirring things up :-)
>I've forwarded it with the author's permission.
>
>Peter.
>
>-- Snip --
>
>Stephen Kent <[email-masked]>:
>
>>I do not agree with the suggestion that we should back off on what
>>constitutes good practice just because a specific piece of (open source)
>>software has limitations in what it supports relative to the standards it
>>purportedly implements.
>
>"do not agree that we should back off ... good practice just because open
>source software has limitatioms..." - Well what about PKIX's non-use of
>modern ASN.1 for almost ten years due to "no freeware modern ASN.1
>compiler available"?? Sigh. Talk about inconsistency.

These are not inconsistent statements, Peter.

Russ argued for some time that we ought not move to the newer ASN.1, 
which offered minor improvements in expressive ability, when the only 
open source ASN.1 compilers were for the older version.  He is now 
making a similar argument about the importance of open source 
software and adoption of PKI technology, using OpenSSL as the 
exemplar.

In the case of ASN.1 compilers, there were several options available 
to implementers, and more than  one of them  was very good. (One was 
commissioned by the U.S  DoD and made available for use in systems 
provided to them.)  In the case of OpenSSL, it is regarded as the de 
facto open source crypto and cert processing software, and it has had 
numerous errors. So, while I agreed with Russ's position on ASN.1, I 
am less sanguine with suggestions that we tailer our view of what 
constitutes good practice based on OpenSSL capabilities.

Steve

Date: Tue, 08 Jan 2008 11:39:09 +0000
From: Stephen Farrell <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: New other certs extension I-D
Sender: [email-masked]

Hi Denis,

Denis Pinkas wrote:
> Stephen,
> 
> It seems that your concern might be solved using RFC 4043: Permanent Identifier.

Certainly worth noting that as a possibility, but I guess I'd have
some concerns:

- I don't think there's a technical need for a permanent identifier for
  this purpose (as I understand it N-R is the main motivator for 4043)
- I'm not sure that there are any real assigner authorities and
  depending on a new name space might just make the problem at hand
  worse
- I've no idea whether 4043 is widely supported or not (mind you, the
  proposed new extension isn't even implemented so that's less of a
  concern)

However, I do agree that were 4043 used, it could solve the problem
at hand, so even if the new extension does go ahead, the spec should
call that out.

> Your proposal is along the following:
> 
>  OtherCertificates ::= SEQUENCE OF IssuerAndSerialNumber
> 
> It would not permit an unambiguous link, since it does not address the case of two CAs 
> that would bear the same name.

Steve K. made a related comment, so if/when I do a -01 I'll likely
change that to use the OCSP or SCVP structure that can link to
the cert via a hash as well.

Cheers,
S.

Date: Tue, 8 Jan 2008 11:27:07 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: New other certs extension I-D
Sender: [email-masked]

Stephen,

It seems that your concern might be solved using RFC 4043: Permanent Identifier.

   The permanent identifier is an optional feature that may be used by a
   CA to indicate that two or more certificates relate to the same
   entity, even if they contain different subject name (DNs) or
   different names in the subjectAltName extension, or if the name or
   the affiliation of that entity stored in the subject or another name
   form in the subjectAltName extension has changed.

      id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }
        PermanentIdentifier ::=     SEQUENCE {
           identifierValue    UTF8String             OPTIONAL,
                           -- if absent, use a serialNumber attribute,
                           -- if there is such an attribute present
                           -- in the subject DN
           assigner           OBJECT IDENTIFIER      OPTIONAL
                           -- if absent, the assigner is
                           -- the certificate issuer
   }

Your proposal is along the following:

 OtherCertificates ::= SEQUENCE OF IssuerAndSerialNumber

It would not permit an unambiguous link, since it does not address the case of two CAs 
that would bear the same name.

Denis

=====================================================

>Hi all,
>
>A problem came up in another forum of how to
>link together various certs belonging (or that
>belonged) to the same end entity. Without some
>additional naming rules beyond 3280 that can
>be tricky so I've written up a one-page-plus-
>boilerpate I-D [1] describing a possible general
>approach.
>
>I don't know if this should or should not
>be a PKIX WG item, but would welcome comments
>(in particular if there's a better way to
>solve the problem with some current extension).
>
>Regards,
>Stephen.
>
>[1] http://www.ietf.org/internet-drafts/draft-farrell-pkix-other-certs-00.txt
>

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 08 Jan 2008 22:57:27 +1300
Sender: [email-masked]

As invariably happens with these things, there are a pile of off-list private
threads going on that look at this.  I thought the following comment was
rather interesting, since I'm currently responsible for stirring things up :-)
I've forwarded it with the author's permission.

Peter.

-- Snip --

Stephen Kent <[email-masked]>:

>I do not agree with the suggestion that we should back off on what
>constitutes good practice just because a specific piece of (open source)
>software has limitations in what it supports relative to the standards it
>purportedly implements.

"do not agree that we should back off ... good practice just because open
source software has limitatioms..." - Well what about PKIX's non-use of
modern ASN.1 for almost ten years due to "no freeware modern ASN.1
compiler available"?? Sigh. Talk about inconsistency.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Cc: [email-masked]
Date: Tue, 08 Jan 2008 21:31:26 +1300
Sender: [email-masked]

Steven Legg <[email-masked]> writes:

>User's of eB2Bcom's LDAP/X.500 directory product

Oh I see, you're from an X.500 directory vendor![0].  It's funny that whenever
I see someone waxing lyrical about the wonders of X.500 it always seems to be
because they're peddling X.500 themselves.  Anyway, I'll let others speak for
me:

  So far, LDAP has not done a great job of supporting PKI
    . Steve Kent, PKIX WG chair

  The X.500 linkage [...] has led to more failed PKI deployments in my
  experience than any other. For PKI deployment to succeed you have to take
  X.500 and LDAP deployment out of the critical path.
    . Phillip Hallam-Baker, Verisign principal scientist

Continuing in the spirit of quoting others:

>Pragmatism is all too often cited as a justification for ill-advised
>behavior. All of your examples of what cab be stuffed into the CN attribute
>are good examples of what NOT to put there. The penultimate example
>specifically is disparaged by PKIX standards.

  I think a lot of purists would rather have PKI be useless to anyone in any
  practical terms than to have it made simple enough to use, but potentially
  "flawed".
    - (IT person at a (very) large multinational after they gave up on PKI in
       frustration for reasons such as this one).

>In the early days of TCP/IP, the folks responsible for the BSD implementation
>decided to NOT calculate the TCP checksum for each packet.  [...]

The difference here was that TCP/IP took over the world while PKI... oh dear.
Reciting dogma at potential users rather than helping them solve their real-
world problems isn't making things any better.  You may be able to sit back
satisfied that you've preserved the integrity of your precious bodily fluids,
but it's a hollow victory if the world ends up ignoring your technology
because of this.

(If people are getting bored with this I can take it offline, but at the
moment I'm having way too much fun :-).

Peter.

[0] Imagine James Earl Jones spraying at Steven with a insecticide sprayer:
    "Out! Back to the sixties! Back! There's no place for you here in the
    future! Get back while you still can!".

Date: Tue, 08 Jan 2008 16:08:08 +1100
From: Steven Legg <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Sender: [email-masked]

Peter,

Peter Gutmann wrote:
> Steven Legg <[email-masked]> writes:
> 
>> One of the modes for accessing a directory is browsing up and down the
>> directory tree.
> 
> And when do people ever do this?

User's of eB2Bcom's LDAP/X.500 directory product do it all the time,
and if you take a step back you'll realize that Google users do much the
same thing. When I use the web interface to the directory I typically start
with a search, which returns a list of matching entries. Clicking on one
of the search results presents a web page with the full details of
the entry along with links to other entries (the superior entry, any
subordinate entries and related entries), which I can click on to
browse through the directory tree. When I use Google it presents a
list of results for my search criteria. Clicking on one of the
search results leads me to a web page (hopefully with relevant content)
that typically has links to other web pages, which I can click on
to browse through the web. The scope and scale are different in each
case, but the user experience is much the same.

> Google, one of the worlds biggest IT
> companies (?), made most of its fortune from the very fact that people don't
> do this.  When did Joe Sixpack last use an Internet directory, and when did
> they last use a non-directory Internet search engine?
> 
> (I'm guessing the answer is pretty close to "never" for the former, and "the
> last time they went online" for the latter).
> 
>> A common name like "Peter Gutmann's Visa Card" is much more informative than
>> the common name "1234 5678 9012 3456".
> 
> To whom is it informative?

To an LDAP or X.500 directory administrator setting up access controls, to
an auditor reviewing directory audit logs, and to ordinary user's following
hyperlinks in the web interface to the directory, among others.

> In what possible context does anyone processing a
> credit card payment care in the remotest manner whether card "1234 5678 9012
> 3456" belongs to "Peter Gutmann" or "The Jolly Green Giant"?

They don't, but there is the entire life-cycle of the credit card records
to consider. The people involved in issuing cards, cancelling cards and
resolving disputed payments probably do care that "1234 5678 9012 3456"
belongs to "Peter Gutmann".

 > All they care
> about is the card number and "authorised/declined".
> 
> (The very existence of anonymous prepaid credit cards prove that card
> processors don't care in the slightest about "Peter Gutmann's Visa Card":
> there's no name associated with the card at all since it has zero value to
> them).
> 
> How about the following compromise between X.500 theologists and pragmatists:
> The pragmatists agree to make all their DNs fully X.500 (well, X.520)
> compliant the moment the global X.500 directory emerges, and in exchange the
> X.500 theologists agree not to bother the pragmatists any more until the
> global X.500 directory emerges.

The validity of X.500 naming is not contingent on the emergence of a global
X.500 directory. LDAP demonstrates that since it uses essentially the same
model, but makes no allusion to a global directory. Since PKIX standards
don't depend on there being a global X.500 directory any more than LDAP
does, making it a precondition for conformance of DNs strikes me as being
a silly proposition.

If PKIX was a world unto its own I wouldn't care what you did with DNs, but
there are LDAP and X.500 clients that expect to find a directory entry
corresponding to a certificate's subject name, so crummy subject DNs have
the potential to adversely affect me. You seem to be acknowledging that
stuffing a credit card number into the commonName attribute is not conformant
with X.520, so I guess you just don't care that such practices are bothersome,
for both practical and theoretical reasons, to people who use DNs to actually
name entries in a directory instead of just as identifiers in certificates.
I have a more practical compromise to offer: if you don't misuse any standard
I care about, then I won't misuse any standard you care about.

Regards,
Steven

> Peter.

Content-class: urn:content-classes:message
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Date: Mon, 7 Jan 2008 17:40:56 -0800
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Scott G. Kelly" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Thanks Scott, 

I agree with your assessment. Supporting the current practice around
using MAC address as CN should be supported.  I also worry that down the
road this restriction will cause problems. 

Since current devices have certs with MAC address in the CN
implementations MUST support MAC address as an identifier within the CN
of the cert.  We should add discussion of the problems of this approach
discussed by Steve. Implementations SHOULD also provide support for
identifier strings (which may or may not be MAC address) in the
SerialNumber field (possibly subjectAltName or some other field if it
makes sense).  

I think this is similar to what Sam suggested. 

Cheers,

Joe

> -----Original Message-----
> From: Scott G. Kelly [mailto:[email-masked]] 
> Sent: Monday, January 07, 2008 10:42 AM
> To: Joseph Salowey (jsalowey); Stephen Kent; Sam Hartman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [secdir] Please review 
> draft-ietf-capwap-protocol-specification's use of certificates
> 
> Hi Joe,
> 
> jsalowey wrote:
> >It seems that stating that the identifier used in a 
> certificate MUST be 
> >a MAC address may be overly restrictive.  It seems you would want to 
> >allow for MAC address, but not require it.  Is there a 
> reason why the 
> >identifier needs to be a MAC address (if I understand 
> correctly the AC 
> >and WTP may not be directly L2 connected and may not have direct 
> >knowledge of each others MAC address)?
> >
> >Why wouldn't another identifier string be acceptable?  
> >
> >Is the MAC address interpreted by the peer or is it just an 
> identifier 
> >string?
> >
> >If there are multiple MAC addresses which one is used?
> 
> These are all good questions. The MAC was originally chosen 
> for two reasons:
> 
> 1) in the initial LWAPP design, devices were always directly 
> connected (it was a L2 protocol which was later extended to 
> include L3 support)
> 
> 2) at the time, this was the convention for 
> DOCSIS/PacketCable, and the guy who suggested that it be 
> included in LWAPP device certs (me) didn't know there was 
> anything incorrect about this approach. 
> 
> Since MAC addresses are not typically assigned to more than 
> one device, it seems like a reasonable choice for a 
> vendor-independent approach to network device identification. 
> Still, as you point out, many devices have more than one MAC 
> address, and this raises the question of, which one?
> 
> In any event, there are a *lot* of legacy devices out there 
> that follow this convention today, and that was the rationale 
> for my introduction of the term "pragmatic" in my reply to Steve. 
> 
> I wasn't suggesting that we introduce a hack to cut corners, 
> and if I had to say over again, my comments would be more in 
> line with Bernard's follow up post, i.e. there are lots of 
> devices out there that already do this, and it is not very 
> practical (pragmatic?) to define a standard that will not be 
> backwardly compatible with these devices.
> 
> I think it's really important to understand 2 things with 
> respect to legacy devices employing this convention: first, 
> they typically inject certs during manufacturing, and 
> changing this will be, in many cases, non-trivial. There are 
> PKI vendors (e.g. Verisign) which provide manufacturing 
> services supporting this convention, so such changes would 
> have potentially far-reaching implications. Second, replacing 
> the already-deployed certs is a non-starter for most vendors. 
> Hence, we need a solution which somehow accommodates this convention.
> 
> I'm not sure what the best solution is going forward. I agree 
> that the Serial Number attribute is more appropriate than CN, 
> but I think we have to accommodate deployed devices. Do we 
> change the convention now, but still permit the MAC-as-CN, or 
> do we simply continue to use the MAC-as-CN? 
> 
> I think it's reasonable to discuss what you've suggested 
> above, i.e. accept the MAC in the CN, but recommend something 
> different (don't make CN=MAC a MUST).
> 
> Scott
> 
> >Joe
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Scott G. Kelly
> >> Sent: Friday, December 21, 2007 1:55 PM
> >> To: Stephen Kent; Sam Hartman
> >> Cc: [email-masked]; [email-masked]; [email-masked]
> >> Subject: Re: [secdir] Please review
> >> draft-ietf-capwap-protocol-specification's use of certificates
> >> 
> >> Hi Steve,
> >> 
> >> Thanks for taking a look at this. Regarding placement of 
> the MAC in 
> >> the CN, I would offer two observations:
> >> 
> >> 1) this is what is specified in the DOCSIS and PacketCable cert 
> >> profiles, and it was on this basis that device certs for 
> LWAPP were 
> >> originally designed in this way. You can see the DOCSIS profile at 
> >> www.drizzle.com/~aboba/CPW/DOCSIS.ppt
> >> 
> >> 2) I don't see anything in the X.520 language that explicitly 
> >> precludes this usage, so assuming that the docsis/packetcable 
> >> designers reviewed that spec, I can see how they could reasonably 
> >> conclude that this is acceptable. Arguably, the string 
> representation 
> >> of the MAC address is "a string chosen [by the] organization 
> >> responsible for the object it describes for devices and 
> application 
> >> entities".
> >> 
> >> Please don't misunderstand: I'm not trying to be difficult, and I 
> >> have a very healthy respect for the depth of your 
> knowledge in this 
> >> area. However, there are a *lot* of devices deployed that 
> already use 
> >> this convention. It might be more pragmatic to interpret X.520 a 
> >> little less restrictively.
> >> 
> >> Scott
> >> 
> >> -----Original Message-----
> >> >From: Stephen Kent <[email-masked]>
> >> >Sent: Dec 21, 2007 3:00 PM
> >> >To: Sam Hartman <[email-masked]>
> >> >Cc: [email-masked], [email-masked], 
> [email-masked]
> >> >Subject: Re: [secdir] Please review 
> >> >draft-ietf-capwap-protocol-specification's use of certificates
> >> >
> >> >At 9:23 PM -0500 12/20/07, Sam Hartman wrote:
> >> >>Hi, folks.  The capwap working group is preparing to last
> >> call their
> >> >>protocol specification draft.
> >> >>
> >> >>I'd appreciate review from the pkix community of section 2.4.4.3 
> >> >>and
> >> >>12.6 of this draft.  These sections specify certificate
> >> validation and
> >> >>certificate usage for the protocol.  Scott Kelly and 
> Charles Clancy 
> >> >>are security advisors for the working group and have 
> been heavily 
> >> >>involved.
> >> >>
> >> >>The capwap certificate profile assumes that the CN in the
> >> certificate
> >> >>has structure and contains an ethernet MAC address.  The capwap 
> >> >>certificate profile also assumes that parts of the subject
> >> name such
> >> >>as the organization and organizational unit will be important to 
> >> >>certificate matching.
> >> >>
> >> >>I'd appreciate review and comments.
> >> >>
> >> >>--Sam
> >> >
> >> >It would be preferable to get an allocated name space for MAC 
> >> >addresses, under the OtherName or, better yet, under registeredID.
> >> >
> >> >I'd argue that it is inappropriate to put a MAC address 
> into a CN. 
> >> >The text from X.520 makes this clear:
> >> >
> >> >The Common Name attribute type specifies an identifier of 
> an object. 
> >> >A Common Name is not a directory name; it is a (possibly 
> ambiguous) 
> >> >name by which the object is commonly known in some limited
> >> scope (such
> >> >as an organization) and conforms to the naming conventions of the 
> >> >country or culture with which it is associated.
> >> >
> >> >An attribute value for common name is a string chosen 
> either by the 
> >> >person or organization it describes or the organization
> >> responsible for
> >> >the object it describes for devices and application entities. For 
> >> >example, a typical name of a person in an 
> English-speaking country 
> >> >comprises a personal title (e.g., Mr., Ms., Rd, Professor,
> >> Sir, Lord),
> >> >a first name, middle name(s), last name, generation
> >> qualifier (if any,
> >> >e.g., Jr.) and decorations and awards (if any e.g., QC).
> >> >
> >> >Examples
> >> >CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE"
> >> >CN = "Divisional Coordination Committee"
> >> >CN = "High Speed Modem".
> >> >
> >> >If there is a very strong desire to make use of an existing
> >> attribute
> >> >in the X.502 space, the SerialNumber attribute makes more 
> sense. So 
> >> >long as we are talking about long, term, stable MAC
> >> addresses assigned
> >> >to devices by manufacturers, this is consistent with the
> >> semantics of
> >> >that attribute.  Moreover, we have advised folks to use
> >> SerialNumber to
> >> >represent data such as employee/student IDs in the past, so
> >> one might
> >> >expect to see support for this attribute in many CAs and clients.
> >> >
> >> >Steve
> >> 
> >> _______________________________________________
> >> secdir mailing list
> >> [email-masked]
> >> https://mailman.mit.edu/mailman/listinfo/secdir
> >> 
> 
> 

Date: Mon, 7 Jan 2008 15:49:35 -0500
To: Russ Housley <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: [secdir] Please review   draft-ietf-capwap-protocol-specification's use of certificates
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 3:20 PM -0500 1/7/08, Russ Housley wrote:
>I think we disagree on the details of the CN=MAC Address situation.
>
>CableLabs has been using this convention for a long time.  Other 
>communities have followed this example because it has worked well 
>for CableLabs.  While I think that defining a naming attribute for 
>the MAC address might have been cleaner many respects, I understand 
>why this was not done.  People want to make use of software that is 
>readily available, such as OpenSSL's certificate libraries. 
>Teaching these libraries about new naming attributes is not simple, 
>so people stick with the attributes that are readily available.
>
>Russ

I concur with your assessment of why people made the choice, which is 
why I agree that we have to live with it in this case.

I do not agree with the suggestion that we should back off on what 
constitutes good practice just because a specific piece of (open 
source) software has limitations in what it supports relative to the 
standards it purportedly implements. We have seen numerous 
limitations and several errors in the OpenSSL code over time.

I'm sure your agree that openSSL is NOT a reference implementation 
for X.509 nor PKIX standards, right?

Steve

Content-class: urn:content-classes:message
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Date: Mon, 7 Jan 2008 15:02:47 -0800
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Mani, Mahalingam (Mani)" <[email-masked]>, "Scott G. Kelly" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Pat Calhoun (pacalhou)" <[email-masked]>, "Dorothy Stanley" <[email-masked]>
Sender: [email-masked]

Hi Mani,

A MAC address is an acceptable identifier string, however if it is just
an identifier string I am not sure it is appropriate to limit it to MAC
address as the only possible identifier string.  MAC address is
currently deployed in the CN field.  I would have to defer to Steve and
others as to how appropriate this usage is with respect to PKIX and
X.509.  

Joe

> -----Original Message-----
> From: Mani, Mahalingam (Mani) [mailto:[email-masked]] 
> Sent: Monday, January 07, 2008 10:32 AM
> To: Joseph Salowey (jsalowey); Scott G. Kelly; Stephen Kent; 
> Sam Hartman
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Pat Calhoun (pacalhou); Dorothy Stanley
> Subject: RE: [secdir] Please review 
> draft-ietf-capwap-protocol-specification's use of certificates
> 
> If you look at the section (PSK usage) it becomes more 
> evident that MAC address is intended as a means of using a 
> namespace for unique identifier for WTP.
> 
> So - the extent to which the peer AC interprets is for that 
> identification of belonging to a database with a certain 
> assurance of uniqueness without having to create another 
> device namespace. It was perhaps partly motivated by other 
> prior practices such as from cablelabs & DOCSIS.
> 
> It is not intended as a runtime-verification at L2 (since 
> WTPs and AC deployment can span across routers).
> 
> So - does MAC address used thus qualify as acceptable 
> identifier string in your interpretation?
> 
> If so - does that still make this form of usage in CN acceptable?
> 
> My understanding is the LAN-side MAC address that is used 
> (not the radio addresses). I will let the CAPWAP authors clarify that.
> 
> -mani
> -----Original Message-----
> From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> Sent: Monday, January 07, 2008 9:32 AM
> To: Scott G. Kelly; Stephen Kent; Sam Hartman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [secdir] Please review
> draft-ietf-capwap-protocol-specification's use of certificates
> 
> It seems that stating that the identifier used in a 
> certificate MUST be a MAC address may be overly restrictive.  
> It seems you would want to allow for MAC address, but not 
> require it.  Is there a reason why the identifier needs to be 
> a MAC address (if I understand correctly the AC and WTP may 
> not be directly L2 connected and may not have direct 
> knowledge of each others MAC address)?  
> Why wouldn't another identifier string be acceptable?  
> Is the MAC address interpreted by the peer or is it just an 
> identifier string?
> If there are multiple MAC addresses which one is used?
> 
> Joe
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Scott G. Kelly
> > Sent: Friday, December 21, 2007 1:55 PM
> > To: Stephen Kent; Sam Hartman
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: [secdir] Please review
> > draft-ietf-capwap-protocol-specification's use of certificates
> > 
> > Hi Steve,
> > 
> > Thanks for taking a look at this. Regarding placement of the MAC in 
> > the CN, I would offer two observations:
> > 
> > 1) this is what is specified in the DOCSIS and PacketCable cert 
> > profiles, and it was on this basis that device certs for LWAPP were 
> > originally designed in this way. You can see the DOCSIS profile at 
> > www.drizzle.com/~aboba/CPW/DOCSIS.ppt
> > 
> > 2) I don't see anything in the X.520 language that explicitly 
> > precludes this usage, so assuming that the docsis/packetcable 
> > designers reviewed that spec, I can see how they could reasonably 
> > conclude that this is acceptable. Arguably, the string 
> representation 
> > of the MAC address is "a string chosen [by the] organization 
> > responsible for the object it describes for devices and application 
> > entities".
> > 
> > Please don't misunderstand: I'm not trying to be difficult, 
> and I have 
> > a very healthy respect for the depth of your knowledge in 
> this area. 
> > However, there are a *lot* of devices deployed that already 
> use this 
> > convention. It might be more pragmatic to interpret X.520 a little 
> > less restrictively.
> > 
> > Scott
> > 
> > -----Original Message-----
> > >From: Stephen Kent <[email-masked]>
> > >Sent: Dec 21, 2007 3:00 PM
> > >To: Sam Hartman <[email-masked]>
> > >Cc: [email-masked], [email-masked], [email-masked]
> > >Subject: Re: [secdir] Please review
> > >draft-ietf-capwap-protocol-specification's use of certificates
> > >
> > >At 9:23 PM -0500 12/20/07, Sam Hartman wrote:
> > >>Hi, folks.  The capwap working group is preparing to last
> > call their
> > >>protocol specification draft.
> > >>
> > >>I'd appreciate review from the pkix community of section 
> 2.4.4.3 and
> > >>12.6 of this draft.  These sections specify certificate
> > validation and
> > >>certificate usage for the protocol.  Scott Kelly and 
> Charles Clancy 
> > >>are security advisors for the working group and have been heavily 
> > >>involved.
> > >>
> > >>The capwap certificate profile assumes that the CN in the
> > certificate
> > >>has structure and contains an ethernet MAC address.  The capwap 
> > >>certificate profile also assumes that parts of the subject
> > name such
> > >>as the organization and organizational unit will be important to 
> > >>certificate matching.
> > >>
> > >>I'd appreciate review and comments.
> > >>
> > >>--Sam
> > >
> > >It would be preferable to get an allocated name space for MAC 
> > >addresses, under the OtherName or, better yet, under registeredID.
> > >
> > >I'd argue that it is inappropriate to put a MAC address into a CN. 
> > >The text from X.520 makes this clear:
> > >
> > >The Common Name attribute type specifies an identifier of 
> an object. 
> > >A Common Name is not a directory name; it is a (possibly 
> ambiguous) 
> > >name by which the object is commonly known in some limited
> > scope (such
> > >as an organization) and conforms to the naming conventions of the 
> > >country or culture with which it is associated.
> > >
> > >An attribute value for common name is a string chosen 
> either by the 
> > >person or organization it describes or the organization
> > responsible for
> > >the object it describes for devices and application entities. For 
> > >example, a typical name of a person in an English-speaking country 
> > >comprises a personal title (e.g., Mr., Ms., Rd, Professor,
> > Sir, Lord),
> > >a first name, middle name(s), last name, generation
> > qualifier (if any,
> > >e.g., Jr.) and decorations and awards (if any e.g., QC).
> > >
> > >Examples
> > >CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE"
> > >CN = "Divisional Coordination Committee"
> > >CN = "High Speed Modem".
> > >
> > >If there is a very strong desire to make use of an existing
> > attribute
> > >in the X.502 space, the SerialNumber attribute makes more 
> sense. So 
> > >long as we are talking about long, term, stable MAC
> > addresses assigned
> > >to devices by manufacturers, this is consistent with the
> > semantics of
> > >that attribute.  Moreover, we have advised folks to use
> > SerialNumber to
> > >represent data such as employee/student IDs in the past, so
> > one might
> > >expect to see support for this attribute in many CAs and clients.
> > >
> > >Steve
> > 
> > _______________________________________________
> > secdir mailing list
> > [email-masked]
> > https://mailman.mit.edu/mailman/listinfo/secdir
> > 
> 

Content-class: urn:content-classes:message
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Date: Mon, 7 Jan 2008 16:48:09 -0500
From: "Ogle Ron" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I've been sending these emails to the Cable Labs folks with the
intention of getting them involved.  I'm thinking that this is a great
opportunity to improve interoperability especially between different
domains.  It is also maybe an opportunity to reduce the number of
purpose specific certs that are used in Cable Modems as has been a
stated goal by Cable Labs.

We can see that the DOCSIS standards are having impact outside of their
specific domain of cable modem interoperability.  As I've stated before,
we are using a similar model in other types of electronics products, and
I know of other manufacturers headed in the same direction.

The DOCSIS 3.0 standards could still be changed I believe.  This could
be a path to righting some wrongs if they are really wrong.  I'm not
sure they are wrong, but I do know that we are going to be moving down
this path of CN=MAC for even more products very soon.

Speaking for myself and the certs that I create under DOCSIS (+10M/yr),
it would not be a difficult change.  However, there are a lot of other
components that would be affected.  Again, the DOCSIS 3.0 effort would
go a long way in providing cover for such a change.

I'm not for or against such a change, but I do think that there is a
fleeting opportunity if change is needed.

Thanks
Ron Ogle
Thomson Product Security

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Scott G. Kelly
> Sent: Monday, January 07, 2008 1:42 PM
> To: Joseph Salowey (jsalowey); Stephen Kent; Sam Hartman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [secdir] Please review 
> draft-ietf-capwap-protocol-specification's use of certificates
> 
> 
> Hi Joe,
> 
> jsalowey wrote:
> >It seems that stating that the identifier used in a 
> certificate MUST be
> >a MAC address may be overly restrictive.  It seems you would want to
> >allow for MAC address, but not require it.  Is there a reason why the
> >identifier needs to be a MAC address (if I understand 
> correctly the AC
> >and WTP may not be directly L2 connected and may not have direct
> >knowledge of each others MAC address)?  
> >
> >Why wouldn't another identifier string be acceptable?  
> >
> >Is the MAC address interpreted by the peer or is it just an 
> identifier
> >string?
> >
> >If there are multiple MAC addresses which one is used?
> 
> These are all good questions. The MAC was originally chosen 
> for two reasons:
> 
> 1) in the initial LWAPP design, devices were always directly 
> connected (it was a L2 protocol which was later extended to 
> include L3 support)
> 
> 2) at the time, this was the convention for 
> DOCSIS/PacketCable, and the guy who suggested that it be 
> included in LWAPP device certs (me) didn't know there was 
> anything incorrect about this approach. 
> 
> Since MAC addresses are not typically assigned to more than 
> one device, it seems like a reasonable choice for a 
> vendor-independent approach to network device identification. 
> Still, as you point out, many devices have more than one MAC 
> address, and this raises the question of, which one?
> 
> In any event, there are a *lot* of legacy devices out there 
> that follow this convention today, and that was the rationale 
> for my introduction of the term "pragmatic" in my reply to Steve. 
> 
> I wasn't suggesting that we introduce a hack to cut corners, 
> and if I had to say over again, my comments would be more in 
> line with Bernard's follow up post, i.e. there are lots of 
> devices out there that already do this, and it is not very 
> practical (pragmatic?) to define a standard that will not be 
> backwardly compatible with these devices.
> 
> I think it's really important to understand 2 things with 
> respect to legacy devices employing this convention: first, 
> they typically inject certs during manufacturing, and 
> changing this will be, in many cases, non-trivial. There are 
> PKI vendors (e.g. Verisign) which provide manufacturing 
> services supporting this convention, so such changes would 
> have potentially far-reaching implications. Second, replacing 
> the already-deployed certs is a non-starter for most vendors. 
> Hence, we need a solution which somehow accommodates this convention.
> 
> I'm not sure what the best solution is going forward. I agree 
> that the Serial Number attribute is more appropriate than CN, 
> but I think we have to accommodate deployed devices. Do we 
> change the convention now, but still permit the MAC-as-CN, or 
> do we simply continue to use the MAC-as-CN? 
> 
> I think it's reasonable to discuss what you've suggested 
> above, i.e. accept the MAC in the CN, but recommend something 
> different (don't make CN=MAC a MUST).
> 
> Scott
> 
> >Joe
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] 
> >> On Behalf Of Scott G. Kelly
> >> Sent: Friday, December 21, 2007 1:55 PM
> >> To: Stephen Kent; Sam Hartman
> >> Cc: [email-masked]; [email-masked]; [email-masked]
> >> Subject: Re: [secdir] Please review 
> >> draft-ietf-capwap-protocol-specification's use of certificates
> >> 
> >> Hi Steve,
> >> 
> >> Thanks for taking a look at this. Regarding placement of the 
> >> MAC in the CN, I would offer two observations: 
> >> 
> >> 1) this is what is specified in the DOCSIS and PacketCable 
> >> cert profiles, and it was on this basis that device certs for 
> >> LWAPP were originally designed in this way. You can see the 
> >> DOCSIS profile at www.drizzle.com/~aboba/CPW/DOCSIS.ppt
> >> 
> >> 2) I don't see anything in the X.520 language that explicitly 
> >> precludes this usage, so assuming that the docsis/packetcable 
> >> designers reviewed that spec, I can see how they could 
> >> reasonably conclude that this is acceptable. Arguably, the 
> >> string representation of the MAC address is "a string chosen 
> >> [by the] organization responsible for the object it describes 
> >> for devices and application entities". 
> >> 
> >> Please don't misunderstand: I'm not trying to be difficult, 
> >> and I have a very healthy respect for the depth of your 
> >> knowledge in this area. However, there are a *lot* of devices 
> >> deployed that already use this convention. It might be more 
> >> pragmatic to interpret X.520 a little less restrictively.
> >> 
> >> Scott
> >> 
> >> -----Original Message-----
> >> >From: Stephen Kent <[email-masked]>
> >> >Sent: Dec 21, 2007 3:00 PM
> >> >To: Sam Hartman <[email-masked]>
> >> >Cc: [email-masked], [email-masked], 
> [email-masked]
> >> >Subject: Re: [secdir] Please review 
> >> >draft-ietf-capwap-protocol-specification's use of certificates
> >> >
> >> >At 9:23 PM -0500 12/20/07, Sam Hartman wrote:
> >> >>Hi, folks.  The capwap working group is preparing to last 
> >> call their 
> >> >>protocol specification draft.
> >> >>
> >> >>I'd appreciate review from the pkix community of section 
> 2.4.4.3 and
> >> >>12.6 of this draft.  These sections specify certificate 
> >> validation and 
> >> >>certificate usage for the protocol.  Scott Kelly and 
> Charles Clancy 
> >> >>are security advisors for the working group and have 
> been heavily 
> >> >>involved.
> >> >>
> >> >>The capwap certificate profile assumes that the CN in the 
> >> certificate 
> >> >>has structure and contains an ethernet MAC address.  The capwap 
> >> >>certificate profile also assumes that parts of the subject 
> >> name such 
> >> >>as the organization and organizational unit will be important to 
> >> >>certificate matching.
> >> >>
> >> >>I'd appreciate review and comments.
> >> >>
> >> >>--Sam
> >> >
> >> >It would be preferable to get an allocated name space for MAC 
> >> >addresses, under the OtherName or, better yet, under registeredID.
> >> >
> >> >I'd argue that it is inappropriate to put a MAC address 
> into a CN. 
> >> >The text from X.520 makes this clear:
> >> >
> >> >The Common Name attribute type specifies an identifier of 
> an object. 
> >> >A Common Name is not a directory name; it is a (possibly 
> ambiguous) 
> >> >name by which the object is commonly known in some limited 
> >> scope (such 
> >> >as an organization) and conforms to the naming conventions of the 
> >> >country or culture with which it is associated.
> >> >
> >> >An attribute value for common name is a string chosen 
> either by the 
> >> >person or organization it describes or the organization 
> >> responsible for 
> >> >the object it describes for devices and application entities. For 
> >> >example, a typical name of a person in an 
> English-speaking country 
> >> >comprises a personal title (e.g., Mr., Ms., Rd, Professor, 
> >> Sir, Lord), 
> >> >a first name, middle name(s), last name, generation 
> >> qualifier (if any, 
> >> >e.g., Jr.) and decorations and awards (if any e.g., QC).
> >> >
> >> >Examples
> >> >CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE"
> >> >CN = "Divisional Coordination Committee"
> >> >CN = "High Speed Modem".
> >> >
> >> >If there is a very strong desire to make use of an existing 
> >> attribute 
> >> >in the X.502 space, the SerialNumber attribute makes more 
> sense. So 
> >> >long as we are talking about long, term, stable MAC 
> >> addresses assigned 
> >> >to devices by manufacturers, this is consistent with the 
> >> semantics of 
> >> >that attribute.  Moreover, we have advised folks to use 
> >> SerialNumber to 
> >> >represent data such as employee/student IDs in the past, so 
> >> one might 
> >> >expect to see support for this attribute in many CAs and clients.
> >> >
> >> >Steve
> >> 
> >> _______________________________________________
> >> secdir mailing list
> >> [email-masked]
> >> https://mailman.mit.edu/mailman/listinfo/secdir
> >> 
> 
> 

Date: Mon, 07 Jan 2008 15:20:03 -0500
To: Stephen Kent <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

I think we disagree on the details of the CN=MAC Address situation.

CableLabs has been using this convention for a long time.  Other 
communities have followed this example because it has worked well for 
CableLabs.  While I think that defining a naming attribute for the 
MAC address might have been cleaner many respects, I understand why 
this was not done.  People want to make use of software that is 
readily available, such as OpenSSL's certificate libraries.  Teaching 
these libraries about new naming attributes is not simple, so people 
stick with the attributes that are readily available.

Russ

At 10:59 AM 1/7/2008, Stephen Kent wrote:

>At 10:05 PM +1300 1/5/08, Peter Gutmann wrote:
>>Stephen Kent <[email-masked]> writes:
>>
>>>If the DOCSIS and PacketCable specs preceded the X.520 publication, this
>>>would have been a good argument. But these specs came along much later. The
>>>folks at Cable Labs who decided to put the MAC address in the 
>>>CN  made a poor
>>>choice.
>>
>>Only in the eyes of X.500 theologists.  As a pragmatic decision 
>>it's perfectly
>>appropriate.  If you're identifying a CC holder, the CN is your credit card
>>number.  If you're identifying a taxpayer, the CN is the taxpayer ID.  If
>>you're identifying a web server, the CN is the server's URL/FQDN.  If you're
>>identifying a piece of hardware addressed by MAC address, the CN is the MAC
>>address.
>
>Pragmatism is all too often cited as a justification for ill-advised 
>behavior. All of your examples of what cab be stuffed into the CN 
>attribute are good examples of what NOT to put there. The 
>penultimate example specifically is disparaged by PKIX standards.
>
>In the early days of TCP/IP, the folks responsible for the BSD 
>implementation decided to NOT calculate the TCP checksum for each 
>packet.  Pragmatically, they found the Ethernet MAC layer CRC to 
>suffice and having to calculate the TCP checksum slowed down their 
>implementation. The fact that a standard defined what to put in the 
>the TCP checksum field was irrelevant to them, based on a purely 
>local, pragmatic view of the situation.
>
>I see echos of that mentality here.
>
>Steve
>

Date: Mon, 7 Jan 2008 15:12:10 -0500
To: Stephen Farrell <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: New other certs extension I-D
Cc: [email-masked]
Sender: [email-masked]

Steve,

If you have time to generate a 01 draft that tries to address the 
concerns I raised, then we can put this on the agenda for March.

Steve

From: Sam Hartman <[email-masked]>
To: "Scott G. Kelly" <[email-masked]>
Cc: "Joseph Salowey (jsalowey)" <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [secdir] Please review  draft-ietf-capwap-protocol-specification's use of certificates
Date: Mon, 07 Jan 2008 14:29:34 -0500
Sender: [email-masked]

>>>>> "Scott" == Scott G Kelly <[email-masked]> writes:

    Scott> Hi Joe,
    Scott> jsalowey wrote:
    >> It seems that stating that the identifier used in a certificate
    >> MUST be a MAC address may be overly restrictive.  It seems you
    >> would want to allow for MAC address, but not require it.  Is
    >> there a reason why the identifier needs to be a MAC address (if
    >> I understand correctly the AC and WTP may not be directly L2
    >> connected and may not have direct knowledge of each others MAC
    >> address)?
    >> 
    >> Why wouldn't another identifier string be acceptable?
    >> 
    >> Is the MAC address interpreted by the peer or is it just an
    >> identifier string?
    >> 
    >> If there are multiple MAC addresses which one is used?

Joe, I proposed a text change to the WG that implementations must
support certs with MAC addresses, but not that all capwap certs had to
use mac address.

Date: Mon, 7 Jan 2008 14:21:01 -0500
To: "Mani, Mahalingam (Mani)" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [secdir] Please review  draft-ietf-capwap-protocol-specification's use of certificates
Cc: "Joseph Salowey (jsalowey)" <[email-masked]>, "Scott G. Kelly" <[email-masked]>, "Sam Hartman" <[email-masked]>, [email-masked], [email-masked], [email-masked], "Pat Calhoun \(pacalhou\)" <[email-masked]>, Dorothy Stanley <[email-masked]>
Sender: [email-masked]

At 11:31 AM -0700 1/7/08, Mani, Mahalingam (Mani) wrote:
>If you look at the section (PSK usage) it becomes more evident that MAC
>address is intended as a means of using a namespace for unique
>identifier for WTP.
>
>So - the extent to which the peer AC interprets is for that
>identification of belonging to a database with a certain assurance of
>uniqueness without having to create another device namespace. It was
>perhaps partly motivated by other prior practices such as from cablelabs
>& DOCSIS.
>
>It is not intended as a runtime-verification at L2 (since WTPs and AC
>deployment can span across routers).
>
>So - does MAC address used thus qualify as acceptable identifier string
>in your interpretation?
>
>If so - does that still make this form of usage in CN acceptable?
>
>My understanding is the LAN-side MAC address that is used (not the radio
>addresses). I will let the CAPWAP authors clarify that.
>
>-mani

Mani,

I think the bottom line has been lost in the recent set of messages. 
My position, (stated in messages at least a week ago) as the SECDIR 
review for the document is:

	- CAPWAP needs to adopt the X.509 Subject DN convention 
adopted by the DOCSIS and later CableLabs specs, that calls for 
putting the MAC address in the CM field.

	- The document needs to justify this misuse of CN to 
represent the MAC address on that basis, and hence needs to cite the 
relevant specs.

	- the document should indicate that this use of NOT 
consistent with X.520 and PKIX standards, but has been used here for 
backwards compatibility.

	- it would be nice if future specs of this sort would employ 
the SerialNumber attribute for the MAC address IF there is a strong 
need to use the Subject field; the preferred solution would be to use 
a Subject Alternative Name and define a name space specifically for 
MAC addresses.

Steve

Date: Mon, 7 Jan 2008 10:42:22 -0800 (GMT-08:00)
From: "Scott G. Kelly" <[email-masked]>
Reply-To: "Scott G. Kelly" <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>, Stephen Kent <[email-masked]>, Sam Hartman <[email-masked]>
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Hi Joe,

jsalowey wrote:
>It seems that stating that the identifier used in a certificate MUST be
>a MAC address may be overly restrictive.  It seems you would want to
>allow for MAC address, but not require it.  Is there a reason why the
>identifier needs to be a MAC address (if I understand correctly the AC
>and WTP may not be directly L2 connected and may not have direct
>knowledge of each others MAC address)?  
>
>Why wouldn't another identifier string be acceptable?  
>
>Is the MAC address interpreted by the peer or is it just an identifier
>string?
>
>If there are multiple MAC addresses which one is used?

These are all good questions. The MAC was originally chosen for two reasons:

1) in the initial LWAPP design, devices were always directly connected (it was a L2 protocol which was later extended to include L3 support)

2) at the time, this was the convention for DOCSIS/PacketCable, and the guy who suggested that it be included in LWAPP device certs (me) didn't know there was anything incorrect about this approach. 

Since MAC addresses are not typically assigned to more than one device, it seems like a reasonable choice for a vendor-independent approach to network device identification. Still, as you point out, many devices have more than one MAC address, and this raises the question of, which one?

In any event, there are a *lot* of legacy devices out there that follow this convention today, and that was the rationale for my introduction of the term "pragmatic" in my reply to Steve. 

I wasn't suggesting that we introduce a hack to cut corners, and if I had to say over again, my comments would be more in line with Bernard's follow up post, i.e. there are lots of devices out there that already do this, and it is not very practical (pragmatic?) to define a standard that will not be backwardly compatible with these devices.

I think it's really important to understand 2 things with respect to legacy devices employing this convention: first, they typically inject certs during manufacturing, and changing this will be, in many cases, non-trivial. There are PKI vendors (e.g. Verisign) which provide manufacturing services supporting this convention, so such changes would have potentially far-reaching implications. Second, replacing the already-deployed certs is a non-starter for most vendors. Hence, we need a solution which somehow accommodates this convention.

I'm not sure what the best solution is going forward. I agree that the Serial Number attribute is more appropriate than CN, but I think we have to accommodate deployed devices. Do we change the convention now, but still permit the MAC-as-CN, or do we simply continue to use the MAC-as-CN? 

I think it's reasonable to discuss what you've suggested above, i.e. accept the MAC in the CN, but recommend something different (don't make CN=MAC a MUST).

Scott

>Joe
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>> On Behalf Of Scott G. Kelly
>> Sent: Friday, December 21, 2007 1:55 PM
>> To: Stephen Kent; Sam Hartman
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> Subject: Re: [secdir] Please review 
>> draft-ietf-capwap-protocol-specification's use of certificates
>> 
>> Hi Steve,
>> 
>> Thanks for taking a look at this. Regarding placement of the 
>> MAC in the CN, I would offer two observations: 
>> 
>> 1) this is what is specified in the DOCSIS and PacketCable 
>> cert profiles, and it was on this basis that device certs for 
>> LWAPP were originally designed in this way. You can see the 
>> DOCSIS profile at www.drizzle.com/~aboba/CPW/DOCSIS.ppt
>> 
>> 2) I don't see anything in the X.520 language that explicitly 
>> precludes this usage, so assuming that the docsis/packetcable 
>> designers reviewed that spec, I can see how they could 
>> reasonably conclude that this is acceptable. Arguably, the 
>> string representation of the MAC address is "a string chosen 
>> [by the] organization responsible for the object it describes 
>> for devices and application entities". 
>> 
>> Please don't misunderstand: I'm not trying to be difficult, 
>> and I have a very healthy respect for the depth of your 
>> knowledge in this area. However, there are a *lot* of devices 
>> deployed that already use this convention. It might be more 
>> pragmatic to interpret X.520 a little less restrictively.
>> 
>> Scott
>> 
>> -----Original Message-----
>> >From: Stephen Kent <[email-masked]>
>> >Sent: Dec 21, 2007 3:00 PM
>> >To: Sam Hartman <[email-masked]>
>> >Cc: [email-masked], [email-masked], [email-masked]
>> >Subject: Re: [secdir] Please review 
>> >draft-ietf-capwap-protocol-specification's use of certificates
>> >
>> >At 9:23 PM -0500 12/20/07, Sam Hartman wrote:
>> >>Hi, folks.  The capwap working group is preparing to last 
>> call their 
>> >>protocol specification draft.
>> >>
>> >>I'd appreciate review from the pkix community of section 2.4.4.3 and
>> >>12.6 of this draft.  These sections specify certificate 
>> validation and 
>> >>certificate usage for the protocol.  Scott Kelly and Charles Clancy 
>> >>are security advisors for the working group and have been heavily 
>> >>involved.
>> >>
>> >>The capwap certificate profile assumes that the CN in the 
>> certificate 
>> >>has structure and contains an ethernet MAC address.  The capwap 
>> >>certificate profile also assumes that parts of the subject 
>> name such 
>> >>as the organization and organizational unit will be important to 
>> >>certificate matching.
>> >>
>> >>I'd appreciate review and comments.
>> >>
>> >>--Sam
>> >
>> >It would be preferable to get an allocated name space for MAC 
>> >addresses, under the OtherName or, better yet, under registeredID.
>> >
>> >I'd argue that it is inappropriate to put a MAC address into a CN. 
>> >The text from X.520 makes this clear:
>> >
>> >The Common Name attribute type specifies an identifier of an object. 
>> >A Common Name is not a directory name; it is a (possibly ambiguous) 
>> >name by which the object is commonly known in some limited 
>> scope (such 
>> >as an organization) and conforms to the naming conventions of the 
>> >country or culture with which it is associated.
>> >
>> >An attribute value for common name is a string chosen either by the 
>> >person or organization it describes or the organization 
>> responsible for 
>> >the object it describes for devices and application entities. For 
>> >example, a typical name of a person in an English-speaking country 
>> >comprises a personal title (e.g., Mr., Ms., Rd, Professor, 
>> Sir, Lord), 
>> >a first name, middle name(s), last name, generation 
>> qualifier (if any, 
>> >e.g., Jr.) and decorations and awards (if any e.g., QC).
>> >
>> >Examples
>> >CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE"
>> >CN = "Divisional Coordination Committee"
>> >CN = "High Speed Modem".
>> >
>> >If there is a very strong desire to make use of an existing 
>> attribute 
>> >in the X.502 space, the SerialNumber attribute makes more sense. So 
>> >long as we are talking about long, term, stable MAC 
>> addresses assigned 
>> >to devices by manufacturers, this is consistent with the 
>> semantics of 
>> >that attribute.  Moreover, we have advised folks to use 
>> SerialNumber to 
>> >represent data such as employee/student IDs in the past, so 
>> one might 
>> >expect to see support for this attribute in many CAs and clients.
>> >
>> >Steve
>> 
>> _______________________________________________
>> secdir mailing list
>> [email-masked]
>> https://mailman.mit.edu/mailman/listinfo/secdir
>> 

Content-class: urn:content-classes:message
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Date: Mon, 7 Jan 2008 11:31:53 -0700
From: "Mani, Mahalingam (Mani)" <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>, "Scott G. Kelly" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Pat Calhoun (pacalhou)" <[email-masked]>, "Dorothy Stanley" <[email-masked]>
Sender: [email-masked]

If you look at the section (PSK usage) it becomes more evident that MAC
address is intended as a means of using a namespace for unique
identifier for WTP.

So - the extent to which the peer AC interprets is for that
identification of belonging to a database with a certain assurance of
uniqueness without having to create another device namespace. It was
perhaps partly motivated by other prior practices such as from cablelabs
& DOCSIS.

It is not intended as a runtime-verification at L2 (since WTPs and AC
deployment can span across routers).

So - does MAC address used thus qualify as acceptable identifier string
in your interpretation?

If so - does that still make this form of usage in CN acceptable?

My understanding is the LAN-side MAC address that is used (not the radio
addresses). I will let the CAPWAP authors clarify that.

-mani
-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Monday, January 07, 2008 9:32 AM
To: Scott G. Kelly; Stephen Kent; Sam Hartman
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [secdir] Please review
draft-ietf-capwap-protocol-specification's use of certificates

It seems that stating that the identifier used in a certificate MUST be
a MAC address may be overly restrictive.  It seems you would want to
allow for MAC address, but not require it.  Is there a reason why the
identifier needs to be a MAC address (if I understand correctly the AC
and WTP may not be directly L2 connected and may not have direct
knowledge of each others MAC address)?  
Why wouldn't another identifier string be acceptable?  
Is the MAC address interpreted by the peer or is it just an identifier
string?
If there are multiple MAC addresses which one is used?

Joe

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Scott G. Kelly
> Sent: Friday, December 21, 2007 1:55 PM
> To: Stephen Kent; Sam Hartman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [secdir] Please review 
> draft-ietf-capwap-protocol-specification's use of certificates
> 
> Hi Steve,
> 
> Thanks for taking a look at this. Regarding placement of the 
> MAC in the CN, I would offer two observations: 
> 
> 1) this is what is specified in the DOCSIS and PacketCable 
> cert profiles, and it was on this basis that device certs for 
> LWAPP were originally designed in this way. You can see the 
> DOCSIS profile at www.drizzle.com/~aboba/CPW/DOCSIS.ppt
> 
> 2) I don't see anything in the X.520 language that explicitly 
> precludes this usage, so assuming that the docsis/packetcable 
> designers reviewed that spec, I can see how they could 
> reasonably conclude that this is acceptable. Arguably, the 
> string representation of the MAC address is "a string chosen 
> [by the] organization responsible for the object it describes 
> for devices and application entities". 
> 
> Please don't misunderstand: I'm not trying to be difficult, 
> and I have a very healthy respect for the depth of your 
> knowledge in this area. However, there are a *lot* of devices 
> deployed that already use this convention. It might be more 
> pragmatic to interpret X.520 a little less restrictively.
> 
> Scott
> 
> -----Original Message-----
> >From: Stephen Kent <[email-masked]>
> >Sent: Dec 21, 2007 3:00 PM
> >To: Sam Hartman <[email-masked]>
> >Cc: [email-masked], [email-masked], [email-masked]
> >Subject: Re: [secdir] Please review 
> >draft-ietf-capwap-protocol-specification's use of certificates
> >
> >At 9:23 PM -0500 12/20/07, Sam Hartman wrote:
> >>Hi, folks.  The capwap working group is preparing to last 
> call their 
> >>protocol specification draft.
> >>
> >>I'd appreciate review from the pkix community of section 2.4.4.3 and
> >>12.6 of this draft.  These sections specify certificate 
> validation and 
> >>certificate usage for the protocol.  Scott Kelly and Charles Clancy 
> >>are security advisors for the working group and have been heavily 
> >>involved.
> >>
> >>The capwap certificate profile assumes that the CN in the 
> certificate 
> >>has structure and contains an ethernet MAC address.  The capwap 
> >>certificate profile also assumes that parts of the subject 
> name such 
> >>as the organization and organizational unit will be important to 
> >>certificate matching.
> >>
> >>I'd appreciate review and comments.
> >>
> >>--Sam
> >
> >It would be preferable to get an allocated name space for MAC 
> >addresses, under the OtherName or, better yet, under registeredID.
> >
> >I'd argue that it is inappropriate to put a MAC address into a CN. 
> >The text from X.520 makes this clear:
> >
> >The Common Name attribute type specifies an identifier of an object. 
> >A Common Name is not a directory name; it is a (possibly ambiguous) 
> >name by which the object is commonly known in some limited 
> scope (such 
> >as an organization) and conforms to the naming conventions of the 
> >country or culture with which it is associated.
> >
> >An attribute value for common name is a string chosen either by the 
> >person or organization it describes or the organization 
> responsible for 
> >the object it describes for devices and application entities. For 
> >example, a typical name of a person in an English-speaking country 
> >comprises a personal title (e.g., Mr., Ms., Rd, Professor, 
> Sir, Lord), 
> >a first name, middle name(s), last name, generation 
> qualifier (if any, 
> >e.g., Jr.) and decorations and awards (if any e.g., QC).
> >
> >Examples
> >CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE"
> >CN = "Divisional Coordination Committee"
> >CN = "High Speed Modem".
> >
> >If there is a very strong desire to make use of an existing 
> attribute 
> >in the X.502 space, the SerialNumber attribute makes more sense. So 
> >long as we are talking about long, term, stable MAC 
> addresses assigned 
> >to devices by manufacturers, this is consistent with the 
> semantics of 
> >that attribute.  Moreover, we have advised folks to use 
> SerialNumber to 
> >represent data such as employee/student IDs in the past, so 
> one might 
> >expect to see support for this attribute in many CAs and clients.
> >
> >Steve
> 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://mailman.mit.edu/mailman/listinfo/secdir
> 

Content-class: urn:content-classes:message
Subject: TAMP reference implementation
Date: Mon, 7 Jan 2008 18:21:42 -0000
From: "Williams, Gareth \(FN\) @ TRL" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8515A.342AEBD6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am interested in TAMP. Can anyone tell me if there is a reference or
draft implementation of the protocol (as defined in
draft-housley-tamp-00) ?

=20

Thanks,

=20

Gareth Williams

------_=_NextPart_001_01C8515A.342AEBD6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I am interested in TAMP. Can anyone tell me if there =
is a
reference or draft implementation of the protocol (as defined in =
draft-housley-tamp-00)
?<o:p></o:p></span></font></p>

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

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

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

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

</div>

</body>

</html>

------_=_NextPart_001_01C8515A.342AEBD6--

Date: Mon, 7 Jan 2008 09:37:23 -0800
To: "Erik Andersen" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 11:38 AM +0100 1/7/08, Erik Andersen wrote:
>I do not believe this is a question about a global directory or not.

The part of the design of X.509 that affects this question is 
definitely about a global directory.

>I have the feeling that the term "X.500 theologists" is meant as a
>disparaging term.

Correct. But...

>What about changing the terminology and replace the terms "X.500
>theologists" and "pragmatists" with those wanting a clean design and those
>that do not care.

I have the feeling that the term "those that do not care" is meant as 
a disparaging term when compared to "those wanting a clean design". I 
believe that I want a clean design, and 15 years of IETF experience 
with X.509 certificates has shown that it is silly to try to limit 
the contents or use of the naming fields in those certificates. 
Everyone, often including standards bodies, stretch the naming until 
it becomes meaningless. A clean and honest view is to say 
"constraints on what kinds of names can go where have not worked".

>During a long life working with IBM customers, I have too often seen hopeful
>youngsters developing so-called pragmatic solutions that resulted in bad and
>non-extensible designs. The result has been that more and more ice pilled up
>in front of the project until it came to a grinding stop. So, I get a bad
>feeling in my stomach whenever the word pragmatic is mentioned.

Maybe the same is true for "clean design".

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Date: Mon, 7 Jan 2008 09:32:19 -0800
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Scott G. Kelly" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

It seems that stating that the identifier used in a certificate MUST be
a MAC address may be overly restrictive.  It seems you would want to
allow for MAC address, but not require it.  Is there a reason why the
identifier needs to be a MAC address (if I understand correctly the AC
and WTP may not be directly L2 connected and may not have direct
knowledge of each others MAC address)?  
Why wouldn't another identifier string be acceptable?  
Is the MAC address interpreted by the peer or is it just an identifier
string?
If there are multiple MAC addresses which one is used?

Joe

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Scott G. Kelly
> Sent: Friday, December 21, 2007 1:55 PM
> To: Stephen Kent; Sam Hartman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [secdir] Please review 
> draft-ietf-capwap-protocol-specification's use of certificates
> 
> Hi Steve,
> 
> Thanks for taking a look at this. Regarding placement of the 
> MAC in the CN, I would offer two observations: 
> 
> 1) this is what is specified in the DOCSIS and PacketCable 
> cert profiles, and it was on this basis that device certs for 
> LWAPP were originally designed in this way. You can see the 
> DOCSIS profile at www.drizzle.com/~aboba/CPW/DOCSIS.ppt
> 
> 2) I don't see anything in the X.520 language that explicitly 
> precludes this usage, so assuming that the docsis/packetcable 
> designers reviewed that spec, I can see how they could 
> reasonably conclude that this is acceptable. Arguably, the 
> string representation of the MAC address is "a string chosen 
> [by the] organization responsible for the object it describes 
> for devices and application entities". 
> 
> Please don't misunderstand: I'm not trying to be difficult, 
> and I have a very healthy respect for the depth of your 
> knowledge in this area. However, there are a *lot* of devices 
> deployed that already use this convention. It might be more 
> pragmatic to interpret X.520 a little less restrictively.
> 
> Scott
> 
> -----Original Message-----
> >From: Stephen Kent <[email-masked]>
> >Sent: Dec 21, 2007 3:00 PM
> >To: Sam Hartman <[email-masked]>
> >Cc: [email-masked], [email-masked], [email-masked]
> >Subject: Re: [secdir] Please review 
> >draft-ietf-capwap-protocol-specification's use of certificates
> >
> >At 9:23 PM -0500 12/20/07, Sam Hartman wrote:
> >>Hi, folks.  The capwap working group is preparing to last 
> call their 
> >>protocol specification draft.
> >>
> >>I'd appreciate review from the pkix community of section 2.4.4.3 and
> >>12.6 of this draft.  These sections specify certificate 
> validation and 
> >>certificate usage for the protocol.  Scott Kelly and Charles Clancy 
> >>are security advisors for the working group and have been heavily 
> >>involved.
> >>
> >>The capwap certificate profile assumes that the CN in the 
> certificate 
> >>has structure and contains an ethernet MAC address.  The capwap 
> >>certificate profile also assumes that parts of the subject 
> name such 
> >>as the organization and organizational unit will be important to 
> >>certificate matching.
> >>
> >>I'd appreciate review and comments.
> >>
> >>--Sam
> >
> >It would be preferable to get an allocated name space for MAC 
> >addresses, under the OtherName or, better yet, under registeredID.
> >
> >I'd argue that it is inappropriate to put a MAC address into a CN. 
> >The text from X.520 makes this clear:
> >
> >The Common Name attribute type specifies an identifier of an object. 
> >A Common Name is not a directory name; it is a (possibly ambiguous) 
> >name by which the object is commonly known in some limited 
> scope (such 
> >as an organization) and conforms to the naming conventions of the 
> >country or culture with which it is associated.
> >
> >An attribute value for common name is a string chosen either by the 
> >person or organization it describes or the organization 
> responsible for 
> >the object it describes for devices and application entities. For 
> >example, a typical name of a person in an English-speaking country 
> >comprises a personal title (e.g., Mr., Ms., Rd, Professor, 
> Sir, Lord), 
> >a first name, middle name(s), last name, generation 
> qualifier (if any, 
> >e.g., Jr.) and decorations and awards (if any e.g., QC).
> >
> >Examples
> >CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE"
> >CN = "Divisional Coordination Committee"
> >CN = "High Speed Modem".
> >
> >If there is a very strong desire to make use of an existing 
> attribute 
> >in the X.502 space, the SerialNumber attribute makes more sense. So 
> >long as we are talking about long, term, stable MAC 
> addresses assigned 
> >to devices by manufacturers, this is consistent with the 
> semantics of 
> >that attribute.  Moreover, we have advised folks to use 
> SerialNumber to 
> >represent data such as employee/student IDs in the past, so 
> one might 
> >expect to see support for this attribute in many CAs and clients.
> >
> >Steve
> 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://mailman.mit.edu/mailman/listinfo/secdir
> 

Date: Mon, 07 Jan 2008 17:12:43 +0000
From: Stephen Farrell <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: New other certs extension I-D
Sender: [email-masked]

Hiya,

Stephen Kent wrote:
> Here I think the danger is greater, because we're including pointers to
> cert but not being explicit about what we expect RPs to do with them. 
> It's not enough to say that the certs have to pass the validation
> policy. If an app believes that the a cert pointed to by this extension
> is intended to replace one it already associates with a given entity,
> then this might create problems at the not-well-defined interface
> between the PKI modules and applications. 

That's possibly true, but also possibly not. Given that we
don't specify those APIs here we can't really tell, and since
this would be a non-critical extension, only applications that
go looking (and hence understand what they want to do) would
find out about its existence.

>> Can you give an example? (I've thought about it a little bit, but
>> haven't come up with a good example of a problem that wouldn't just
>> be an implementation bug in an RP.)
> 
> As noted above, we don't prescribe the interface between PKI processing
> and app use of data that comes from that processing. 

Right.

> If this extension
> is intended to solve a specific problem in this realm, then we need to
> be precise in describing what the problem is, and how this extension
> solves it. 

I would claim that (modulo -00 type text), there is the core of
such a problem and solution description in the draft. Totally
agree that it needs work though.

> I am not comfortable defining an extension for which we do
> not do this.

But I don't see how to tell the application exactly what to do
(since that's application specific) while at the same time
specifying a generic extension. (I think this is the nub of
what we're discussing.)

If there is a way, then I'm all for adding such text. I do agree
that there needs to be some text saying that if you do make use of
the linkage, then you need to be aware of various security
considerations (e.g. if an old private key were liable to be
leaked) and possible application gotchas (e.g. name changes).

If there isn't then we either kill the idea, or else have to
go with an application-specific extension, which is much less
interesting (I reckon), since I'd argue that the same problem
will arise in many applications. Basically, anyone who wants
to change things at cert renewal time but where there's
existing application state tied to the old cert.

I also reckon that this extension could be useful in load
balancing situations, though I guess one could well argue
that that's sufficiently different and can be handled via
wildcards (or handled well enough).

>> As to a CA not knowing the utility, I disagree. Were this extension
>> to see real life use, then CAs would surely only include it when
>> they do understand the effects. (I can even imagine them charging
>> a premium;-)
> 
> Then let's have CAs contribute to the discussion and say what they would
> do with the extension, and how they want RPs to process it.

Yes, I think this is only interesting if there's a real chance that
it'll be used. Otherwise, we can just let it wither away... (I've
had a couple of "hmm, interesting..." type mails off-list, but no
more than that.)

Maybe the thing to do is to put this on the agenda next time to
see if it gets more than a few scattered yawns? If so, I guess
I can try do up a -01 before then reflecting this thread.

Cheers,
S.

Date: Mon, 7 Jan 2008 10:59:33 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 10:05 PM +1300 1/5/08, Peter Gutmann wrote:
>Stephen Kent <[email-masked]> writes:
>
>>If the DOCSIS and PacketCable specs preceded the X.520 publication, this
>>would have been a good argument. But these specs came along much later. The
>>folks at Cable Labs who decided to put the MAC address in the CN  made a poor
>>choice.
>
>Only in the eyes of X.500 theologists.  As a pragmatic decision it's perfectly
>appropriate.  If you're identifying a CC holder, the CN is your credit card
>number.  If you're identifying a taxpayer, the CN is the taxpayer ID.  If
>you're identifying a web server, the CN is the server's URL/FQDN.  If you're
>identifying a piece of hardware addressed by MAC address, the CN is the MAC
>address.

Pragmatism is all too often cited as a justification for ill-advised 
behavior. All of your examples of what cab be stuffed into the CN 
attribute are good examples of what NOT to put there. The penultimate 
example specifically is disparaged by PKIX standards.

In the early days of TCP/IP, the folks responsible for the BSD 
implementation decided to NOT calculate the TCP checksum for each 
packet.  Pragmatically, they found the Ethernet MAC layer CRC to 
suffice and having to calculate the TCP checksum slowed down their 
implementation. The fact that a standard defined what to put in the 
the TCP checksum field was irrelevant to them, based on a purely 
local, pragmatic view of the situation.

I see echos of that mentality here.

Steve

Date: Mon, 7 Jan 2008 11:14:41 -0500
To: Stephen Farrell <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: New other certs extension I-D
Cc: [email-masked]
Sender: [email-masked]

--============_-1012399134==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 12:13 PM +0000 1/7/08, Stephen Farrell wrote:
>Hi Steve,
>
>Stephen Kent wrote:
>
>>  Maybe my comments were not precise enough.
>>
>>  My concern is that there is not sufficient description of what an RP
>>  MUST/SHOULD do with the info provided via this proposed extension.
>
>I'm still not getting the concern. Since this extension is not part of
>path validation, the RP actions are essentially application specific, so
>there're no MUSTs or SHOULDs required for the RP here, other than to
>re-iterate that an RP MUST only use certs that passed 3280(bis)
>validation, which I took as implicit but might be worth calling out.
>
>That's more or less what we do with e.g. SubjectDirectoryAttributes
>[1] which is also not an input to path validation.

Yes, but SDA is marginal and we used to disparage its use :-). (In 
RFC 2459 we said "The subject directory attributes extension is not 
recommended as an essential part of this profile, but it may be used 
in local  environments." and I'm sorry we deleted that warning in 
3280.)

Here I think the danger is greater, because we're including pointers 
to cert but not being explicit about what we expect RPs to do with 
them.  It's not enough to say that the certs have to pass the 
validation policy. If an app believes that the a cert pointed to by 
this extension is intended to replace one it already associates with 
a given entity, then this might create problems at the 
not-well-defined interface between the PKI modules and applications. 

>However, if there're any security concerns then there could be some
>MUST NOTs, for example, it might make sense to say that an RP MUST
>NOT assume that the other certs all have the same key usage etc.,
>but that's sort-of motherhood and apple pie stuff, and I guess
>isn't what you meant.

no, it's not.

>  > Giving example of what an RP MIGHT do is not enough. We need to be
>>  precise. In so doing, we should be able to figure out what constraints
>>  are imposed on CAs who make use of the extension, and what security
>>  implications arise.
>
>>  If we just create syntax for transporting these pointers, and some
>>  suggestions about what an RP might do with the info, we create a
>>  situation where a CA doesn't know what utility they provide (because it
>>  cannot count on how an RP will use the info) and users cannot know what
>>  their local PKI engines are doing with the info, which may undermine
>>  local PKI management efforts.
>
>Can you give an example? (I've thought about it a little bit, but
>haven't come up with a good example of a problem that wouldn't just
>be an implementation bug in an RP.)

As noted above, we don't prescribe the interface between PKI 
processing and app use of data that comes from that processing. If 
this extension is intended to solve a specific problem in this realm, 
then we need to be precise in describing what the problem is, and how 
this extension solves it. I am not comfortable defining an extension 
for which we do not do this.

>As to a CA not knowing the utility, I disagree. Were this extension
>to see real life use, then CAs would surely only include it when
>they do understand the effects. (I can even imagine them charging
>a premium;-)

Then let's have CAs contribute to the discussion and say what they 
would do with the extension, and how they want RPs to process it.

Steve
--============_-1012399134==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: New other certs extension
I-D</title></head><body>
<div>At 12:13 PM +0000 1/7/08, Stephen Farrell wrote:</div>
<blockquote type="cite" cite>Hi Steve,<br>
<br>
Stephen Kent wrote:<br>
<br>
&gt; Maybe my comments were not precise enough.<br>
&gt;<br>
&gt; My concern is that there is not sufficient description of what an
RP<br>
&gt; MUST/SHOULD do with the info provided via this proposed
extension.<br>
<br>
I'm still not getting the concern. Since this extension is not part
of<br>
path validation, the RP actions are essentially application specific,
so<br>
there're no MUSTs or SHOULDs required for the RP here, other than
to<br>
re-iterate that an RP MUST only use certs that passed 3280(bis)<br>
validation, which I took as implicit but might be worth calling
out.<br>
<br>
That's more or less what we do with e.g.
SubjectDirectoryAttributes<br>
[1] which is also not an input to path validation.</blockquote>
<div><br></div>
<div>Yes, but SDA is marginal and we used to disparage its use :-).
(In RFC 2459 we said &quot;<font color="#000000">The subject directory
attributes extension is not recommended as an essential part of this
profile, but it may be used in local&nbsp; environments.&quot; and I'm
sorry we deleted that warning in 3280.)</font></div>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">Here I think the danger is greater, because
we're including pointers to cert but not being explicit about what we
expect RPs to do with them.&nbsp; It's not enough to say that the
certs have to pass the validation policy. If an app believes that the
a cert pointed to by this extension is intended to replace one it
already associates with a given entity, then this might create
problems at the not-well-defined interface between the PKI modules and
applications.<font face="Times New Roman"
size="+2">&nbsp;</font></font></div>
<div><br></div>
<blockquote type="cite" cite>However, if there're any security
concerns then there could be some<br>
MUST NOTs, for example, it might make sense to say that an RP MUST<br>
NOT assume that the other certs all have the same key usage etc.,<br>
but that's sort-of motherhood and apple pie stuff, and I guess<br>
isn't what you meant.</blockquote>
<div><br></div>
<div>no, it's not.<br>
</div>
<blockquote type="cite" cite>&gt; Giving example of what an RP MIGHT
do is not enough. We need to be<br>
&gt; precise. In so doing, we should be able to figure out what
constraints<br>
&gt; are imposed on CAs who make use of the extension, and what
security<br>
&gt; implications arise.<br>
<br>
&gt; If we just create syntax for transporting these pointers, and
some<br>
&gt; suggestions about what an RP might do with the info, we create
a<br>
&gt; situation where a CA doesn't know what utility they provide
(because it<br>
&gt; cannot count on how an RP will use the info) and users cannot
know what<br>
&gt; their local PKI engines are doing with the info, which may
undermine<br>
&gt; local PKI management efforts.<br>
<br>
Can you give an example? (I've thought about it a little bit, but<br>
haven't come up with a good example of a problem that wouldn't
just<br>
be an implementation bug in an RP.)</blockquote>
<div><br></div>
<div>As noted above, we don't prescribe the interface between PKI
processing and app use of data that comes from that processing. If
this extension is intended to solve a specific problem in this realm,
then we need to be precise in describing what the problem is, and how
this extension solves it. I am not comfortable defining an extension
for which we do not do this.</div>
<div><br></div>
<blockquote type="cite" cite>As to a CA not knowing the utility, I
disagree. Were this extension<br>
to see real life use, then CAs would surely only include it when<br>
they do understand the effects. (I can even imagine them
charging</blockquote>
<blockquote type="cite" cite>a premium;-)</blockquote>
<div><br></div>
<div>Then let's have CAs contribute to the discussion and say what
they would do with the extension, and how they want RPs to process
it.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1012399134==_ma============--

Content-class: urn:content-classes:message
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Date: Mon, 7 Jan 2008 11:09:07 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

You believe Google employees do a Google search when they want to find
the telephone number or organizational designator of another employee,
or find the employees of a particular organization?

I may or may not be representative of Joe Sixpack, but I use a directory
when I want to look up structured data and a full text search when I
want to find content on a topic.  And to answer the question, I used my
employer's directory more recently than I used our internal Google
service.
Semantic consistency makes structured data work better.

How about if the pragmatists refrain from objecting to standards for
tagged data field semantics, and instead just silently ignore the
standards that they find too restrictive.  Feel free to ignore Dublin
Core too, and go ahead and put Identifier information into the
Description element.

And stop chanting "global directory" - directories can federate based on
X.500 standards without needing a Borg to be assimilated into.

Bob Juenemann's jpeg-of-a-cat example is a perfectly pragmatic use for
the Common Name field.  Base-64 will make it fit Printable String, and
pragmatic applications could parse it and treat it like favicon.ico.  If
anything goes, then why not?

Dave

-----Original Message-----
From: Peter Gutmann

Steven Legg <[email-masked]> writes:
>One of the modes for accessing a directory is browsing up and down the
>directory tree.

And when do people ever do this?  Google, one of the worlds biggest IT
companies (?), made most of its fortune from the very fact that people
don't
do this.  When did Joe Sixpack last use an Internet directory, and when
did
they last use a non-directory Internet search engine?

(I'm guessing the answer is pretty close to "never" for the former, and
"the
last time they went online" for the latter).

[...]

How about the following compromise between X.500 theologists and
pragmatists:
The pragmatists agree to make all their DNs fully X.500 (well, X.520)
compliant the moment the global X.500 directory emerges, and in exchange
the
X.500 theologists agree not to bother the pragmatists any more until the
global X.500 directory emerges.

Peter.

Date: Mon, 07 Jan 2008 12:13:17 +0000
From: Stephen Farrell <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: New other certs extension I-D
Sender: [email-masked]

Hi Steve,

Stephen Kent wrote:

> Maybe my comments were not precise enough.
> 
> My concern is that there is not sufficient description of what an RP
> MUST/SHOULD do with the info provided via this proposed extension.

I'm still not getting the concern. Since this extension is not part of
path validation, the RP actions are essentially application specific, so
there're no MUSTs or SHOULDs required for the RP here, other than to
re-iterate that an RP MUST only use certs that passed 3280(bis)
validation, which I took as implicit but might be worth calling out.

That's more or less what we do with e.g. SubjectDirectoryAttributes
[1] which is also not an input to path validation.

However, if there're any security concerns then there could be some
MUST NOTs, for example, it might make sense to say that an RP MUST
NOT assume that the other certs all have the same key usage etc.,
but that's sort-of motherhood and apple pie stuff, and I guess
isn't what you meant.

> Giving example of what an RP MIGHT do is not enough. We need to be
> precise. In so doing, we should be able to figure out what constraints
> are imposed on CAs who make use of the extension, and what security
> implications arise.

> If we just create syntax for transporting these pointers, and some
> suggestions about what an RP might do with the info, we create a
> situation where a CA doesn't know what utility they provide (because it
> cannot count on how an RP will use the info) and users cannot know what
> their local PKI engines are doing with the info, which may undermine
> local PKI management efforts.

Can you give an example? (I've thought about it a little bit, but
haven't come up with a good example of a problem that wouldn't just
be an implementation bug in an RP.)

As to a CA not knowing the utility, I disagree. Were this extension
to see real life use, then CAs would surely only include it when
they do understand the effects. (I can even imagine them charging
a premium;-)

Stephen.

[1] http://tools.ietf.org/html/draft-ietf-pkix-rfc3280bis-10#page-38

From: "Erik Andersen" <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Date: Mon, 7 Jan 2008 11:38:24 +0100
Importance: Normal
Sender: [email-masked]

Hi,

I do not believe this is a question about a global directory or not.

I have the feeling that the term "X.500 theologists" is meant as a
disparaging term.

What about changing the terminology and replace the terms "X.500
theologists" and "pragmatists" with those wanting a clean design and those
that do not care.

During a long life working with IBM customers, I have too often seen hopeful
youngsters developing so-called pragmatic solutions that resulted in bad and
non-extensible designs. The result has been that more and more ice pilled up
in front of the project until it came to a grinding stop. So, I get a bad
feeling in my stomach whenever the word pragmatic is mentioned.

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Peter Gutmann
> Sent: 7. januar 2008 06:56
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; ietf-
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [secdir] Please review draft-ietf-capwap-protocol-
> specification's use of certificates
> 
> 
> Steven Legg <[email-masked]> writes:
> 
> >One of the modes for accessing a directory is browsing up and down the
> >directory tree.
> 
> And when do people ever do this?  Google, one of the worlds biggest IT
> companies (?), made most of its fortune from the very fact that people
> don't
> do this.  When did Joe Sixpack last use an Internet directory, and when
> did
> they last use a non-directory Internet search engine?
> 
> (I'm guessing the answer is pretty close to "never" for the former, and
> "the
> last time they went online" for the latter).
> 
> >A common name like "Peter Gutmann's Visa Card" is much more informative
> than
> >the common name "1234 5678 9012 3456".
> 
> To whom is it informative?  In what possible context does anyone
> processing a
> credit card payment care in the remotest manner whether card "1234 5678
> 9012
> 3456" belongs to "Peter Gutmann" or "The Jolly Green Giant"?  All they
> care
> about is the card number and "authorised/declined".
> 
> (The very existence of anonymous prepaid credit cards prove that card
> processors don't care in the slightest about "Peter Gutmann's Visa Card":
> there's no name associated with the card at all since it has zero value to
> them).
> 
> How about the following compromise between X.500 theologists and
> pragmatists:
> The pragmatists agree to make all their DNs fully X.500 (well, X.520)
> compliant the moment the global X.500 directory emerges, and in exchange
> the
> X.500 theologists agree not to bother the pragmatists any more until the
> global X.500 directory emerges.
> 
> Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 07 Jan 2008 18:56:19 +1300
Sender: [email-masked]

Steven Legg <[email-masked]> writes:

>One of the modes for accessing a directory is browsing up and down the
>directory tree.

And when do people ever do this?  Google, one of the worlds biggest IT
companies (?), made most of its fortune from the very fact that people don't
do this.  When did Joe Sixpack last use an Internet directory, and when did
they last use a non-directory Internet search engine?

(I'm guessing the answer is pretty close to "never" for the former, and "the
last time they went online" for the latter).

>A common name like "Peter Gutmann's Visa Card" is much more informative than
>the common name "1234 5678 9012 3456".

To whom is it informative?  In what possible context does anyone processing a
credit card payment care in the remotest manner whether card "1234 5678 9012
3456" belongs to "Peter Gutmann" or "The Jolly Green Giant"?  All they care
about is the card number and "authorised/declined".

(The very existence of anonymous prepaid credit cards prove that card
processors don't care in the slightest about "Peter Gutmann's Visa Card":
there's no name associated with the card at all since it has zero value to
them).

How about the following compromise between X.500 theologists and pragmatists:
The pragmatists agree to make all their DNs fully X.500 (well, X.520)
compliant the moment the global X.500 directory emerges, and in exchange the
X.500 theologists agree not to bother the pragmatists any more until the
global X.500 directory emerges.

Peter.

Date: Mon, 07 Jan 2008 11:18:36 +1100
From: Steven Legg <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Sender: [email-masked]

Peter,

Peter Gutmann wrote:
> Stephen Kent <[email-masked]> writes:
> 
>> If the DOCSIS and PacketCable specs preceded the X.520 publication, this
>> would have been a good argument. But these specs came along much later. The
>> folks at Cable Labs who decided to put the MAC address in the CN  made a poor
>> choice.
> 
> Only in the eyes of X.500 theologists.  As a pragmatic decision it's perfectly
> appropriate.  If you're identifying a CC holder, the CN is your credit card
> number.

One of the modes for accessing a directory is browsing up and down the
directory tree. As a human user browsing the directory tree, seeing a
list of entries with common names that are just numbers isn't very
helpful to me. A common name like "Peter Gutmann's Visa Card" is much
more informative than the common name "1234 5678 9012 3456". If I'm
interested in the entry for a particular card number then I would
just search directly on the attribute holding the card number, rather
that browsing the tree. The same considerations apply to the other
examples you've given.

The commonName attribute is not a particularly appropriate choice for
searching and sorting purposes either because it uses caseIgnoreMatch
as the equality matching rule. The values "1234 5678 9012 3456" and
"1234567890123456" are different common name values, but would be
the same value for an attribute with the NumericString syntax and
numericStringMatch equality matching rule. Unfortunately, LDAP and
X.500 don't define a general-purpose number attribute with this syntax
(serialNumber uses PrintableString and caseIgnoreMatch). Perhaps they
(or PKIX) should, to avoid further abuses of the commonName attribute ?

 > If you're identifying a taxpayer, the CN is the taxpayer ID.  If
> you're identifying a web server, the CN is the server's URL/FQDN.  If you're
> identifying a piece of hardware addressed by MAC address, the CN is the MAC
> address.
> 
>> If one looks at ALL of the text associated with the definition of CN, it is
>> clear what sorts of names are envisioned
> 
> Yup, something that works with the global X.500 directory.  Just as soon as
> that appears we can start requiring people to choose names compliant with it.

The presence or absence of a global X.500 directory is not relevant.
Good naming practice applies just as much to stand-alone enterprise
directory deployments.

Regards,
Steven

> Peter.

Date: Sun, 6 Jan 2008 19:56:15 +0900
To: [email-masked]
From: "Char Nyakacska" <[email-masked]>
Subject: alltag

Have a large , thick penis and gain inches in just weeks! http://Censorstenver.com/

From: "Erik Andersen" <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Date: Sat, 5 Jan 2008 13:19:31 +0100
Importance: Normal
Sender: [email-masked]

Hi Folks,

I do not want to be directly involved in this discussion.

As the project editor of X.500, including X.520, I may probably be titled as
an X.500 theologist, although I am not very religious.

I always get a little scare when people talks about pragmatic solutions, and
I normally translate that into "cutting corners" or "quick and dirty
solutions". Sticking to standards is not just a theological question, but a
very practical to allow systems from different vendors developed at
different times to interwork.

As to the matter at hand. It is not just theology to stick to the defined
semantics of different attribute types. It has a practical aspect as I have
been taught by implementers (never, never change the semantic). If there are
different semantics attached to the same attribute type, in adversely
affects (or confuses) client software.

This probably doesn't help.

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Peter Gutmann
> Sent: 5. januar 2008 10:06
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; ietf-
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-
> specification's use of certificates
> 
> 
> Stephen Kent <[email-masked]> writes:
> 
> >If the DOCSIS and PacketCable specs preceded the X.520 publication, this
> >would have been a good argument. But these specs came along much later.
> The
> >folks at Cable Labs who decided to put the MAC address in the CN  made a
> poor
> >choice.
> 
> Only in the eyes of X.500 theologists.  As a pragmatic decision it's
> perfectly
> appropriate.  If you're identifying a CC holder, the CN is your credit
> card
> number.  If you're identifying a taxpayer, the CN is the taxpayer ID.  If
> you're identifying a web server, the CN is the server's URL/FQDN.  If
> you're
> identifying a piece of hardware addressed by MAC address, the CN is the
> MAC
> address.
> 
> >If one looks at ALL of the text associated with the definition of CN, it
> is
> >clear what sorts of names are envisioned
> 
> Yup, something that works with the global X.500 directory.  Just as soon
> as
> that appears we can start requiring people to choose names compliant with
> it.
> 
> Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sat, 05 Jan 2008 22:05:43 +1300
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:

>If the DOCSIS and PacketCable specs preceded the X.520 publication, this
>would have been a good argument. But these specs came along much later. The
>folks at Cable Labs who decided to put the MAC address in the CN  made a poor
>choice.

Only in the eyes of X.500 theologists.  As a pragmatic decision it's perfectly
appropriate.  If you're identifying a CC holder, the CN is your credit card
number.  If you're identifying a taxpayer, the CN is the taxpayer ID.  If
you're identifying a web server, the CN is the server's URL/FQDN.  If you're
identifying a piece of hardware addressed by MAC address, the CN is the MAC
address.

>If one looks at ALL of the text associated with the definition of CN, it is
>clear what sorts of names are envisioned

Yup, something that works with the global X.500 directory.  Just as soon as
that appears we can start requiring people to choose names compliant with it.

Peter.

Date: Fri, 4 Jan 2008 11:23:52 +0900
To: [email-masked]
From: "asdfqer Poppelier" <[email-masked]>
Subject: hysop

3 months of VPXL, and most men gain an average of 1-2 inches! http://www.Istatablew.com/

Date: Thu, 3 Jan 2008 09:22:32 +0300
From: "Raquel Neuhart" <[email-masked]>
To: [email-masked]
Subject: sretsneo

Finally, a product that is TOO GOOD TO BE TRUE - the only proven penis enlargement pill! http://www.Freisgans.com/

Content-class: urn:content-classes:message
Subject: RE: [secdir] Please review  draft-ietf-capwap-protocol-specification's use of certificates
Date: Wed, 2 Jan 2008 13:32:36 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: "Scott G. Kelly" <[email-masked]>, "Sam Hartman" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

You write the spec, you hope that people will take notice.
=20
If people do not take notice that is at least in part the fault of the =
spec writer for failing to make their intentions more clearly =
understood.
=20
=20
What the CableLabs sec should have said seems like a pointless argument =
to me at this point but for the record we have a professional =
disagreement as to the most reasonable interpretation of this passage. =
EUI-48 identifiers do not exactly map onto any meaningful concept within =
X.520 space, this is due to the same lack of imagination on its =
designers part that makes X.500 the real world success it is today. The =
choice is between using the CN field and creating a new one. The CN =
field approach meets the expectations of existing applications much =
better than a new creation would.
=20
=20
=20
________________________________

From: [email-masked] on behalf of Stephen Kent
Sent: Wed 02/01/2008 1:32 PM
To: Hallam-Baker, Phillip
Cc: Scott G. Kelly; Sam Hartman; [email-masked]; =
[email-masked]; [email-masked]
Subject: RE: [secdir] Please review =
draft-ietf-capwap-protocol-specification's use of certificates

At 9:53 AM -0800 1/2/08, Hallam-Baker, Phillip wrote:

	>One ought not expect the writers of X.520 to anticipate every
	>questionable use of an attribute and say "no, don't do this" so I
	>don't think your observation above is a valid argument in favor of
	>using CN here. Also, the text for common name starts by saying "A
	>Common Name is not a directory name; it is a (possibly ambiguous)
	>name by which the object is commonly known in some limited scope
	>(such as an organization) and conforms to the naming conventions of
	>the country or culture with which it is associated." This text, which
	>precedes the text you cite, makes it clear that a MAC address should
	>not be represented as a common name. A vendor assigning a MAC
	>generally does so in a globally unique fashion, which contradicts the
	>"limited scope" concept cited in the standard. A MAC address is not
	>at all congruent with the allusions to "naming conventions of the
	>country or culture with which it is associated" part of the
	>description of the common name attribute.
=09

	I would argue the reverse.

Why am I not surprised?

	 First it is far more important to be consistent with established =
practice than what the descriptive text in the X.520 spec might say. The =
Common Name is just a sequence of bits making up a tag-value pair. It is =
what it is, meaning is the result of usage.

If the DOCSIS and PacketCable specs preceded the X.520 publication, this =
would have been a good argument. But these specs came along much later. =
The folks at Cable Labs who decided to put the MAC address in the CN  =
made a poor choice.

If your comments apply to the capwap I-D, I have already stated that, =
given the need to be compatible with the extant, deployed base, there =
isn't much of a choice here. However, the capwap I-D needs to cite these =
specs as the justification for this odd decision, so that readers don't =
draw the wrong conclusion.=20

	 More importantly I would argue that the word 'limited' should be =
considered in the context 'in at least a limited context'. In general we =
like names to be as unique as is possible. Common names are not unique =
in general (although my common name is in fact unique at this point in =
time). We should not hold the fact that EUI-48 addresses do in general =
have this desirable property against them. The spec says POSSIBLY =
ambiguous. EUI-48 names appear to comply in my view.

If one looks at ALL of the text associated with the definition of CN, it =
is clear what sorts of names are envisioned, and a MAC address is not a =
reasonable candidate. One might work hard to try to find a way to =
justify the use, but hopefully a smart guy like you is doing so =
tongue-in-cheek.

Steve

------_=_NextPart_001_01C84D86.FDFD94F4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>RE: [secdir] Please review =
draft-ietf-capwap-protocol-spe</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<STYLE type=3Dtext/css><!--=0A=
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }=0A=
 --></STYLE>=0A=
=0A=
<META content=3D"MSHTML 6.00.6000.16587" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText80941 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>You write the =
spec, you hope that people will take notice.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>If people do not take notice =
that is at least in part the fault of the spec writer for failing to =
make their intentions more clearly understood.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>What the CableLabs sec should =
have said seems like a pointless argument to me at this point but for =
the record we have a professional disagreement as to the most =
reasonable&nbsp;interpretation of this passage. EUI-48 identifiers do =
not exactly map onto any meaningful concept within X.520 space, this is =
due to the same lack of imagination on its designers part that makes =
X.500 the real world success it is today. The choice is between using =
the CN field and creating a new one. The CN field approach meets the =
expectations of existing applications much better than a new creation =
would.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked] on behalf of Stephen Kent<BR><B>Sent:</B> =
Wed 02/01/2008 1:32 PM<BR><B>To:</B> Hallam-Baker, Phillip<BR><B>Cc:</B> =
Scott G. Kelly; Sam Hartman; [email-masked]; =
[email-masked]; [email-masked]<BR><B>Subject:</B> RE: [secdir] Please =
review draft-ietf-capwap-protocol-specification's use of =
certificates<BR></FONT><BR></DIV></DIV>=0A=
<DIV>=0A=
<DIV>At 9:53 AM -0800 1/2/08, Hallam-Baker, Phillip wrote:</DIV>=0A=
<BLOCKQUOTE type=3D"cite"><FONT face=3DArial size=3D-1>&gt;</FONT><FONT =
size=3D-1>One ought not expect the writers of X.520 to anticipate =
every<BR>&gt;questionable use of an attribute and say "no, don't do =
this" so I<BR>&gt;don't think your observation above is a valid argument =
in favor of<BR>&gt;using CN here. Also, the text for common name starts =
by saying "A<BR>&gt;Common Name is not a directory name; it is a =
(possibly ambiguous)<BR>&gt;name by which the object is commonly known =
in some limited scope<BR>&gt;(such as an organization) and conforms to =
the naming conventions of<BR>&gt;the country or culture with which it is =
associated." This text, which<BR>&gt;precedes the text you cite, makes =
it clear that a MAC address should<BR>&gt;not be represented as a common =
name. A vendor assigning a MAC<BR>&gt;generally does so in a globally =
unique fashion, which contradicts the<BR>&gt;"limited scope" concept =
cited in the standard. A MAC address is not<BR>&gt;at all congruent with =
the allusions to "naming conventions of the<BR>&gt;country or culture =
with which it is associated" part of the<BR>&gt;description of the =
common name attribute.</FONT><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><FONT size=3D-1>I would argue the =
reverse.</FONT></BLOCKQUOTE>=0A=
<DIV><BR></DIV>=0A=
<DIV>Why am I not surprised?</DIV>=0A=
<DIV><BR></DIV>=0A=
<BLOCKQUOTE type=3D"cite">&nbsp;<FONT size=3D-1>First it is far more =
important to be consistent with established practice than what the =
descriptive text in the X.520 spec might say. The Common Name is just a =
sequence of bits making up a tag-value pair. It is what it is, meaning =
is the result of usage.</FONT></BLOCKQUOTE>=0A=
<DIV><BR></DIV>=0A=
<DIV>If the DOCSIS and PacketCable specs preceded the X.520 publication, =
this would have been a good argument. But these specs came along much =
later. The folks at Cable Labs who decided to put the MAC address in the =
CN&nbsp; made a poor choice.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>If your comments apply to the capwap I-D, I have already stated =
that, given the need to be compatible with the extant, deployed base, =
there isn't much of a choice here. However, the capwap I-D needs to cite =
these specs as the justification for this odd decision, so that readers =
don't draw the wrong conclusion. </DIV>=0A=
<DIV><BR></DIV>=0A=
<BLOCKQUOTE type=3D"cite">&nbsp;<FONT size=3D-1>More importantly I would =
argue that the word 'limited' should be considered in the context 'in at =
least a limited context'. In general we like names to be as unique as is =
possible. Common names are not unique in general (although my common =
name is in fact unique at this point in time). We should not hold the =
fact that EUI-48 addresses do in general have this desirable property =
against them. The spec says POSSIBLY ambiguous. EUI-48 names appear to =
comply in my view.</FONT></BLOCKQUOTE>=0A=
<DIV><BR></DIV>=0A=
<DIV>If one looks at ALL of the text associated with the definition of =
CN, it is clear what sorts of names are envisioned, and a MAC address is =
not a reasonable candidate. One might work hard to try to find a way to =
justify the use, but hopefully a smart guy like you is doing so =
tongue-in-cheek.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>Steve</DIV></DIV></BODY></HTML>
------_=_NextPart_001_01C84D86.FDFD94F4--

Date: Wed, 2 Jan 2008 13:40:27 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: New other certs extension I-D
Cc: [email-masked]
Sender: [email-masked]

At 10:53 PM +0000 12/21/07, [email-masked] wrote:
>Hi Steve,
>
>>  I did a quick read of the I-D
>
>Thanks for taking the time to read this.
>
>>  I do have a concern.  The text says:
>>
>>  When this extension is present the CA is asserting that the same end
>>  entity is the subject of the relevant certificates. Mechanisms for
>>  how this assertion is validated by the CA or used by consumers of the
>>  certificate are out of scope of this memo.
>>
>>  I agree that the CA's actions re validation may be outside the scope
>>  of a document like this. However, we might say that CA is expected to
>>  have acted in accordance with any CP cited in the new cert, and
>>  performed whatever validation called for in the CPS for the CA.
>>
>>  I am less sanguine about being silent re what the client (RP) is
>>  expected to to do based on these links.  That creates a dangerous
>>  ambiguity. Since there were some examples provided to motivate this
>>  extension, I think you should use those as a starting point to
>>  describe what you think a client will do, based on this extension.
>
>Yes, as written there'd be nothing to stop a CA
>putting in references to web server certs and VPN g/w certs
>and code signing certs all in one place, which does
>seem odd but I didn't see a security problem arising.
>
>I did think of adding an OID in there, e.g. to say that
>all the linked certs are current or former web server
>certs issued to the same organisation/web site. However,
>I didn't see a concrete problem with leaving that out,
>so I did. Might be worth thinking again though.
>
>Or, I suppose one could simply make the extension specific
>to web server certs, but that feels a bit wrong, as I reckon
>there must be other uses for this extension.

Stephen,

Maybe my comments were not precise enough.

My concern is that there is not sufficient description of what an RP 
MUST/SHOULD do with the info provided via this proposed extension. 
Giving example of what an RP MIGHT do is not enough. We need to be 
precise. In so doing, we should be able to figure out what 
constraints are imposed on CAs who make use of the extension, and 
what security implications arise.

If we just create syntax for transporting these pointers, and some 
suggestions about what an RP might do with the info, we create a 
situation where a CA doesn't know what utility they provide (because 
it cannot count on how an RP will use the info) and users cannot know 
what their local PKI engines are doing with the info, which may 
undermine local PKI management efforts.

Steve

Date: Wed, 2 Jan 2008 13:32:27 -0500
To: "Hallam-Baker, Phillip" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: [secdir] Please review  draft-ietf-capwap-protocol-specification's use of certificates
Cc: "Scott G. Kelly" <[email-masked]>, "Sam Hartman" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

--============_-1012823560==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 9:53 AM -0800 1/2/08, Hallam-Baker, Phillip wrote:
>  >One ought not expect the writers of X.520 to anticipate every
>>questionable use of an attribute and say "no, don't do this" so I
>>don't think your observation above is a valid argument in favor of
>>using CN here. Also, the text for common name starts by saying "A
>>Common Name is not a directory name; it is a (possibly ambiguous)
>>name by which the object is commonly known in some limited scope
>>(such as an organization) and conforms to the naming conventions of
>>the country or culture with which it is associated." This text, which
>>precedes the text you cite, makes it clear that a MAC address should
>>not be represented as a common name. A vendor assigning a MAC
>>generally does so in a globally unique fashion, which contradicts the
>>"limited scope" concept cited in the standard. A MAC address is not
>>at all congruent with the allusions to "naming conventions of the
>>country or culture with which it is associated" part of the
>>description of the common name attribute.
>
>I would argue the reverse.

Why am I not surprised?

>  First it is far more important to be consistent with established 
>practice than what the descriptive text in the X.520 spec might say. 
>The Common Name is just a sequence of bits making up a tag-value 
>pair. It is what it is, meaning is the result of usage.

If the DOCSIS and PacketCable specs preceded the X.520 publication, 
this would have been a good argument. But these specs came along much 
later. The folks at Cable Labs who decided to put the MAC address in 
the CN  made a poor choice.

If your comments apply to the capwap I-D, I have already stated that, 
given the need to be compatible with the extant, deployed base, there 
isn't much of a choice here. However, the capwap I-D needs to cite 
these specs as the justification for this odd decision, so that 
readers don't draw the wrong conclusion.

>  More importantly I would argue that the word 'limited' should be 
>considered in the context 'in at least a limited context'. In 
>general we like names to be as unique as is possible. Common names 
>are not unique in general (although my common name is in fact unique 
>at this point in time). We should not hold the fact that EUI-48 
>addresses do in general have this desirable property against them. 
>The spec says POSSIBLY ambiguous. EUI-48 names appear to comply in 
>my view.

If one looks at ALL of the text associated with the definition of CN, 
it is clear what sorts of names are envisioned, and a MAC address is 
not a reasonable candidate. One might work hard to try to find a way 
to justify the use, but hopefully a smart guy like you is doing so 
tongue-in-cheek.

Steve
--============_-1012823560==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>RE: [secdir] Please review 
draft-ietf-capwap-protocol-spe</title></head><body>
<div>At 9:53 AM -0800 1/2/08, Hallam-Baker, Phillip wrote:</div>
<blockquote type="cite" cite><font face="Arial"
size="-1">&gt;</font><font size="-1">One ought not expect the writers
of X.520 to anticipate every<br>
&gt;questionable use of an attribute and say &quot;no, don't do this&quot;
so I<br>
&gt;don't think your observation above is a valid argument in favor
of<br>
&gt;using CN here. Also, the text for common name starts by saying
&quot;A<br>
&gt;Common Name is not a directory name; it is a (possibly
ambiguous)<br>
&gt;name by which the object is commonly known in some limited
scope<br>
&gt;(such as an organization) and conforms to the naming conventions
of<br>
&gt;the country or culture with which it is associated.&quot; This
text, which<br>
&gt;precedes the text you cite, makes it clear that a MAC address
should<br>
&gt;not be represented as a common name. A vendor assigning a MAC<br>
&gt;generally does so in a globally unique fashion, which contradicts
the<br>
&gt;&quot;limited scope&quot; concept cited in the standard. A MAC
address is not<br>
&gt;at all congruent with the allusions to &quot;naming conventions of
the<br>
&gt;country or culture with which it is associated&quot; part of
the<br>
&gt;description of the common name attribute.</font><br>
</blockquote>
<blockquote type="cite" cite><font size="-1">I would argue the
reverse.</font></blockquote>
<div><br></div>
<div>Why am I not surprised?</div>
<div><br></div>
<blockquote type="cite" cite>&nbsp;<font size="-1">First it is far
more important to be consistent with established practice than what
the descriptive text in the X.520 spec might say. The Common Name is
just a sequence of bits making up a tag-value pair. It is what it is,
meaning is the result of usage.</font></blockquote>
<div><br></div>
<div>If the DOCSIS and PacketCable specs preceded the X.520
publication, this would have been a good argument. But these specs
came along much later. The folks at Cable Labs who decided to put the
MAC address in the CN&nbsp; made a poor choice.</div>
<div><br></div>
<div>If your comments apply to the capwap I-D, I have already stated
that, given the need to be compatible with the extant, deployed base,
there isn't much of a choice here. However, the capwap I-D needs to
cite these specs as the justification for this odd decision, so that
readers don't draw the wrong conclusion. </div>
<div><br></div>
<blockquote type="cite" cite>&nbsp;<font size="-1">More importantly I
would argue that the word 'limited' should be considered in the
context 'in at least a limited context'. In general we like names to
be as unique as is possible. Common names are not unique in general
(although my common name is in fact unique at this point in time). We
should not hold the fact that EUI-48 addresses do in general have this
desirable property against them. The spec says POSSIBLY ambiguous.
EUI-48 names appear to comply in my view.</font></blockquote>
<div><br></div>
<div>If one looks at ALL of the text associated with the definition of
CN, it is clear what sorts of names are envisioned, and a MAC address
is not a reasonable candidate. One might work hard to try to find a
way to justify the use, but hopefully a smart guy like you is doing so
tongue-in-cheek.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1012823560==_ma============--

Content-class: urn:content-classes:message
Subject: RE: [secdir] Please review  draft-ietf-capwap-protocol-specification's use of certificates
Date: Wed, 2 Jan 2008 09:53:41 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Scott G. Kelly" <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C84D68.68FC0578
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>One ought not expect the writers of X.520 to anticipate every
>questionable use of an attribute and say "no, don't do this" so I
>don't think your observation above is a valid argument in favor of
>using CN here. Also, the text for common name starts by saying "A
>Common Name is not a directory name; it is a (possibly ambiguous)
>name by which the object is commonly known in some limited scope
>(such as an organization) and conforms to the naming conventions of
>the country or culture with which it is associated." This text, which
>precedes the text you cite, makes it clear that a MAC address should
>not be represented as a common name. A vendor assigning a MAC
>generally does so in a globally unique fashion, which contradicts the
>"limited scope" concept cited in the standard. A MAC address is not
>at all congruent with the allusions to "naming conventions of the
>country or culture with which it is associated" part of the
>description of the common name attribute.

I would argue the reverse.
=20
First it is far more important to be consistent with established =
practice than what the descriptive text in the X.520 spec might say. The =
Common Name is just a sequence of bits making up a tag-value pair. It is =
what it is, meaning is the result of usage.
=20
More importantly I would argue that the word 'limited' should be =
considered in the context 'in at least a limited context'. In general we =
like names to be as unique as is possible. Common names are not unique =
in general (although my common name is in fact unique at this point in =
time). We should not hold the fact that EUI-48 addresses do in general =
have this desirable property against them. The spec says POSSIBLY =
ambiguous. EUI-48 names appear to comply in my view.

------_=_NextPart_001_01C84D68.68FC0578
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>Re: [secdir] Please review =
draft-ietf-capwap-protocol-specification's use of certificates</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6000.16587" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText4302 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT size=3D2><FONT face=3DArial>&gt;</FONT>One ought =
not expect the writers of X.520 to anticipate every<BR>&gt;questionable =
use of an attribute and say "no, don't do this" so I<BR>&gt;don't think =
your observation above is a valid argument in favor of<BR>&gt;using CN =
here. Also, the text for common name starts by saying "A<BR>&gt;Common =
Name is not a directory name; it is a (possibly ambiguous)<BR>&gt;name =
by which the object is commonly known in some limited scope<BR>&gt;(such =
as an organization) and conforms to the naming conventions of<BR>&gt;the =
country or culture with which it is associated." This text, =
which<BR>&gt;precedes the text you cite, makes it clear that a MAC =
address should<BR>&gt;not be represented as a common name. A vendor =
assigning a MAC<BR>&gt;generally does so in a globally unique fashion, =
which contradicts the<BR>&gt;"limited scope" concept cited in the =
standard. A MAC address is not<BR>&gt;at all congruent with the =
allusions to "naming conventions of the<BR>&gt;country or culture with =
which it is associated" part of the<BR>&gt;description of the common =
name attribute.<BR></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>I would argue the reverse.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>First it is far more important to be =
consistent with established practice than what the descriptive text in =
the X.520 spec might say. The Common Name is just a sequence of bits =
making up a tag-value pair. It is what it is, meaning is the result of =
usage.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>More importantly I would argue that the =
word 'limited' should be considered in the context 'in at least a =
limited context'. In general we like names to be as unique as is =
possible. Common names are not unique in general (although my common =
name is in fact unique at this point in time). We should not hold the =
fact that EUI-48 addresses do in general have this desirable property =
against them. The spec says POSSIBLY ambiguous. EUI-48 names appear to =
comply in my view.</DIV></FONT></DIV></BODY></HTML>
------_=_NextPart_001_01C84D68.68FC0578--

Content-class: urn:content-classes:message
Subject: RE: [secdir] Please review  draft-ietf-capwap-protocol-specification's use of certificates
Date: Wed, 2 Jan 2008 09:46:09 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Joseph Salowey (jsalowey)" <[email-masked]>, "Bernard Aboba" <[email-masked]>, "Scott G. Kelly" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Sam Hartman" <[email-masked]>, "Max Pritikin (pritikin)" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C84D67.5BF21A60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This all fits into the category of 'it really does not matter how it is =
done provided that as many systems as possible do it in the same way'.
=20
At some point it would be really nice to be able to use these =
certificates in combination with 802.1x type authentication protocols. =
That is going to be easiest and cheapest for all concerned =
(manufacturers, administrators, tool builders) if there is as much =
consistency as possible.
=20
Since we are having a debate about how to do this, how about a short RFC =
that describes one way to do it? Preferably the way CableLabs or whoever =
has the most device certs out there today does it. That way the next =
committee that starts down this path can read up on how it is done in =
the field already and use the result to swat down whatever NIH proposal =
someone would otherwise put on the table.
=20
I would suggest that the spec would cover both the EUI-48 and EUI-64 =
address forms. Perhaps we could even persuade the IEEE to take a chunk =
of .arpa or other DNS space and hand out zone delegations along with OUI =
prefixes. That way manufacturers could if the choose use the DNS as a =
means of delivering indexes to device description information on demand =
as has utility in certain applications (but not necessarily all).
=20
I can spend time on this if there is interest.
=20
________________________________

From: [email-masked] on behalf of Russ Housley
Sent: Thu 27/12/2007 4:09 PM
To: Joseph Salowey (jsalowey); Bernard Aboba; Scott G. Kelly; Stephen =
Kent; Sam Hartman; Max Pritikin (pritikin)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [secdir] Please review =
draft-ietf-capwap-protocol-specification's use of certificates

CableLabs and WiMAX specifications include the MAC address in the CN.

Russ

At 06:19 PM 12/26/2007, Joseph Salowey (jsalowey) wrote:

>I don't believe that 802.1AR uses the MAC address in the CN field.  I
>believe it makes use of the SerialNumber field and does not mandate =
that
>the identity must be a MAC address (it doesn't prevent it either).  The
>current text from draft 1.2 on SubjectName is
>
>"The DevID subject field shall uniquely identify the particular DevID
>credential within the issuer's domain of significance. The formatting =
of
>this field shall contain a unique X.500 distinguished name (DN). This
>may include the manufacturer's serial number, manufacturer's factory
>programmed MAC address, issuer's or user's node name or any other
>suitable unique string that the issuer prefers.
>
>It is recommended that the subject field's DN encoding include the
>'serialNumber' attribute with the device's unique serial number. "
>
>The current editor of the document, Max Pritikin, is copied on this
>message.
>
>Joe
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > On Behalf Of Bernard Aboba
> > Sent: Friday, December 21, 2007 8:00 PM
> > To: Scott G. Kelly; Stephen Kent; Sam Hartman
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: [secdir] Please review
> > draft-ietf-capwap-protocol-specification's use of certificates
> >
> >
> > Although I agree with Steve that a MAC address would best be
> > placed within the SerialNumber attribute, the cat is long out
> > of the bag.  WiMAX Forum, IEEE 802.1ar and DOCSIS have all
> > specified inclusion of a MAC address within a CN.  So the
> > issue is no longer whether this is done, but rather, whether
> > it is done in a uniform way.
> >
> >
> >
> > ----------------------------------------
> > > Date: Fri, 21 Dec 2007 16:54:45 -0500
> > > From: [email-masked]
> > > To: [email-masked]; [email-masked]
> > > CC: [email-masked]; [email-masked]; =
[email-masked]
> > > Subject: Re: [secdir] Please review
> > > draft-ietf-capwap-protocol-specification's use of certificates
> > >
> > > Hi Steve,
> > >
> > > Thanks for taking a look at this. Regarding placement of
> > the MAC in the CN, I would offer two observations:
> > >
> > > 1) this is what is specified in the DOCSIS and PacketCable cert
> > > profiles, and it was on this basis that device certs for LWAPP =
were
> > > originally designed in this way. You can see the DOCSIS profile at
> > > www.drizzle.com/~aboba/CPW/DOCSIS.ppt
> > >
> > > 2) I don't see anything in the X.520 language that
> > explicitly precludes this usage, so assuming that the
> > docsis/packetcable designers reviewed that spec, I can see
> > how they could reasonably conclude that this is acceptable.
> > Arguably, the string representation of the MAC address is "a
> > string chosen [by the] organization responsible for the
> > object it describes for devices and application entities".
> > >
> > > Please don't misunderstand: I'm not trying to be difficult,
> > and I have a very healthy respect for the depth of your
> > knowledge in this area. However, there are a *lot* of devices
> > deployed that already use this convention. It might be more
> > pragmatic to interpret X.520 a little less restrictively.
> > >
> > > Scott
> > >
> > > -----Original Message-----
> > >>From: Stephen Kent
> > >>Sent: Dec 21, 2007 3:00 PM
> > >>To: Sam Hartman
> > >>Cc: [email-masked], [email-masked], =
[email-masked]
> > >>Subject: Re: [secdir] Please review
> > >>draft-ietf-capwap-protocol-specification's use of certificates
> > >>
> > >>At 9:23 PM -0500 12/20/07, Sam Hartman wrote:
> > >>>Hi, folks.  The capwap working group is preparing to last
> > call their
> > >>>protocol specification draft.
> > >>>
> > >>>I'd appreciate review from the pkix community of section
> > 2.4.4.3 and
> > >>>12.6 of this draft.  These sections specify certificate =
validation
> > >>>and certificate usage for the protocol.  Scott Kelly and Charles
> > >>>Clancy are security advisors for the working group and have been
> > >>>heavily involved.
> > >>>
> > >>>The capwap certificate profile assumes that the CN in the
> > certificate
> > >>>has structure and contains an ethernet MAC address.  The capwap
> > >>>certificate profile also assumes that parts of the subject
> > name such
> > >>>as the organization and organizational unit will be important to
> > >>>certificate matching.
> > >>>
> > >>>I'd appreciate review and comments.
> > >>>
> > >>>--Sam
> > >>
> > >>It would be preferable to get an allocated name space for MAC
> > >>addresses, under the OtherName or, better yet, under registeredID.
> > >>
> > >>I'd argue that it is inappropriate to put a MAC address into a CN.
> > >>The text from X.520 makes this clear:
> > >>
> > >>The Common Name attribute type specifies an identifier of
> > an object.
> > >>A Common Name is not a directory name; it is a (possibly =
ambiguous)
> > >>name by which the object is commonly known in some limited
> > scope (such
> > >>as an organization) and conforms to the naming conventions of the
> > >>country or culture with which it is associated.
> > >>
> > >>An attribute value for common name is a string chosen either by =
the
> > >>person or organization it describes or the organization =
responsible
> > >>for the object it describes for devices and application
> > entities. For
> > >>example, a typical name of a person in an English-speaking country
> > >>comprises a personal title (e.g., Mr., Ms., Rd, Professor,
> > Sir, Lord),
> > >>a first name, middle name(s), last name, generation
> > qualifier (if any,
> > >>e.g., Jr.) and decorations and awards (if any e.g., QC).
> > >>
> > >>Examples
> > >>CN =3D "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE"
> > >>CN =3D "Divisional Coordination Committee"
> > >>CN =3D "High Speed Modem".
> > >>
> > >>If there is a very strong desire to make use of an existing
> > attribute
> > >>in the X.502 space, the SerialNumber attribute makes more sense. =
So
> > >>long as we are talking about long, term, stable MAC
> > addresses assigned
> > >>to devices by manufacturers, this is consistent with the
> > semantics of
> > >>that attribute.  Moreover, we have advised folks to use
> > SerialNumber
> > >>to represent data such as employee/student IDs in the past, so one
> > >>might expect to see support for this attribute in many CAs and
> > >>clients.
> > >>
> > >>Steve
> > >
> > > _______________________________________________
> > > secdir mailing list
> > > [email-masked]
> > > https://mailman.mit.edu/mailman/listinfo/secdir
> >
> > _______________________________________________
> > secdir mailing list
> > [email-masked]
> > https://mailman.mit.edu/mailman/listinfo/secdir
> >

------_=_NextPart_001_01C84D67.5BF21A60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>RE: [secdir] Please review =
draft-ietf-capwap-protocol-specification's use of certificates</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6000.16587" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText949 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>This all fits =
into the category of 'it really does not matter how it is done provided =
that as many systems as possible do it in the same way'.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>At some point it would be =
really nice to be able to use these certificates in combination with =
802.1x type authentication protocols. That is going to be easiest and =
cheapest for all concerned (manufacturers, administrators, tool =
builders) if there is as much consistency as possible.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Since we are having a debate =
about how to do this, how about a short RFC that describes one way to do =
it? Preferably the way CableLabs or whoever has the most device certs =
out there today does it. That way the next committee that starts down =
this path can read up on how it is done in the field already and use the =
result to swat down whatever NIH proposal someone would otherwise put on =
the table.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I would suggest that the spec =
would cover both the EUI-48 and EUI-64 address forms. Perhaps we could =
even persuade the IEEE to take a chunk of .arpa or other DNS space and =
hand out zone delegations along with OUI prefixes. That way =
manufacturers could if the choose use the DNS as a means of delivering =
indexes to device description information on demand as has utility in =
certain applications (but not necessarily all).</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I can spend time on this if =
there is interest.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked] on behalf of Russ Housley<BR><B>Sent:</B> =
Thu 27/12/2007 4:09 PM<BR><B>To:</B> Joseph Salowey (jsalowey); Bernard =
Aboba; Scott G. Kelly; Stephen Kent; Sam Hartman; Max Pritikin =
(pritikin)<BR><B>Cc:</B> [email-masked]; =
[email-masked]; [email-masked]<BR><B>Subject:</B> RE: [secdir] Please =
review draft-ietf-capwap-protocol-specification's use of =
certificates<BR></FONT><BR></DIV></DIV>=0A=
<DIV><BR>=0A=
<P><FONT size=3D2>CableLabs and WiMAX specifications include the MAC =
address in the CN.<BR><BR>Russ<BR><BR>At 06:19 PM 12/26/2007, Joseph =
Salowey (jsalowey) wrote:<BR><BR>&gt;I don't believe that 802.1AR uses =
the MAC address in the CN field.&nbsp; I<BR>&gt;believe it makes use of =
the SerialNumber field and does not mandate that<BR>&gt;the identity =
must be a MAC address (it doesn't prevent it either).&nbsp; =
The<BR>&gt;current text from draft 1.2 on SubjectName =
is<BR>&gt;<BR>&gt;"The DevID subject field shall uniquely identify the =
particular DevID<BR>&gt;credential within the issuer's domain of =
significance. The formatting of<BR>&gt;this field shall contain a unique =
X.500 distinguished name (DN). This<BR>&gt;may include the =
manufacturer's serial number, manufacturer's factory<BR>&gt;programmed =
MAC address, issuer's or user's node name or any other<BR>&gt;suitable =
unique string that the issuer prefers.<BR>&gt;<BR>&gt;It is recommended =
that the subject field's DN encoding include the<BR>&gt;'serialNumber' =
attribute with the device's unique serial number. "<BR>&gt;<BR>&gt;The =
current editor of the document, Max Pritikin, is copied on =
this<BR>&gt;message.<BR>&gt;<BR>&gt;Joe<BR>&gt;<BR>&gt; &gt; =
-----Original Message-----<BR>&gt; &gt; From: [email-masked] [<A =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]=
<BR>&gt; &gt; On Behalf Of Bernard Aboba<BR>&gt; &gt; Sent: Friday, =
December 21, 2007 8:00 PM<BR>&gt; &gt; To: Scott G. Kelly; Stephen Kent; =
Sam Hartman<BR>&gt; &gt; Cc: [email-masked]; =
[email-masked]; [email-masked]<BR>&gt; &gt; Subject: Re: [secdir] =
Please review<BR>&gt; &gt; draft-ietf-capwap-protocol-specification's =
use of certificates<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; Although I =
agree with Steve that a MAC address would best be<BR>&gt; &gt; placed =
within the SerialNumber attribute, the cat is long out<BR>&gt; &gt; of =
the bag.&nbsp; WiMAX Forum, IEEE 802.1ar and DOCSIS have all<BR>&gt; =
&gt; specified inclusion of a MAC address within a CN.&nbsp; So =
the<BR>&gt; &gt; issue is no longer whether this is done, but rather, =
whether<BR>&gt; &gt; it is done in a uniform way.<BR>&gt; &gt;<BR>&gt; =
&gt;<BR>&gt; &gt;<BR>&gt; &gt; =
----------------------------------------<BR>&gt; &gt; &gt; Date: Fri, 21 =
Dec 2007 16:54:45 -0500<BR>&gt; &gt; &gt; From: =
[email-masked]<BR>&gt; &gt; &gt; To: [email-masked]; =
[email-masked]<BR>&gt; &gt; &gt; CC: =
[email-masked]; [email-masked]; [email-masked]<BR>&gt; =
&gt; &gt; Subject: Re: [secdir] Please review<BR>&gt; &gt; &gt; =
draft-ietf-capwap-protocol-specification's use of certificates<BR>&gt; =
&gt; &gt;<BR>&gt; &gt; &gt; Hi Steve,<BR>&gt; &gt; &gt;<BR>&gt; &gt; =
&gt; Thanks for taking a look at this. Regarding placement of<BR>&gt; =
&gt; the MAC in the CN, I would offer two observations:<BR>&gt; &gt; =
&gt;<BR>&gt; &gt; &gt; 1) this is what is specified in the DOCSIS and =
PacketCable cert<BR>&gt; &gt; &gt; profiles, and it was on this basis =
that device certs for LWAPP were<BR>&gt; &gt; &gt; originally designed =
in this way. You can see the DOCSIS profile at<BR>&gt; &gt; &gt; =
www.drizzle.com/~aboba/CPW/DOCSIS.ppt<BR>&gt; &gt; &gt;<BR>&gt; &gt; =
&gt; 2) I don't see anything in the X.520 language that<BR>&gt; &gt; =
explicitly precludes this usage, so assuming that the<BR>&gt; &gt; =
docsis/packetcable designers reviewed that spec, I can see<BR>&gt; &gt; =
how they could reasonably conclude that this is acceptable.<BR>&gt; &gt; =
Arguably, the string representation of the MAC address is "a<BR>&gt; =
&gt; string chosen [by the] organization responsible for the<BR>&gt; =
&gt; object it describes for devices and application entities".<BR>&gt; =
&gt; &gt;<BR>&gt; &gt; &gt; Please don't misunderstand: I'm not trying =
to be difficult,<BR>&gt; &gt; and I have a very healthy respect for the =
depth of your<BR>&gt; &gt; knowledge in this area. However, there are a =
*lot* of devices<BR>&gt; &gt; deployed that already use this convention. =
It might be more<BR>&gt; &gt; pragmatic to interpret X.520 a little less =
restrictively.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Scott<BR>&gt; &gt; =
&gt;<BR>&gt; &gt; &gt; -----Original Message-----<BR>&gt; &gt; =
&gt;&gt;From: Stephen Kent<BR>&gt; &gt; &gt;&gt;Sent: Dec 21, 2007 3:00 =
PM<BR>&gt; &gt; &gt;&gt;To: Sam Hartman<BR>&gt; &gt; &gt;&gt;Cc: =
[email-masked], [email-masked], [email-masked]<BR>&gt; =
&gt; &gt;&gt;Subject: Re: [secdir] Please review<BR>&gt; &gt; =
&gt;&gt;draft-ietf-capwap-protocol-specification's use of =
certificates<BR>&gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt;&gt;At 9:23 PM -0500 =
12/20/07, Sam Hartman wrote:<BR>&gt; &gt; &gt;&gt;&gt;Hi, folks.&nbsp; =
The capwap working group is preparing to last<BR>&gt; &gt; call =
their<BR>&gt; &gt; &gt;&gt;&gt;protocol specification draft.<BR>&gt; =
&gt; &gt;&gt;&gt;<BR>&gt; &gt; &gt;&gt;&gt;I'd appreciate review from =
the pkix community of section<BR>&gt; &gt; 2.4.4.3 and<BR>&gt; &gt; =
&gt;&gt;&gt;12.6 of this draft.&nbsp; These sections specify certificate =
validation<BR>&gt; &gt; &gt;&gt;&gt;and certificate usage for the =
protocol.&nbsp; Scott Kelly and Charles<BR>&gt; &gt; &gt;&gt;&gt;Clancy =
are security advisors for the working group and have been<BR>&gt; &gt; =
&gt;&gt;&gt;heavily involved.<BR>&gt; &gt; &gt;&gt;&gt;<BR>&gt; &gt; =
&gt;&gt;&gt;The capwap certificate profile assumes that the CN in =
the<BR>&gt; &gt; certificate<BR>&gt; &gt; &gt;&gt;&gt;has structure and =
contains an ethernet MAC address.&nbsp; The capwap<BR>&gt; &gt; =
&gt;&gt;&gt;certificate profile also assumes that parts of the =
subject<BR>&gt; &gt; name such<BR>&gt; &gt; &gt;&gt;&gt;as the =
organization and organizational unit will be important to<BR>&gt; &gt; =
&gt;&gt;&gt;certificate matching.<BR>&gt; &gt; &gt;&gt;&gt;<BR>&gt; &gt; =
&gt;&gt;&gt;I'd appreciate review and comments.<BR>&gt; &gt; =
&gt;&gt;&gt;<BR>&gt; &gt; &gt;&gt;&gt;--Sam<BR>&gt; &gt; =
&gt;&gt;<BR>&gt; &gt; &gt;&gt;It would be preferable to get an allocated =
name space for MAC<BR>&gt; &gt; &gt;&gt;addresses, under the OtherName =
or, better yet, under registeredID.<BR>&gt; &gt; &gt;&gt;<BR>&gt; &gt; =
&gt;&gt;I'd argue that it is inappropriate to put a MAC address into a =
CN.<BR>&gt; &gt; &gt;&gt;The text from X.520 makes this clear:<BR>&gt; =
&gt; &gt;&gt;<BR>&gt; &gt; &gt;&gt;The Common Name attribute type =
specifies an identifier of<BR>&gt; &gt; an object.<BR>&gt; &gt; =
&gt;&gt;A Common Name is not a directory name; it is a (possibly =
ambiguous)<BR>&gt; &gt; &gt;&gt;name by which the object is commonly =
known in some limited<BR>&gt; &gt; scope (such<BR>&gt; &gt; &gt;&gt;as =
an organization) and conforms to the naming conventions of the<BR>&gt; =
&gt; &gt;&gt;country or culture with which it is associated.<BR>&gt; =
&gt; &gt;&gt;<BR>&gt; &gt; &gt;&gt;An attribute value for common name is =
a string chosen either by the<BR>&gt; &gt; &gt;&gt;person or =
organization it describes or the organization responsible<BR>&gt; &gt; =
&gt;&gt;for the object it describes for devices and application<BR>&gt; =
&gt; entities. For<BR>&gt; &gt; &gt;&gt;example, a typical name of a =
person in an English-speaking country<BR>&gt; &gt; &gt;&gt;comprises a =
personal title (e.g., Mr., Ms., Rd, Professor,<BR>&gt; &gt; Sir, =
Lord),<BR>&gt; &gt; &gt;&gt;a first name, middle name(s), last name, =
generation<BR>&gt; &gt; qualifier (if any,<BR>&gt; &gt; &gt;&gt;e.g., =
Jr.) and decorations and awards (if any e.g., QC).<BR>&gt; &gt; =
&gt;&gt;<BR>&gt; &gt; &gt;&gt;Examples<BR>&gt; &gt; &gt;&gt;CN =3D "Mr. =
Robin Lachlan McLeod BSc(Hons) CEng MIEE"<BR>&gt; &gt; &gt;&gt;CN =3D =
"Divisional Coordination Committee"<BR>&gt; &gt; &gt;&gt;CN =3D "High =
Speed Modem".<BR>&gt; &gt; &gt;&gt;<BR>&gt; &gt; &gt;&gt;If there is a =
very strong desire to make use of an existing<BR>&gt; &gt; =
attribute<BR>&gt; &gt; &gt;&gt;in the X.502 space, the SerialNumber =
attribute makes more sense. So<BR>&gt; &gt; &gt;&gt;long as we are =
talking about long, term, stable MAC<BR>&gt; &gt; addresses =
assigned<BR>&gt; &gt; &gt;&gt;to devices by manufacturers, this is =
consistent with the<BR>&gt; &gt; semantics of<BR>&gt; &gt; &gt;&gt;that =
attribute.&nbsp; Moreover, we have advised folks to use<BR>&gt; &gt; =
SerialNumber<BR>&gt; &gt; &gt;&gt;to represent data such as =
employee/student IDs in the past, so one<BR>&gt; &gt; &gt;&gt;might =
expect to see support for this attribute in many CAs and<BR>&gt; &gt; =
&gt;&gt;clients.<BR>&gt; &gt; &gt;&gt;<BR>&gt; &gt; =
&gt;&gt;Steve<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; =
_______________________________________________<BR>&gt; &gt; &gt; secdir =
mailing list<BR>&gt; &gt; &gt; [email-masked]<BR>&gt; &gt; &gt; <A =
href=3D"https://mailman.mit.edu/mailman/listinfo/secdir">https://mailman.=
mit.edu/mailman/listinfo/secdir</A><BR>&gt; &gt;<BR>&gt; &gt; =
_______________________________________________<BR>&gt; &gt; secdir =
mailing list<BR>&gt; &gt; [email-masked]<BR>&gt; &gt; <A =
href=3D"https://mailman.mit.edu/mailman/listinfo/secdir">https://mailman.=
mit.edu/mailman/listinfo/secdir</A><BR>&gt; =
&gt;<BR><BR></FONT></P></DIV></BODY></HTML>
------_=_NextPart_001_01C84D67.5BF21A60--