Subject: RE: 3280bis redefines HTTP

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 28 Sep 2006 12:14:06 -0700

These may be valid operational issues but as such they have no valid place in a standard designed to serve for several decades.

If we prohibit signature generation for performance reasons this suggests that there might be a problem with verification as well. (It is not necessarily the case that verification is faster). 

Regardless the restriction is unverifiable and hence unenforceable. The syntactic form of a URL says nothing about the resource it refers to.

I doubt that many engineers would read the spec and insert a check to reject a URI that was not formed exactly as specified: 

If (not-what-I-expect) then
	throw (hissy-fit)

> -----Original Message-----
> From: Alan Sill [mailto:[email-masked]] 
> Sent: Thursday, September 28, 2006 3:03 PM
> To: Hallam-Baker, Phillip
> Cc: Alan Sill; Anders Rundgren; [email-masked]
> Subject: Re: 3280bis redefines HTTP
> 
> The purpose of this is to prevent CRL's from being logical 
> URIs, but instead actually to be physical entities on a disk. 
>  I do not know the origin of this restriction, which has 
> cause a certain amount of questioning in my community 
> (grids), but I can say that one does NOT want to implement 
> CRLs via time-consuming mechanisms in general, and in 
> particular tomcat servlets (although I am a fan of Tomcat in other
> circumstances) would be a very bad way to implement a CRL.
> 
> In any substantial deployment, as hinted here, it is crucial 
> to have a CRL responder that is very fast indeed.  Most CRL 
> servers used in academic grids already run at several hundred 
> hits per second, and the rate is going up.  This is driving 
> research on credential validation methods that do not use 
> CRLs as intensively.  For now, you should NOT read the RFC as 
> a mistake, but as a requirement.  At minimum, to meet this 
> requirement, your CRL identifier must be fully specified, i.e.,
> 
> http://mycrlserver.domain.tld/crlname.ext
> 
> and not
> 
> http://mycrlserver.domain.tld/crlname/
> 
> (Didn't invent it, not my fault, that's the spec.)
> 
> Alan
> 
> On Sep 28, 2006, at 12:18 PM, Hallam-Baker, Phillip wrote:
> 
> > There is a minor problem here and a significant error.
> >
> > The minor problem is the use of the term 'file' in place of 
> > 'resource'. Since a file is merely an abstraction for a bag of bits 
> > this does not worry me very much. Some people assume that file must 
> > mean a resource stored on disk. It worried some people in 
> the context 
> > of http and they started using the term resource.
> >
> > The more troubling issue is the use of the file extension 
> rather than 
> > the mime content type. This is likely to cause problems in 
> quite a few 
> > deployments. It is clearly an error, it might be a mistake.
> >
> >
> > On the wording for logotypes I would be happier with stating that 
> > there SHOULD be an HTTP uri and that FTP and LDAP SHOULD 
> NOT be used. 
> > Mandating HTTP is likely to be a problem down the road when we have 
> > something better. Its not a major concern unless someone thought it 
> > was OK to write code that would actually break if it saw a non HTTP 
> > URI.
> >
> > Prohibiting LDAP and FTP does make good sense, they are both less 
> > efficient than HTTP. FTP is much less efficient and less reliable 
> > through NAT.
> >
> > From: [email-masked] [mailto:owner-ietf- 
> > [email-masked]] On Behalf Of Anders Rundgren
> > Sent: Wednesday, September 27, 2006 2:50 PM
> > To: [email-masked]
> > Subject: 3280bis redefines HTTP
> >
> > Talking about standards, the following extract from 3280bis 
> contains 
> > an interpretation of HTTP which is quite unique:
> >
> >
> >    Where the information is available via HTTP or FTP, 
> accessLocation
> >    MUST be a uniformResourceIdentifier and the URI MUST point to a 
> > certificate file.
> >    The certificate file MUST contain either a single
> >    DER encoded certificate (indicated by the .cer file 
> extension) or a
> >    collection of certificates (indicated by the .p7c file 
> extension):
> >
> >
> >
> > Outside of 3280bis, HTTP UIRs like
> >
> > http://example.com/index.html
> > http://example.com/index.asp
> > http://example.com/home
> > http://example.com/library?id=2
> >
> > work flawlessly in spite of either using a real file extension 
> > (.html), a file extension which as no meaning for a client 
> (.asp), or  
> > having no extensions at all.  If the underlaying object is 
> a "file" or 
> > not is totally ireelvant.  In fact, the depencdy on file 
> extension for 
> > HTTP URIs complicates deployment if you want to use a Servlet or 
> > similar rather than a file.  The Apache web-server
> > requires a change in the MIME master table in order to do this.   
> > But such a change affects static contents and is therefore highly 
> > impopular.  MIME-types represent the established way of associating 
> > HTTP objects with consuming applications.
> >
> > Putting this in a typical CA context it is probably a good idea 
> > publishing certficates in an LDAP directory.  If you want 
> to provide 
> > HTTP access as well, a trivial way would be to wrap a suitable LDAP 
> > call in a JSP page or .NET appication. Such applications do 
> normally 
> > not use file extensions except ..jsp and
> > aspx.  http://example.com/respository/certs.aspx?id=455 
> works just   
> > fine.
> >
> > Using FTP, you indeed need to bother about file-names, but FTP is 
> > another protocol, not to be confused with HTTP.  Since LDAP got its 
> > own wording, you might do the same with HTTP.
> >
> > Anders
> >
> >
> > ----- Original Message -----
> > From: Stephen Kent
> > To: Anders Rundgren
> > Cc: Sharon Boeyen ; 'Stefan Santesson' ; [email-masked]
> > Sent: Wednesday, September 27, 2006 00:04
> > Subject: Re: 3280bis AIA RFC2585 and RFC2797 deviations
> >
> > At 9:39 PM +0200 9/26/06, Anders Rundgren wrote:
> >> Sharon & Stefan,
> >> I did not write that AIA -aIssuers should be mandatory, or even be 
> >> recommended.
> >>
> >> I simply asked you to lower the bar for clients in order 
> to improve 
> >> interoperability.
> >> Since the CA defines this property unilaterally, it is kind of 
> >> critical that it is usable.
> >>
> >> I noted that in the Logotypes RFC, HTTP is a MUST.  In what aspect 
> >> are certificates files different from image files with respect to 
> >> access?  IMO, not at all.
> >
> > certs are nominally available via a wide range of ways, which are 
> > under the control of CAs and others who choose to operate 
> > repositories. The AIA and SIA extensions allow specification of 
> > various access methods to accommodate such diversity. The logotypes 
> > extension defined a new data item and Stefan, as the 
> author, chose a 
> > particular method of making them accessible. Nobody argued 
> for other 
> > access methods at the time this was proposed, so ...
> >
> >>  Regarding "alien" file-extensions and MIME-types: I believe it is 
> >> prudent documenting established practices rather than hoping that 
> >> nobody will notice the glitches that will result by ignoring them.
> >
> > An established practice that is not the product of an IETF 
> WG can be 
> > documented via an informational RFC written by the folks who 
> > established the practice. Including comments about such 
> practices in a 
> > standards track RFC obscures the distinction.
> >
> >>  Since a CA is usually server you can put higher 
> requirements on a CA 
> >> than on clients, there seems to be a reasonable compromise:
> >
> > CAs are not servers acting as repositories. While a CA may 
> choose to 
> > operate a repository for the certs and CRLs is issues, prudent 
> > security practice often calls for a machine signing certs to not be 
> > directly accessible in the same fashion as a repository.  So maybe 
> > what you meant to say above was that IF a CA operates a 
> repository for 
> > such data, then it is likely to be a highly available machine.
> >
> >> HTTP and LDAP could be RECOMMENDED for AIA-caIssuers-using CAs.   
> >> There isn't a "certificate-user" (it is a program) that 
> can't handle 
> >> at least one of these.  Often both.
> >>
> >> http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf
> >> "AIA extensions include both LDAP and HTTP URIs for id-ad- 
> caIssuers 
> >> access method"
> >>
> >> That is, this is already a standard.
> >
> > This is a U.S. Government PKI profile, but that does not make it a 
> > global standard of the sort we develop in the IETF.
> >
> > Steve
> >
> 
> Alan Sill
> TIGRE Senior Scientist
> High Performance Computing Center
> TTU
> 
> ====================================================================
> :  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
> :  e-mail: [email-masked]   ph. 806-742-4350  fax 806-742-4358  :
> ====================================================================
> 
> 
>

---

From: Alan Sill <[email-masked]>
Date: Thu, 28 Sep 2006 15:18:35 -0500

Phillip,

I do not disagree with you on any point of philosophy!!  I do however  
point out that conformance with RFC 3280, which has specified this  
for some time, requires a full specification of the destination for  
the CRL distribution point, with name and extension.  It was probably  
written this way to discourage (although not completely prevent)  
programmatic reconfiguration.  Note also that many implementations  
have been written at this point involving caching layers, which do  
not deal well with redirects.

Some discussion on implementation including LDAP, as in the original  
thread (including optional URI checking), can be found at:

http://jce.iaik.tugraz.at/sic/support/technical_articles/ 
how_to_fetch_crls_from_distribution_points

Note that the URI MUST be in the certificate, and so should be a  
stable location.

In practice I have seen URIs that deviate from this practice, though  
for reasons of compatibility with all software (some of which DOES  
check the URI for compliance), this is discouraged.

Moving to OCSP and more general credential validation is probably a  
more productive avenue than arguing this point, as CRLs don't scale  
well to very high volumes anyway...

Alan

On Sep 28, 2006, at 2:14 PM, Hallam-Baker, Phillip wrote:

> These may be valid operational issues but as such they have no  
> valid place in a standard designed to serve for several decades.
>
> If we prohibit signature generation for performance reasons this  
> suggests that there might be a problem with verification as well.  
> (It is not necessarily the case that verification is faster).
>
> Regardless the restriction is unverifiable and hence unenforceable.  
> The syntactic form of a URL says nothing about the resource it  
> refers to.
>
> I doubt that many engineers would read the spec and insert a check  
> to reject a URI that was not formed exactly as specified:
>

Alan Sill
TIGRE Senior Scientist

---

From: Alan Sill <[email-masked]>
Date: Thu, 28 Sep 2006 15:24:21 -0500

Pursuant to the original question, let me point  out the following  
document conveying CA best practices for grids in the form of an OGF  
document:

http://forge.gridforum.org/sf/go/doc13742?nav=1

Further information on IGTF profiles and practices can be obtained at

http://gridpma.org

Alan

Alan Sill
TIGRE Senior Scientist

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 29 Sep 2006 07:13:05 +0200

Alan,

The [published] RFC 3280  says nothing about file extensions.
This has been introduced in 3280bis.

Core problem: 3280bis treats FTP and HTTP as the *same* protocol.

Regardless the merits of FTP as a protocol in this context, mixing[up] the
two protocols gives "unwanted side-effects" like URL constraints on HTTP.

If programmatic web-server access is slow or not is as Phill pointed out
outside of the scope of a standard.

That OCSP is both programmatic and typically use HTTP indicates that this is
not a universal truth.

But please note: Your best practices are 100% compatible with what I suggest!
No existing code is broken.  

The late introduction of "URL constraints" may indeed render some code
non-conformant but it will not cease to work unless vendors begin to *remove*
support for the existing practice.  If the latter is the ultimate goal of 3280bis,
I am getting quite worried..

regards
Anders

----- Original Message ----- 
From: "Alan Sill" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Cc: "Alan Sill" <[email-masked]>; "Anders Rundgren" <[email-masked]>; <[email-masked]>
Sent: Thursday, September 28, 2006 22:18
Subject: Re: 3280bis redefines HTTP

Phillip,

Alan

Alan Sill
TIGRE Senior Scientist

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Sep 2006 08:30:28 +0100

All very interesting. Be more effective if one of you would
offer some alternative text though.

S.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 29 Sep 2006 17:55:34 +0200

What about:

When a uniformResourceidentifier indicating an FTP protocol is used, a 
filename
suffix .cer (RFC2585) indicates a single DER encoded certificate a 
suffix .p7c
(RFC 2797) indicates a "certs-only" CMS message containing a list of 
certificates.

When a uniformResourceidentifier indicating an HTTP protocol is used,
the a content-type application/pkix-cert (RFC2585) indicates a
single DER encoded certificate and application/pkcs7-mime (RFC 2797) 
indicates
a "certs-only" CMS message containing a list of certificates.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Sep 2006 20:58:37 +0100

Looks ok to me, but then so does the current text.

S.

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 30 Sep 2006 00:08:55 +0200

Peter,

That looks like a good start for a revised text but since these issues are repeated
several times thought the RFC, it seems that this could be stuffed in a subsection
describing URL locator access to static resources.  A good ol table would be
really nice!

Regarding some of the finer details, I still question the value of introducing and
enforcing MIME-identifiers and file-extension that are in conflict with the informal
standards supported (since 7Y+) by the two leading web server vendors, and
thus also by a billion or so web browsers:
http://www.microsoft.com/technet/isa/2004/plan/mimetypes.mspx#E4AAC

Therefore I suggest that certificate-using software MUST support the "new"
extensions and MIME-types, but that they (for backward compatibility reasons)
SHOULD also support the "legacy" extensions and MIME types.

This is indeed a compromise but what would an engineer's life be without
compromises? :-)

I'm prepared spending a few hours on the text, if the editors agree on the
basic principles.

Anders

----- Original Message -----
From: "Peter Sylvester" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>; "Hallam-Baker, Phillip" <[email-masked]>; "Alan Sill" <[email-masked]>;
<[email-masked]>
Sent: Friday, September 29, 2006 17:55
Subject: Re: 3280bis redefines HTTP

What about:

Date: Sat, 30 Sep 2006 20:12:13 -0300
Reply-To: "Gaja Grey" <[email-masked]>
From: "Gaja Grey" <[email-masked]>
To: <[email-masked]>
Subject: my PHAeykRMA

This is a multi-part message in MIME format.

------=_NextPart_000_313B_01C6E4CC.B7C23FE0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Good day,

AMBzzIEN

VIAzzGRA

VALzzIUM

CIAzzLIS

Econnomize over 50 % with http://www.vertionkasefuterindas.com
=20
  _____ =20

Madonette, this might affect her. This entire affair was getting a
just an observation. Such as the observation that men are basically
I can kill you-quite quickly, The Commander said coldly and calmly.

------=_NextPart_000_313B_01C6E4CC.B7C23FE0
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Good day,</DIV>
<P>AMBzzIEN</P>
<P>VIAzzGRA</P>
<P>VALzzIUM</P>
<P>CIAzzLIS</P>
<DIV>Econnomize over 50 % with <A =
href=3D"http://www.vertionkasefuterindas.com">http://www.vertionkasefuter=
indas.com</A></DIV>
<DIV>
<DIV>&nbsp;</DIV>
<HR></DIV><P>Madonette,  this might affect her. This entire affair  was  =
getting  a<BR>
just  an  observation. Such as the observation that men are  =
basically<BR>
 I  can kill you-quite quickly, The Commander said coldly and =
calmly.<BR></P></BODY></HTML>
------=_NextPart_000_313B_01C6E4CC.B7C23FE0--

From: "Anders Rundgren" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "Hallam-Baker, Phillip" <[email-masked]>, "Alan Sill" <[email-masked]>, <[email-masked]>
Subject: Re: 3280bis  redefines HTTP
Date: Sat, 30 Sep 2006 00:08:55 +0200
Sender: [email-masked]

Peter,

That looks like a good start for a revised text but since these issues are repeated
several times thought the RFC, it seems that this could be stuffed in a subsection
describing URL locator access to static resources.  A good ol table would be
really nice!

Regarding some of the finer details, I still question the value of introducing and
enforcing MIME-identifiers and file-extension that are in conflict with the informal
standards supported (since 7Y+) by the two leading web server vendors, and
thus also by a billion or so web browsers:
http://www.microsoft.com/technet/isa/2004/plan/mimetypes.mspx#E4AAC

Therefore I suggest that certificate-using software MUST support the "new"
extensions and MIME-types, but that they (for backward compatibility reasons)
SHOULD also support the "legacy" extensions and MIME types.

This is indeed a compromise but what would an engineer's life be without
compromises? :-)

I'm prepared spending a few hours on the text, if the editors agree on the
basic principles.

Anders

----- Original Message -----
From: "Peter Sylvester" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>; "Hallam-Baker, Phillip" <[email-masked]>; "Alan Sill" <[email-masked]>;
<[email-masked]>
Sent: Friday, September 29, 2006 17:55
Subject: Re: 3280bis redefines HTTP

What about:

Date: Fri, 29 Sep 2006 20:58:37 +0100
From: Stephen Farrell <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: Anders Rundgren <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, Alan Sill <[email-masked]>, [email-masked]
Subject: Re: 3280bis  redefines HTTP
Sender: [email-masked]

S.

> a "certs-only" CMS message containing a list of certificates.

Date: Fri, 29 Sep 2006 19:17:22 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

Peter Rybar wrote:
> I was afraid of inaccurate understanding of RFC 3161 from other discussions being sent about this problem.
>   
There seem to be some confusion indeed lying here, and not having a 
*good* description of what there is in the ISO doc will not help.
> Timestamp is CMS signature which can be inserted to another CMS signature as signed attribute (id-aa-ets-contentTimestamp) or as unsigned attribute (id-aa-signatureTimeStampToken, id-aa-ets-escTimeStamp, id-aa-ets-certCRLTimestamp, id-aa-ets-archiveTimestamp).
> Timestamp according to RFC 3161 is not a countersignature and there was the misunderstanding!
>
> If ISO plans to do that as a countersignature then it looks like as problem in implementations in some applications.
> The countersignature is an unsigned attribute of the type SignerInfo which is included in the main SignerInfo and the countersignature signs hash of the signature (SignatureValue) within the main SignerInfo.
>   
RFC3161 defines timestamp as an unsigned attribute inside a  SignerInfo 
that signs hash of the signature (SignatureValue) within that SignerInfo 
(I will not cover here the various CADES variations).

So this is extremly similar to a counter signature except that
- the format of the counter signature is SignerInfo and
- the format of the token is TimeStampToken (a signed CMS whose signed 
content is a TSTInfo structure with various information amongst which 
the hash ).

How can the ISO standard be nearer to a counter signature than that ? Is 
it that the ISO standard defines the timestamp as a SignerInfo 
structure  and uses specific signed attributes to add the needed 
additional info for a time-stamp ?

Date: Fri, 29 Sep 2006 17:55:34 +0200
From: Peter Sylvester <[email-masked]>
To: Stephen Farrell <[email-masked]>
CC: Anders Rundgren <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, Alan Sill <[email-masked]>, [email-masked]
Subject: Re: 3280bis  redefines HTTP
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

What about:

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

--------------ms090808050904000709090307--

Content-class: urn:content-classes:message
Subject: RE: Call for volunteers for a ECC subject public key info design team
Date: Fri, 29 Sep 2006 15:53:42 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Daniel Brown" <[email-masked]>
Cc: <[email-masked]>, "Stephen Kent" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6E3D7.0FC63E96
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

Daniel,

=20

First of all I would like to ask you to submit a new draft, at this
moment there is no valid draft available.

=20

I'm not personally convinced restricting the sequence to 1 algorithm
solves the issue but what you state below is a good input to the design
team.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: Daniel Brown [mailto:[email-masked]]=20
Sent: den 29 september 2006 16:28
To: Stefan Santesson
Cc: [email-masked]; Stephen Kent
Subject: Re: Call for volunteers for a ECC subject public key info
design team

=20

Stefan Santessan wrote on 09/28/2006 10:49:01 PM:

> We have since quite some time had two diverse positions on how to=20
> specify subject public key info for ECC public keys in X.509
certificates.=20
>  =20
> On one hand the current proposal embracing the ANSI solution with a=20
> structured subject public key info that has the capacity to specify=20
> algorithm modes, and the RFC 4055 approach on the other hand using a
> single OID to specify algorithm and parameters.=20

Ok, but again, just to clarify: this oversimplifies RFC 4055, which uses
up to three OIDs: one to specify the algorithm, and then some further
optional OIDs to specify the paramters.=20

Many of the objections I've heard to the ANSI syntax apply equally well
to RFC 4055.  =20

The main difference between the two approaches is that ANSI inserts one
extra layer: a SEQ of OIDs (and parameters as needed), whose purpose is
allow a single cert to permit more than one algorithm mode without
leaving it completely open.=20

My suggested compromise is to fix the ANSI sequence length to at most
one, which would make 4055 and ANSI functionally the same (by reducing
the capabilities of the ANSI syntax).  This would leave only syntactical
differences, which are trivial to handle.=20

Thanks,=20

Dan=20

 =20
> As other groups are dependent on our progress on this issue, in=20
> particular the Kerberos group, the Security ADs has requested us to=20
> form a design team to prepare a decision for the WG.=20
>  =20
> The design team shall;=20
>  =20
> (1) be made up of no more than five people.=20
> (2) interview (via the phone and/or e-mail) concerned parties.=20
> (3) document the pros and cons of each proposal, and make a=20
> recommendation to the WG.=20
>  =20
> The authors of RFC 4055 and authors of draft-ietf-pkix-ecc-pkalgs=20
> should be excluded from design team membership.=20
>  =20
> The selected design team should be prepared to make their=20
> recommendation at the PKIX meeting in San Diego (or before on the=20
> mail list, which would be even better).  Then, the PKIX WG can have=20
> a straw poll to see if the design team recommendation is accepted. =20
> Of course, it needs to be followed up by WG mail list confirmation.=20
>  =20
> If you are interested to be part of this design team, please send me
> and Steve Kent an e-mail no later than Friday next week (October 6).

>  =20
>  =20
> Stefan Santesson=20
> Senior Program Manager=20
> Windows Security, Standards

------_=_NextPart_001_01C6E3D7.0FC63E96
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

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

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

<div class=3DSection1>

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

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

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>First of all I would like to ask you to submit a new =
draft, at
this moment there is no valid draft available.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I&#8217;m not personally convinced restricting the =
sequence to 1
algorithm solves the issue but what you state below is a good input to =
the
design team.<o:p></o:p></span></p>

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

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

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

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

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

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

<div>

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

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Daniel Brown =
[mailto:[email-masked]] <br>
<b>Sent:</b> den 29 september 2006 16:28<br>
<b>To:</b> Stefan Santesson<br>
<b>Cc:</b> [email-masked]; Stephen Kent<br>
<b>Subject:</b> Re: Call for volunteers for a ECC subject public key =
info
design team<o:p></o:p></span></p>

</div>

</div>

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

<p class=3DMsoNormal><br>
<tt><span style=3D'font-size:10.0pt'>Stefan Santessan wrote on =
09/28/2006
10:49:01 PM:</span></tt><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<br>
<tt>&gt; We have since quite some time had two diverse positions on how =
to </tt><br>
<tt>&gt; specify subject public key info for ECC public keys in X.509
certificates.</tt></span> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; &nbsp;</span></tt> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; On one hand the current =
proposal
embracing the ANSI solution with a </span></tt><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><br>
<tt>&gt; structured subject public key info that has the capacity to =
specify </tt><br>
<tt>&gt; algorithm modes, and the RFC 4055 approach on the other hand =
using a</tt><br>
<tt>&gt; single OID to specify algorithm and parameters.</tt></span> =
<br>
<br>
<tt><span style=3D'font-size:10.0pt'>Ok, but again, just to clarify: =
this
oversimplifies RFC 4055, which uses up to three OIDs: one to specify the
algorithm, and then some further optional OIDs to specify the =
paramters.</span></tt>
<br>
<br>
<tt><span style=3D'font-size:10.0pt'>Many of the objections I've heard =
to the
ANSI syntax apply equally well to RFC 4055. &nbsp;</span></tt> <br>
<br>
<tt><span style=3D'font-size:10.0pt'>The main difference between the two
approaches is that ANSI inserts one extra layer: a SEQ of OIDs (and =
parameters
as needed), whose purpose is allow a single cert to permit more than one
algorithm mode without leaving it completely open.</span></tt> <br>
<br>
<tt><span style=3D'font-size:10.0pt'>My suggested compromise is to fix =
the ANSI
sequence length to at most one, which would make 4055 and ANSI =
functionally the
same (by reducing the capabilities of the ANSI syntax). &nbsp;This would =
leave
only syntactical differences, which are trivial to handle.</span></tt> =
<br>
<br>
<tt><span style=3D'font-size:10.0pt'>Thanks,</span></tt> <br>
<br>
<tt><span style=3D'font-size:10.0pt'>Dan</span></tt> <br>
<br>
<tt><span style=3D'font-size:10.0pt'>&nbsp; </span></tt><br>
<tt><span style=3D'font-size:10.0pt'>&gt; As other groups are dependent =
on our
progress on this issue, in </span></tt><span style=3D'font-size:10.0pt;
font-family:"Courier New"'><br>
<tt>&gt; particular the Kerberos group, the Security ADs has requested =
us to </tt><br>
<tt>&gt; form a design team to prepare a decision for the =
WG.</tt></span> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; &nbsp;</span></tt> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; The design team =
shall;</span></tt> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; &nbsp;</span></tt> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; (1) be made up of no more than =
five
people.</span></tt> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; (2) interview (via the phone =
and/or
e-mail) concerned parties.</span></tt> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; (3) document the pros and cons =
of each
proposal, and make a </span></tt><span =
style=3D'font-size:10.0pt;font-family:
"Courier New"'><br>
<tt>&gt; recommendation to the WG.</tt></span> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; &nbsp;</span></tt> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; The authors of RFC 4055 and =
authors of
draft-ietf-pkix-ecc-pkalgs </span></tt><span style=3D'font-size:10.0pt;
font-family:"Courier New"'><br>
<tt>&gt; should be excluded from design team membership.</tt></span> =
<br>
<tt><span style=3D'font-size:10.0pt'>&gt; &nbsp;</span></tt> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; The selected design team =
should be
prepared to make their </span></tt><span =
style=3D'font-size:10.0pt;font-family:
"Courier New"'><br>
<tt>&gt; recommendation at the PKIX meeting in San Diego (or before on =
the </tt><br>
<tt>&gt; mail list, which would be even better). &nbsp;Then, the PKIX WG =
can
have </tt><br>
<tt>&gt; a straw poll to see if the design team recommendation is =
accepted.
&nbsp;</tt><br>
<tt>&gt; Of course, it needs to be followed up by WG mail list =
confirmation.</tt></span>
<br>
<tt><span style=3D'font-size:10.0pt'>&gt; &nbsp;</span></tt> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; If you are interested to be =
part of
this design team, please send me</span></tt><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><br>
<tt>&gt; and Steve Kent an e-mail no later than Friday next week =
(October 6).
&nbsp;</tt></span> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; &nbsp;</span></tt> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; &nbsp;</span></tt> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; Stefan Santesson</span></tt> =
<br>
<tt><span style=3D'font-size:10.0pt'>&gt; Senior Program =
Manager</span></tt> <br>
<tt><span style=3D'font-size:10.0pt'>&gt; Windows Security, =
Standards</span></tt><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C6E3D7.0FC63E96--

To: "Stefan Santesson" <[email-masked]>
Cc: [email-masked], "Stephen Kent" <[email-masked]>
Subject: Re: Call for volunteers for a ECC subject public key info design team
From: Daniel Brown <[email-masked]>
Date: Fri, 29 Sep 2006 10:27:56 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 004FF924852571F8_=
Content-Type: text/plain; charset="US-ASCII"

Stefan Santessan wrote on 09/28/2006 10:49:01 PM:

> We have since quite some time had two diverse positions on how to 
> specify subject public key info for ECC public keys in X.509 
certificates.
> 
> On one hand the current proposal embracing the ANSI solution with a 
> structured subject public key info that has the capacity to specify 
> algorithm modes, and the RFC 4055 approach on the other hand using a
> single OID to specify algorithm and parameters.

Ok, but again, just to clarify: this oversimplifies RFC 4055, which uses 
up to three OIDs: one to specify the algorithm, and then some further 
optional OIDs to specify the paramters.

Many of the objections I've heard to the ANSI syntax apply equally well to 
RFC 4055. 

The main difference between the two approaches is that ANSI inserts one 
extra layer: a SEQ of OIDs (and parameters as needed), whose purpose is 
allow a single cert to permit more than one algorithm mode without leaving 
it completely open.

My suggested compromise is to fix the ANSI sequence length to at most one, 
which would make 4055 and ANSI functionally the same (by reducing the 
capabilities of the ANSI syntax).  This would leave only syntactical 
differences, which are trivial to handle.

Thanks,

Dan

> As other groups are dependent on our progress on this issue, in 
> particular the Kerberos group, the Security ADs has requested us to 
> form a design team to prepare a decision for the WG.
> 
> The design team shall;
> 
> (1) be made up of no more than five people.
> (2) interview (via the phone and/or e-mail) concerned parties.
> (3) document the pros and cons of each proposal, and make a 
> recommendation to the WG.
> 
> The authors of RFC 4055 and authors of draft-ietf-pkix-ecc-pkalgs 
> should be excluded from design team membership.
> 
> The selected design team should be prepared to make their 
> recommendation at the PKIX meeting in San Diego (or before on the 
> mail list, which would be even better).  Then, the PKIX WG can have 
> a straw poll to see if the design team recommendation is accepted. 
> Of course, it needs to be followed up by WG mail list confirmation.
> 
> If you are interested to be part of this design team, please send me
> and Steve Kent an e-mail no later than Friday next week (October 6). 
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
--=_alternative 004FF924852571F8_=
Content-Type: text/html; charset="US-ASCII"

<br><tt><font size=2>Stefan Santessan wrote on 09/28/2006 10:49:01 PM:<br>
<br>
&gt; We have since quite some time had two diverse positions on how to
<br>
&gt; specify subject public key info for ECC public keys in X.509 certificates.</font></tt>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; On one hand the current proposal embracing the
ANSI solution with a <br>
&gt; structured subject public key info that has the capacity to specify
<br>
&gt; algorithm modes, and the RFC 4055 approach on the other hand using
a<br>
&gt; single OID to specify algorithm and parameters.</font></tt>
<br>
<br><tt><font size=2>Ok, but again, just to clarify: this oversimplifies
RFC 4055, which uses up to three OIDs: one to specify the algorithm, and
then some further optional OIDs to specify the paramters.</font></tt>
<br>
<br><tt><font size=2>Many of the objections I've heard to the ANSI syntax
apply equally well to RFC 4055. &nbsp;</font></tt>
<br>
<br><tt><font size=2>The main difference between the two approaches is
that ANSI inserts one extra layer: a SEQ of OIDs (and parameters as needed),
whose purpose is allow a single cert to permit more than one algorithm
mode without leaving it completely open.</font></tt>
<br>
<br><tt><font size=2>My suggested compromise is to fix the ANSI sequence
length to at most one, which would make 4055 and ANSI functionally the
same (by reducing the capabilities of the ANSI syntax). &nbsp;This would
leave only syntactical differences, which are trivial to handle.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br>
<br><tt><font size=2>Dan</font></tt>
<br>
<br><tt><font size=2>&nbsp; </font></tt>
<br><tt><font size=2>&gt; As other groups are dependent on our progress
on this issue, in <br>
&gt; particular the Kerberos group, the Security ADs has requested us to
<br>
&gt; form a design team to prepare a decision for the WG.</font></tt>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; The design team shall;</font></tt>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; (1) be made up of no more than five people.</font></tt>
<br><tt><font size=2>&gt; (2) interview (via the phone and/or e-mail) concerned
parties.</font></tt>
<br><tt><font size=2>&gt; (3) document the pros and cons of each proposal,
and make a <br>
&gt; recommendation to the WG.</font></tt>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; The authors of RFC 4055 and authors of draft-ietf-pkix-ecc-pkalgs
<br>
&gt; should be excluded from design team membership.</font></tt>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; The selected design team should be prepared to
make their <br>
&gt; recommendation at the PKIX meeting in San Diego (or before on the
<br>
&gt; mail list, which would be even better). &nbsp;Then, the PKIX WG can
have <br>
&gt; a straw poll to see if the design team recommendation is accepted.
&nbsp;<br>
&gt; Of course, it needs to be followed up by WG mail list confirmation.</font></tt>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; If you are interested to be part of this design
team, please send me<br>
&gt; and Steve Kent an e-mail no later than Friday next week (October 6).
&nbsp;</font></tt>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; Stefan Santesson</font></tt>
<br><tt><font size=2>&gt; Senior Program Manager</font></tt>
<br><tt><font size=2>&gt; Windows Security, Standards</font></tt>
--=_alternative 004FF924852571F8_=--

Date: Fri, 29 Sep 2006 13:46:20 +0200
From: "Denis Pinkas" <[email-masked]>
To: "=?iso-8859-1?B?Sm9z6V9BLl9NYfFhcw==?=" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

José,
 
>> Stefan or any other involved in this thread,
>> 
>> Would you be able to provide the document number of the SC27 document 
>> so that people on the PKIX list may dig it more easily from their ISO NB ?
>> 
>> Additional question : when is the dead line for sending NB comments to SC 27 ?
>> 
>> Denis
>
>The current WD is
>	SC27N5134_3rdWD_18014-2_Jul2006.pdf

SC27N5134 is: Information technology -- Security techniques -- 
Digital signatures giving message recovery -- 
Part 2 : Integer factorization based mechanisms -- Amendment 1

It is not apparently the right document. Would you please provide the right number ?

Denis

>The deadline for comments is
>	30.9.2006 (tomorrow)
>
>anyhow, besides formal comments,
>i'd try to listen to informal comments too,
>and try to push for the best
>
>jam
>	
>
>

Regards,

Denis Pinkas

From: "Peter Rybar" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "=?UTF-8?Q?'=22Jos=C3=A9_A._Ma=C3=B1as=22'?=" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: New time stamping standard by ISO
Date: Fri, 29 Sep 2006 11:31:51 +0200
Sender: [email-masked]

Thanks Stefan,
I was afraid of inaccurate understanding of RFC 3161 from other discussions being sent about this problem.

Timestamp is CMS signature which can be inserted to another CMS signature as signed attribute (id-aa-ets-contentTimestamp) or as unsigned attribute (id-aa-signatureTimeStampToken, id-aa-ets-escTimeStamp, id-aa-ets-certCRLTimestamp, id-aa-ets-archiveTimestamp).
Timestamp according to RFC 3161 is not a countersignature and there was the misunderstanding!

If ISO plans to do that as a countersignature then it looks like as problem in implementations in some applications.
The countersignature is an unsigned attribute of the type SignerInfo which is included in the main SignerInfo and the countersignature signs hash of the signature (SignatureValue) within the main SignerInfo.
If new CMS attribute type will be defined then it will depend on its definition.  

Peter Rybar

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, September 28, 2006 4:19 PM
To: Peter Rybar; "JosÃ© A. MaÃ±as"; Stephen Kent
Cc: Russ Housley; [email-masked]
Subject: RE: New time stamping standard by ISO

Peter,

It appears to me that you are describing (and defending) the RFC 3161 time-stamp protocol, which we all agree are correct and which does not make the TSA a signer of the document.

The discussion here is that an ISO standard under development (ISO/IEC WD 18014-2.3) has expanded on the RFC 3161 time-stamping model, and offer an alternative where the TSTInfo is provided as a signed attribute of a SignerInfo amended to the original document, making the TSA signer of the document.

Did I misunderstand you?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: Peter Rybar [mailto:[email-masked]]
> Sent: den 28 september 2006 15:20
> To: Stefan Santesson; '"JosÃ© A. MaÃ±as"'; 'Stephen Kent'
> Cc: 'Russ Housley'; [email-masked]
> Subject: RE: New time stamping standard by ISO
> 
> 
> > the TSA becomes signer of the document without ever have seen it.
> 
> Timestamp is a simple automatic application, which signs binary
> document specified in RFC 3161 as TSTInfo and this binary TSTInfo
> document is included in CMS internal signature created by TSA.
> 
> First module: The timestamp application module which creates binary
> TSTInfo document can be stand-alone with trusted source of time.
> 
> Second module: The signing CMS module can have more then one HSM and it
> signs only some data like TSTInfo with specific requirement of CMS
> attributes:
> (
>   eContentType within SignedData is id-ct-TSTInfo
>   eContent within SignedData is TSTInfo
> 
>   signedAttrs within SignerInfo contain contentType (1 2 840 113549 1 9
> 3)
>        within OBJECT IDENTIFIER id-ct-TSTInfo(1 2 840 113549 1 9 16 1
> 4)
>   ...
> )
> 
> Binary TSTInfo document contains especially trusted connection between
> HASH in messageImprint and the trusted time in genTime. TSTInfo
> contains also another useful attributes like TSA Policy Id in the
> policy attribute.
> 
> It means that the timestamp is CMS signature which can be used as a
> proof that something from which  HASH was generated had been present
> before the time when the TSTInfo document was created and signed.
> 
> It can by used as  mentioned in RFC 3126:
>   id-aa-ets-contentTimestamp = The value of messageImprint field within
> TimeStampToken must be hash of the value of eContent field within
> encapContentInfo within the signedData.
> (HASH of the signed document which can be added during the signature as
> a proof that signed document has existed before the signing time)
> 
> Or it can be a id-aa-signatureTimeStampToken, id-aa-ets-escTimeStamp,
> id-aa-ets-certCRLTimestamp, id-aa-ets-archiveTimestamp.
> 
> Peter Rybar
> 
> 
> TSTInfo ::= SEQUENCE  {
>    version                      INTEGER  { v1(1) },
>    policy                       TSAPolicyId,
>    messageImprint               MessageImprint,
>      -- MUST have the same value as the similar field in
>      -- TimeStampReq
>    serialNumber                 INTEGER,
>     -- Time-Stamping users MUST be ready to accommodate integers
>     -- up to 160 bits.
>    genTime                      GeneralizedTime,
>    accuracy                     Accuracy                 OPTIONAL,
>    ordering                     BOOLEAN             DEFAULT FALSE,
>    nonce                        INTEGER                  OPTIONAL,
>      -- MUST be present if the similar field was present
>      -- in TimeStampReq.  In that case it MUST have the same value.
>    tsa                          [0] GeneralName          OPTIONAL,
>    extensions                   [1] IMPLICIT Extensions   OPTIONAL  }
> 
> 
> 
> [email-masked]] On Behalf Of Stefan Santesson
> Sent: Wednesday, September 27, 2006 5:42 PM
> To: "JosÃ© A. MaÃ±as"; Stephen Kent
> Cc: Russ Housley; [email-masked]
> Subject: RE: New time stamping standard by ISO
> 
> 
> You sign the document bits by encrypting the hash of the document in a
> signing context. So Yes, according to the CMS format (which defines the
> signing context for SignerInfos in SignedData), the TSA becomes signer
> of the document without ever have seen it.
> 
> I think that is bad design of a standard and the motivation for it
> still escapes me.
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > From: "JosÃ© A. MaÃ±as" [mailto:[email-masked]]
> > Sent: den 27 september 2006 08:08
> > To: Stephen Kent
> > Cc: Stefan Santesson; Russ Housley; [email-masked]
> > Subject: Re: New time stamping standard by ISO
> >
> > Stephen Kent wrote:
> > > Stefan,
> > >
> > > I too am not comfortable with a TSA signing a document, vs. signing
> a
> > > hash of a document, as a way to time stamp the data contained in
> the
> > > document.
> > >
> > > Steve
> > >
> >
> > the tsa is not signing any document bits, but only the hash of them
> >
> > however, I understand that technically (bits on the asn1 construct)
> > the signer info does not make any structural difference
> >
> > jam
> 
> 

Date: Fri, 29 Sep 2006 10:34:40 +0200
From: =?ISO-8859-1?Q?=22Jos=E9_A=2E_Ma=F1as=22?= <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

Denis Pinkas wrote:
> Stefan or any other involved in this thread,
> 
> Would you be able to provide the document number of the SC27 document 
> so that people on the PKIX list may dig it more easily from their ISO NB ?
> 
> Additional question : when is the dead line for sending NB comments to SC 27 ?
> 
> Denis

The current WD is
	SC27N5134_3rdWD_18014-2_Jul2006.pdf

The deadline for comments is
	30.9.2006 (tomorrow)

anyhow, besides formal comments,
i'd try to listen to informal comments too,
and try to push for the best

jam

Date: Fri, 29 Sep 2006 08:30:28 +0100
From: Stephen Farrell <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: "Hallam-Baker, Phillip" <[email-masked]>, Alan Sill <[email-masked]>, [email-masked]
Subject: Re: 3280bis  redefines HTTP
Sender: [email-masked]

S.

Date: Fri, 29 Sep 2006 09:04:18 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

Stefan or any other involved in this thread,

Would you be able to provide the document number of the SC27 document 
so that people on the PKIX list may dig it more easily from their ISO NB ?

Additional question : when is the dead line for sending NB comments to SC 27 ?

Denis

>Peter,
>
>You put the finger on the problem of this discussion, we don't have the draft because its secret.
>I personally have the draft but can't distribute it.
>
>I was rising the discussion here in order to hear the opinions from pkix "members" with the intent to forward them to ISO.
>
>However, ISO/IEC WD 18014-2.3 is pretty clear in the fact that the outcome of the so called "time-stamping signature" is a signature on the original message where the TSA is the signer. The concept of counter signing is not mentioned at all. The TSTInfo is provided as a signed attribute in a standard SignerInfo signing the original message.
>
>
>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
>> From: Peter Sylvester [mailto:[email-masked]]
>> Sent: den 28 september 2006 18:48
>> To: Stefan Santesson
>> Cc: Peter Rybar; "José A. Mañas"; Stephen Kent; Russ Housley; ietf-
>> [email-masked]
>> Subject: Re: New time stamping standard by ISO
>> 
>> I am not so sure.  I think the assumption is to use a countersignature.
>> 
>> What is the context of a countersignature. The input of the
>> countersignature is
>> the signature, and not the document that was signed, at least if my
>> reading of CMS is correct.:CMS does not say anything
>> about whether you should first validate a signature before creating a
>> countersignature
>> or else. A countersignature can simply be a confirmation that the
>> signer had
>> the right to sign.
>> 
>> A timestamp formatted as a countersignature goes indeed a little bit
>> further because
>> you would only give a hash.
>> 
>> Again, since I do not have the proposed text, I do not know how the
>> content data
>> of the TSTInfor would be replaced by signed attributes or so for
>> example.
>> 
>> Peter
>> 
>> 
>> Stefan Santesson wrote:
>> > Peter,
>> >
>> > It appears to me that you are describing (and defending) the RFC 3161
>> time-stamp protocol, which we all agree are correct and which does not
>> make the TSA a signer of the document.
>> >
>> > The discussion here is that an ISO standard under development
>> (ISO/IEC WD 18014-2.3) has expanded on the RFC 3161 time-stamping
>> model, and offer an alternative where the TSTInfo is provided as a
>> signed attribute of a SignerInfo amended to the original document,
>> making the TSA signer of the document.
>> >
>> > Did I misunderstand you?
>> >
>> >
>> > Stefan Santesson
>> > Senior Program Manager
>> > Windows Security, Standards
>> >
>> >
>> >> From: Peter Rybar [mailto:[email-masked]]
>> >> Sent: den 28 september 2006 15:20
>> >> To: Stefan Santesson; '"José A. Mañas"'; 'Stephen Kent'
>> >> Cc: 'Russ Housley'; [email-masked]
>> >> Subject: RE: New time stamping standard by ISO
>> >>
>> >>
>> >>
>> >>> the TSA becomes signer of the document without ever have seen it.
>> >>>
>> >> Timestamp is a simple automatic application, which signs binary
>> >> document specified in RFC 3161 as TSTInfo and this binary TSTInfo
>> >> document is included in CMS internal signature created by TSA.
>> >>
>> >> First module: The timestamp application module which creates binary
>> >> TSTInfo document can be stand-alone with trusted source of time.
>> >>
>> >> Second module: The signing CMS module can have more then one HSM and
>> it
>> >> signs only some data like TSTInfo with specific requirement of CMS
>> >> attributes:
>> >> (
>> >>   eContentType within SignedData is id-ct-TSTInfo
>> >>   eContent within SignedData is TSTInfo
>> >>
>> >>   signedAttrs within SignerInfo contain contentType (1 2 840 113549
>> 1 9
>> >> 3)
>> >>        within OBJECT IDENTIFIER id-ct-TSTInfo(1 2 840 113549 1 9 16
>> 1
>> >> 4)
>> >>   ...
>> >> )
>> >>
>> >> Binary TSTInfo document contains especially trusted connection
>> between
>> >> HASH in messageImprint and the trusted time in genTime. TSTInfo
>> >> contains also another useful attributes like TSA Policy Id in the
>> >> policy attribute.
>> >>
>> >> It means that the timestamp is CMS signature which can be used as a
>> >> proof that something from which  HASH was generated had been present
>> >> before the time when the TSTInfo document was created and signed.
>> >>
>> >> It can by used as  mentioned in RFC 3126:
>> >>   id-aa-ets-contentTimestamp = The value of messageImprint field
>> within
>> >> TimeStampToken must be hash of the value of eContent field within
>> >> encapContentInfo within the signedData.
>> >> (HASH of the signed document which can be added during the signature
>> as
>> >> a proof that signed document has existed before the signing time)
>> >>
>> >> Or it can be a id-aa-signatureTimeStampToken, id-aa-ets-
>> escTimeStamp,
>> >> id-aa-ets-certCRLTimestamp, id-aa-ets-archiveTimestamp.
>> >>
>> >> Peter Rybar
>> >>
>> >>
>> >> TSTInfo ::= SEQUENCE  {
>> >>    version                      INTEGER  { v1(1) },
>> >>    policy                       TSAPolicyId,
>> >>    messageImprint               MessageImprint,
>> >>      -- MUST have the same value as the similar field in
>> >>      -- TimeStampReq
>> >>    serialNumber                 INTEGER,
>> >>     -- Time-Stamping users MUST be ready to accommodate integers
>> >>     -- up to 160 bits.
>> >>    genTime                      GeneralizedTime,
>> >>    accuracy                     Accuracy                 OPTIONAL,
>> >>    ordering                     BOOLEAN             DEFAULT FALSE,
>> >>    nonce                        INTEGER                  OPTIONAL,
>> >>      -- MUST be present if the similar field was present
>> >>      -- in TimeStampReq.  In that case it MUST have the same value.
>> >>    tsa                          [0] GeneralName          OPTIONAL,
>> >>    extensions                   [1] IMPLICIT Extensions   OPTIONAL
>> }
>> >>
>> >>
>> >>
>> >> [email-masked]] On Behalf Of Stefan Santesson
>> >> Sent: Wednesday, September 27, 2006 5:42 PM
>> >> To: "José A. Mañas"; Stephen Kent
>> >> Cc: Russ Housley; [email-masked]
>> >> Subject: RE: New time stamping standard by ISO
>> >>
>> >>
>> >> You sign the document bits by encrypting the hash of the document in
>> a
>> >> signing context. So Yes, according to the CMS format (which defines
>> the
>> >> signing context for SignerInfos in SignedData), the TSA becomes
>> signer
>> >> of the document without ever have seen it.
>> >>
>> >> I think that is bad design of a standard and the motivation for it
>> >> still escapes me.
>> >>
>> >> Stefan Santesson
>> >> Senior Program Manager
>> >> Windows Security, Standards
>> >>
>> >>
>> >>> From: "José A. Mañas" [mailto:[email-masked]]
>> >>> Sent: den 27 september 2006 08:08
>> >>> To: Stephen Kent
>> >>> Cc: Stefan Santesson; Russ Housley; [email-masked]
>> >>> Subject: Re: New time stamping standard by ISO
>> >>>
>> >>> Stephen Kent wrote:
>> >>>
>> >>>> Stefan,
>> >>>>
>> >>>> I too am not comfortable with a TSA signing a document, vs.
>> signing
>> >>>>
>> >> a
>> >>
>> >>>> hash of a document, as a way to time stamp the data contained in
>> >>>>
>> >> the
>> >>
>> >>>> document.
>> >>>>
>> >>>> Steve
>> >>>>
>> >>>>
>> >>> the tsa is not signing any document bits, but only the hash of them
>> >>>
>> >>> however, I understand that technically (bits on the asn1 construct)
>> >>> the signer info does not make any structural difference
>> >>>
>> >>> jam
>> >>>
>> >>
>> >
>> >
>> >
>> >
>> >
>> 
>> 
>> --
>> 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: "Anders Rundgren" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "Alan Sill" <[email-masked]>, <[email-masked]>
Subject: Re: 3280bis  redefines HTTP
Date: Fri, 29 Sep 2006 07:13:05 +0200
Sender: [email-masked]

Alan,

regards
Anders

----- Original Message ----- 
From: "Alan Sill" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Cc: "Alan Sill" <[email-masked]>; "Anders Rundgren" <[email-masked]>; <[email-masked]>
Sent: Thursday, September 28, 2006 22:18
Subject: Re: 3280bis redefines HTTP

Phillip,

Alan

Alan Sill
TIGRE Senior Scientist

Date: Fri, 29 Sep 2006 06:46:29 +0200
From: =?UTF-8?B?Ikpvc8OpIEEuIE1hw7FhcyI=?= <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Peter Sylvester <[email-masked]>, Peter Rybar <[email-masked]>, Stephen Kent <[email-masked]>, Russ Housley <[email-masked]>, [email-masked]
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

Stefan Santesson wrote:

 > I do not agree with this analogy. IN the ISO approach, according to 
CMS, the TSA adds another time stamped signature to the document, indeed 
signing the document.
 > AdES, however only adds a time stamp.

sorry,
i think it is only poor wording of mine;
perhaps "analogy" is not the right way of speaking ...

in AdES you attach a tsa attribute to one signerinfo pack
(the attribute happens to be a cms-signeddata itself)

in ADES the aim is to qualify the signature

in iso a new signerinfo is attached to one cms pack;
therefore, the time-stamp becomes one more commitment
to the same contents
(that is, the tsa stating existence at some point of time)

jam

Content-class: urn:content-classes:message
Subject: Call for volunteers for a ECC subject public key info design team
Date: Fri, 29 Sep 2006 03:49:01 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6E371.D2E5DB1E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We have since quite some time had two diverse positions on how to
specify subject public key info for ECC public keys in X.509
certificates.

=20

On one hand the current proposal embracing the ANSI solution with a
structured subject public key info that has the capacity to specify
algorithm modes, and the RFC 4055 approach on the other hand using a
single OID to specify algorithm and parameters.

=20

As other groups are dependent on our progress on this issue, in
particular the Kerberos group, the Security ADs has requested us to form
a design team to prepare a decision for the WG.

=20

The design team shall;

=20

(1) be made up of no more than five people.

(2) interview (via the phone and/or e-mail) concerned parties.

(3) document the pros and cons of each proposal, and make a
recommendation to the WG.

=20

The authors of RFC 4055 and authors of draft-ietf-pkix-ecc-pkalgs should
be excluded from design team membership.

=20

The selected design team should be prepared to make their recommendation
at the PKIX meeting in San Diego (or before on the mail list, which
would be even better).  Then, the PKIX WG can have a straw poll to see
if the design team recommendation is accepted.  Of course, it needs to
be followed up by WG mail list confirmation.

=20

If you are interested to be part of this design team, please send me and
Steve Kent an e-mail no later than Friday next week (October 6). =20

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

------_=_NextPart_001_01C6E371.D2E5DB1E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

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

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

<div class=3DSection1>

<p class=3DMsoPlainText><span lang=3DEN-US>We have since quite some time =
had two
diverse positions on how to specify subject public key info for ECC =
public keys
in X.509 certificates.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US>On one hand the current =
proposal
embracing the ANSI solution with a structured subject public key info =
that has
the capacity to specify algorithm modes, and the RFC 4055 approach on =
the other
hand using a single OID to specify algorithm and =
parameters.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US>As other groups are dependent =
on our
progress on this issue, in particular the Kerberos group, the Security =
ADs has
requested us to form a design team to prepare a decision for the =
WG.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US>The design team =
shall;<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US>(1) be made up of no more =
than five
people.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US>(2) interview (via the phone =
and/or
e-mail) concerned parties.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US>(3) document the pros and =
cons of each
proposal, and make a recommendation to the WG.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US>The authors of RFC 4055 and =
authors of
draft-ietf-pkix-ecc-pkalgs should be excluded from design team =
membership.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US>The selected design team =
should be
prepared to make their recommendation at the PKIX meeting in San Diego =
(or
before on the mail list, which would be even better).&nbsp; Then, the =
PKIX WG
can have a straw poll to see if the design team recommendation is
accepted.&nbsp; Of course, it needs to be followed up by WG mail list
confirmation.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US>If you are interested to be =
part of this
design team, please send me and Steve Kent an e-mail no later than =
Friday next
week (October 6). &nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman","serif";color:navy'><o:p></o:p></span></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C6E371.D2E5DB1E--

Content-class: urn:content-classes:message
Subject: Call for agenda items for pkix at IETF-67
Date: Fri, 29 Sep 2006 03:12:49 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6E36C.C5F7F6A6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

=20

I'm requesting proposals on agenda items for IETF-67.

=20

All, lead editors of current pkix drafts are required to respond,
stating to what extent they whish to  present latest issues and progress
and how much time, if any, they need.

In addition to this I would like input on other presentations on
proposed new work and liaison presentations.

=20

I will need your input no later than end of next week, Friday October
6th, in order to post the agenda well in time for the next meeting.

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

------_=_NextPart_001_01C6E36C.C5F7F6A6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

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

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

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US>All,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I&#8217;m requesting proposals =
on agenda
items for IETF-67.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>All, lead editors of current =
pkix drafts
are required to respond, stating to what extent they whish to =
&nbsp;present latest
issues and progress and how much time, if any, they =
need.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>In addition to this I would like =
input on
other presentations on proposed new work and liaison =
presentations.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>I will need your input no later =
than end of
next week, Friday October 6<sup>th</sup>, in order to post the agenda =
well in
time for the next meeting.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span =
lang=3DEN-GB
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#400040'>Senior Program Manager</span><span lang=3DEN-GB =
style=3D'font-size:
12.0pt;font-family:"Times New =
Roman","serif";color:navy'><o:p></o:p></span></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C6E36C.C5F7F6A6--

Content-class: urn:content-classes:message
Subject: RE: New time stamping standard by ISO
Date: Fri, 29 Sep 2006 00:32:28 +0100
From: "Stefan Santesson" <[email-masked]>
To: =?utf-8?B?Ikpvc8OpIEEuIE1hw7FhcyI=?= <[email-masked]>, "Peter Sylvester" <[email-masked]>
Cc: "Peter Rybar" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> ISO merges both into a TS-SignerInfo attached to the subject CMS-
> SignedData;
> as is the case when you sign a paper, and the public administration
> adds a time-stamp to the same paper acknowledging receipt

I do not agree with this analogy. IN the ISO approach, according to CMS, the TSA adds another time stamped signature to the document, indeed signing the document.
AdES, however only adds a time stamp.

That does not make me a big fan of AdES, but it is the way it works.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: "JosÃ© A. MaÃ±as" [mailto:[email-masked]]
> Sent: den 28 september 2006 21:35
> To: Peter Sylvester
> Cc: Stefan Santesson; Peter Rybar; Stephen Kent; Russ Housley; ietf-
> [email-masked]
> Subject: Re: New time stamping standard by ISO
> 
> Peter Sylvester wrote:
> 
> > Ah, this looks like someone just wants to timestamp data and combine
> the
> > data and the timestamp, Since
> > CMS is a way to add envelopes. One could create a timestampedData for
> > example. I think
> > one reason is about what CMS types are actually supported in the
> wild.
> 
> a new cms type sounds as an overkill
> 
> 3161 produces a CMS-SignedData where the contents is the TSTInfo
> 
> AdES adds such a CMS thing as an unsigned attribute to another
> CMS-SignedData
> 
> ISO merges both into a TS-SignerInfo attached to the subject CMS-
> SignedData;
> as is the case when you sign a paper, and the public administration
> adds a time-stamp to the same paper acknowledging receipt
> 
> jam

Content-class: urn:content-classes:message
Subject: RE: 3280bis  redefines HTTP
Date: Thu, 28 Sep 2006 13:56:30 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Alan Sill" <[email-masked]>, "pkix" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>
Sender: [email-masked]

I still think that the need for a layered architecture approach should have trumped any ad-hoc optimizations for specific constraints.

The proper term to use in these cases is SHOULD.

MUST should be exclusively reserved for cases that are essential for interoperation and hence verifiable.

> Sent: Thursday, September 28, 2006 4:24 PM
> To: pkix
> Cc: Hallam-Baker, Phillip; Anders Rundgren; Alan Sill
> Pursuant to the original question, let me point  out the 
> following document conveying CA best practices for grids in 
> the form of an OGF
> document:
> 

Cc: Phillip Hallam-Baker <[email-masked]>, Anders Rundgren <[email-masked]>, Alan Sill <[email-masked]>
From: Alan Sill <[email-masked]>
Subject: Re: 3280bis  redefines HTTP
Date: Thu, 28 Sep 2006 15:24:21 -0500
To: pkix <[email-masked]>
Sender: [email-masked]

http://gridpma.org

Alan

Alan Sill
TIGRE Senior Scientist

Cc: Alan Sill <[email-masked]>, "Anders Rundgren" <[email-masked]>, <[email-masked]>
From: Alan Sill <[email-masked]>
Subject: Re: 3280bis  redefines HTTP
Date: Thu, 28 Sep 2006 15:18:35 -0500
To: "Hallam-Baker, Phillip" <[email-masked]>
Sender: [email-masked]

Phillip,

Alan

Alan Sill
TIGRE Senior Scientist

Date: Thu, 28 Sep 2006 21:35:45 +0200
From: =?UTF-8?B?Ikpvc8OpIEEuIE1hw7FhcyI=?= <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: Stefan Santesson <[email-masked]>, Peter Rybar <[email-masked]>, Stephen Kent <[email-masked]>, Russ Housley <[email-masked]>, [email-masked]
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

Peter Sylvester wrote:
> I am not so sure.  I think the assumption is to use a countersignature.

I do not think this is the intention of countersignatures.
If you sign B, I may countersign your signature.
Though the asn1 structure is quite similar,
the bits that go into the hashing are different ones.

The tsa could time-stamp the original contents,
or the signed content,
using the same structs;

as mentioned previously, the thing that makes the signature
a different kind of signature is not the structure,
but the signing policy of the tsa

and that lack of structural difference is the one that
makes stefan feel uneasy -- if i summarized correctly

> What is the context of a countersignature. The input of the 
> countersignature is
> the signature, and not the document that was signed, at least if my
> reading of CMS is correct.:CMS does not say anything
> about whether you should first validate a signature before creating a 
> countersignature
> or else. A countersignature can simply be a confirmation that the signer 
> had
> the right to sign.
> 
> A timestamp formatted as a countersignature goes indeed a little bit 
> further because
> you would only give a hash.

you might be interested on time-stamping a countersignature;
i see this as orthogonal to (signing | countersigning)

> Again, since I do not have the proposed text, I do not know how the 
> content data
> of the TSTInfor would be replaced by signed attributes or so for example.

it is a pity I cannot put forth the text;
but i may try to explain it shortly

according to cms way of doing things,
in order to produce a SignerInfo you do not need the contents,
only its hash;
if anybody provides the hash, you may sign it

sure it is dangerous to sign a hash without knowing what is after it,
UNLESS you state clearly that you are not agreeing to
the bulk contents of the document

i have seen may signatures attached to the same document,
where each signer has a specific role and liabilities;
for instance, in adobe, you may explicitly choose out of
a number of predefined reasons to sign
   - I attest to the accuracy and integrity of this document
   - I agree to the terms defined by the placement of
     my signature on this document
   - I am the author of this document
   - I have reviewed this document
   - I am approving this document
   - I agree to specified portions of this document

In commercial transactions, there are usually several signatures
   - the seller commits to deliver the specified product
   - the buyer commits to pay the specified price
   - a third party may provide an insurance to cover the transaction,
     without involving itself on delivering or paying
   - a tsa may involve herself as a proof of time
   - ...

so, as far as the relation of the signer to the contents is an
unforgeable statement, i am not nervous about

imho, of course,
jam

> Peter
> 
> 
> Stefan Santesson wrote:
>> Peter,
>>
>> It appears to me that you are describing (and defending) the RFC 3161 
>> time-stamp protocol, which we all agree are correct and which does not 
>> make the TSA a signer of the document.
>>
>> The discussion here is that an ISO standard under development (ISO/IEC 
>> WD 18014-2.3) has expanded on the RFC 3161 time-stamping model, and 
>> offer an alternative where the TSTInfo is provided as a signed 
>> attribute of a SignerInfo amended to the original document, making the 
>> TSA signer of the document.
>>
>> Did I misunderstand you?
>>
>>
>> Stefan Santesson
>> Senior Program Manager
>> Windows Security, Standards
>>
>>  
>>> From: Peter Rybar [mailto:[email-masked]]
>>> Sent: den 28 september 2006 15:20
>>> To: Stefan Santesson; '"JosÃ© A. MaÃ±as"'; 'Stephen Kent'
>>> Cc: 'Russ Housley'; [email-masked]
>>> Subject: RE: New time stamping standard by ISO
>>>
>>>
>>>    
>>>> the TSA becomes signer of the document without ever have seen it.
>>>>       
>>> Timestamp is a simple automatic application, which signs binary
>>> document specified in RFC 3161 as TSTInfo and this binary TSTInfo
>>> document is included in CMS internal signature created by TSA.
>>>
>>> First module: The timestamp application module which creates binary
>>> TSTInfo document can be stand-alone with trusted source of time.
>>>
>>> Second module: The signing CMS module can have more then one HSM and it
>>> signs only some data like TSTInfo with specific requirement of CMS
>>> attributes:
>>> (
>>>   eContentType within SignedData is id-ct-TSTInfo
>>>   eContent within SignedData is TSTInfo
>>>
>>>   signedAttrs within SignerInfo contain contentType (1 2 840 113549 1 9
>>> 3)
>>>        within OBJECT IDENTIFIER id-ct-TSTInfo(1 2 840 113549 1 9 16 1
>>> 4)
>>>   ...
>>> )
>>>
>>> Binary TSTInfo document contains especially trusted connection between
>>> HASH in messageImprint and the trusted time in genTime. TSTInfo
>>> contains also another useful attributes like TSA Policy Id in the
>>> policy attribute.
>>>
>>> It means that the timestamp is CMS signature which can be used as a
>>> proof that something from which  HASH was generated had been present
>>> before the time when the TSTInfo document was created and signed.
>>>
>>> It can by used as  mentioned in RFC 3126:
>>>   id-aa-ets-contentTimestamp = The value of messageImprint field within
>>> TimeStampToken must be hash of the value of eContent field within
>>> encapContentInfo within the signedData.
>>> (HASH of the signed document which can be added during the signature as
>>> a proof that signed document has existed before the signing time)
>>>
>>> Or it can be a id-aa-signatureTimeStampToken, id-aa-ets-escTimeStamp,
>>> id-aa-ets-certCRLTimestamp, id-aa-ets-archiveTimestamp.
>>>
>>> Peter Rybar
>>>
>>>
>>> TSTInfo ::= SEQUENCE  {
>>>    version                      INTEGER  { v1(1) },
>>>    policy                       TSAPolicyId,
>>>    messageImprint               MessageImprint,
>>>      -- MUST have the same value as the similar field in
>>>      -- TimeStampReq
>>>    serialNumber                 INTEGER,
>>>     -- Time-Stamping users MUST be ready to accommodate integers
>>>     -- up to 160 bits.
>>>    genTime                      GeneralizedTime,
>>>    accuracy                     Accuracy                 OPTIONAL,
>>>    ordering                     BOOLEAN             DEFAULT FALSE,
>>>    nonce                        INTEGER                  OPTIONAL,
>>>      -- MUST be present if the similar field was present
>>>      -- in TimeStampReq.  In that case it MUST have the same value.
>>>    tsa                          [0] GeneralName          OPTIONAL,
>>>    extensions                   [1] IMPLICIT Extensions   OPTIONAL  }
>>>
>>>
>>>
>>> [email-masked]] On Behalf Of Stefan Santesson
>>> Sent: Wednesday, September 27, 2006 5:42 PM
>>> To: "JosÃ© A. MaÃ±as"; Stephen Kent
>>> Cc: Russ Housley; [email-masked]
>>> Subject: RE: New time stamping standard by ISO
>>>
>>>
>>> You sign the document bits by encrypting the hash of the document in a
>>> signing context. So Yes, according to the CMS format (which defines the
>>> signing context for SignerInfos in SignedData), the TSA becomes signer
>>> of the document without ever have seen it.
>>>
>>> I think that is bad design of a standard and the motivation for it
>>> still escapes me.
>>>
>>> Stefan Santesson
>>> Senior Program Manager
>>> Windows Security, Standards
>>>
>>>    
>>>> From: "JosÃ© A. MaÃ±as" [mailto:[email-masked]]
>>>> Sent: den 27 september 2006 08:08
>>>> To: Stephen Kent
>>>> Cc: Stefan Santesson; Russ Housley; [email-masked]
>>>> Subject: Re: New time stamping standard by ISO
>>>>
>>>> Stephen Kent wrote:
>>>>      
>>>>> Stefan,
>>>>>
>>>>> I too am not comfortable with a TSA signing a document, vs. signing
>>>>>         
>>> a
>>>    
>>>>> hash of a document, as a way to time stamp the data contained in
>>>>>         
>>> the
>>>    
>>>>> document.
>>>>>
>>>>> Steve
>>>>>
>>>>>         
>>>> the tsa is not signing any document bits, but only the hash of them
>>>>
>>>> however, I understand that technically (bits on the asn1 construct)
>>>> the signer info does not make any structural difference
>>>>
>>>> jam
>>>>       
>>>     
>>
>>
>>
>>
>>   
> 
> 

Date: Thu, 28 Sep 2006 21:34:34 +0200
From: =?UTF-8?B?Ikpvc8OpIEEuIE1hw7FhcyI=?= <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: Stefan Santesson <[email-masked]>, Peter Rybar <[email-masked]>, Stephen Kent <[email-masked]>, Russ Housley <[email-masked]>, [email-masked]
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

Peter Sylvester wrote:

> Ah, this looks like someone just wants to timestamp data and combine the 
> data and the timestamp, Since
> CMS is a way to add envelopes. One could create a timestampedData for 
> example. I think
> one reason is about what CMS types are actually supported in the wild.

a new cms type sounds as an overkill

3161 produces a CMS-SignedData where the contents is the TSTInfo

AdES adds such a CMS thing as an unsigned attribute to another
CMS-SignedData

ISO merges both into a TS-SignerInfo attached to the subject CMS-SignedData;
as is the case when you sign a paper, and the public administration
adds a time-stamp to the same paper acknowledging receipt

jam

Content-class: urn:content-classes:message
Subject: RE: 3280bis  redefines HTTP
Date: Thu, 28 Sep 2006 12:14:06 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Alan Sill" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> High Performance Computing Center

Cc: Alan Sill <[email-masked]>, "Anders Rundgren" <[email-masked]>, <[email-masked]>
From: Alan Sill <[email-masked]>
Subject: Re: 3280bis  redefines HTTP
Date: Thu, 28 Sep 2006 14:03:14 -0500
To: "Hallam-Baker, Phillip" <[email-masked]>
Sender: [email-masked]

The purpose of this is to prevent CRL's from being logical URIs, but  
instead actually to be physical entities on a disk.  I do not know  
the origin of this restriction, which has cause a certain amount of  
questioning in my community (grids), but I can say that one does NOT  
want to implement CRLs via time-consuming mechanisms in general, and  
in particular tomcat servlets (although I am a fan of Tomcat in other  
circumstances) would be a very bad way to implement a CRL.

In any substantial deployment, as hinted here, it is crucial to have  
a CRL responder that is very fast indeed.  Most CRL servers used in  
academic grids already run at several hundred hits per second, and  
the rate is going up.  This is driving research on credential  
validation methods that do not use CRLs as intensively.  For now, you  
should NOT read the RFC as a mistake, but as a requirement.  At  
minimum, to meet this requirement, your CRL identifier must be fully  
specified, i.e.,

and not

Alan

On Sep 28, 2006, at 12:18 PM, Hallam-Baker, Phillip wrote:

> mean a resource stored on disk. It worried some people in the  
> context of http and they started using the term resource.
>
> The more troubling issue is the use of the file extension rather  
> than the mime content type. This is likely to cause problems in  
> quite a few deployments. It is clearly an error, it might be a  
> mistake.
>
>
> there SHOULD be an HTTP uri and that FTP and LDAP SHOULD NOT be  
> used. Mandating HTTP is likely to be a problem down the road when  
> we have something better. Its not a major concern unless someone  
> thought it was OK to write code that would actually break if it saw  
> a non HTTP URI.
>
> contains an interpretation of HTTP which is quite unique:
>
>
>    Where the information is available via HTTP or FTP, accessLocation
>    DER encoded certificate (indicated by the .cer file extension) or a
>    collection of certificates (indicated by the .p7c file extension):
>
>
>
> (.html), a file extension which as no meaning for a client (.asp),  
> or  having no extensions at all.  If the underlaying object is a  
> "file" or not is totally ireelvant.  In fact, the depencdy on file  
> extension for HTTP URIs complicates deployment if you want to use a  
> Servlet or similar rather than a file.  The Apache web-server  
> publishing certficates in an LDAP directory.  If you want to  
> provide HTTP access as well, a trivial way would be to wrap a  
> suitable LDAP call in a JSP page or .NET appication. Such  
> applications do normally not use file extensions except ..jsp and  
> aspx.  http://example.com/respository/certs.aspx?id=455 works just   
> fine.
>
>> I simply asked you to lower the bar for clients in order to  
>> improve interoperability.
> extension defined a new data item and Stefan, as the author, chose  
> a particular method of making them accessible. Nobody argued for  
> other access methods at the time this was proposed, so ...
>
> An established practice that is not the product of an IETF WG can  
> be documented via an informational RFC written by the folks who  
> established the practice. Including comments about such practices  
> in a standards track RFC obscures the distinction.
>
>>  Since a CA is usually server you can put higher requirements on a  
>> CA than on clients, there seems to be a reasonable compromise:
>
> CAs are not servers acting as repositories. While a CA may choose  
> to operate a repository for the certs and CRLs is issues, prudent  
> what you meant to say above was that IF a CA operates a repository  
> for such data, then it is likely to be a highly available machine.
>
>> There isn't a "certificate-user" (it is a program) that can't  
>> handle at least one of these.  Often both.
>>
>> caIssuers access method"

Alan Sill
TIGRE Senior Scientist

Date: Thu, 28 Sep 2006 19:47:33 +0200
From: Peter Sylvester <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Peter Rybar <[email-masked]>, =?UTF-8?B?Ikpvc8OpIEEuIE1hw7FhcyI=?= <[email-masked]>, Stephen Kent <[email-masked]>, Russ Housley <[email-masked]>, [email-masked]
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090905000309040000050404
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Stefan Santesson wrote:
> Peter,
>
> You put the finger on the problem of this discussion, we don't have the draft because its secret.
> I personally have the draft but can't distribute it.
>
> I was rising the discussion here in order to hear the opinions from pkix "members" with the intent to forward them to ISO.
>   
I think that an open discussion would be useful.
> However, ISO/IEC WD 18014-2.3 is pretty clear in the fact that the outcome of the so called "time-stamping signature" is a signature on the original message where the TSA is the signer. The concept of counter signing is not mentioned at all. The TSTInfo is provided as a signed attribute in a standard SignerInfo signing the original message.
>   
Ah, this looks like someone just wants to timestamp data and combine the 
data and the timestamp, Since
CMS is a way to add envelopes. One could create a timestampedData for 
example. I think
one reason is about what CMS types are actually supported in the wild.
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>   
>> From: Peter Sylvester [mailto:[email-masked]]
>> Sent: den 28 september 2006 18:48
>> To: Stefan Santesson
>> Cc: Peter Rybar; "JosÃ© A. MaÃ±as"; Stephen Kent; Russ Housley; ietf-
>> [email-masked]
>> Subject: Re: New time stamping standard by ISO
>>
>> I am not so sure.  I think the assumption is to use a countersignature.
>>
>> What is the context of a countersignature. The input of the
>> countersignature is
>> the signature, and not the document that was signed, at least if my
>> reading of CMS is correct.:CMS does not say anything
>> about whether you should first validate a signature before creating a
>> countersignature
>> or else. A countersignature can simply be a confirmation that the
>> signer had
>> the right to sign.
>>
>> A timestamp formatted as a countersignature goes indeed a little bit
>> further because
>> you would only give a hash.
>>
>> Again, since I do not have the proposed text, I do not know how the
>> content data
>> of the TSTInfor would be replaced by signed attributes or so for
>> example.
>>
>> Peter
>>
>>
>> Stefan Santesson wrote:
>>     
>>> Peter,
>>>
>>> It appears to me that you are describing (and defending) the RFC 3161
>>>       
>> time-stamp protocol, which we all agree are correct and which does not
>> make the TSA a signer of the document.
>>     
>>> The discussion here is that an ISO standard under development
>>>       
>> (ISO/IEC WD 18014-2.3) has expanded on the RFC 3161 time-stamping
>> model, and offer an alternative where the TSTInfo is provided as a
>> signed attribute of a SignerInfo amended to the original document,
>> making the TSA signer of the document.
>>     
>>> Did I misunderstand you?
>>>
>>>
>>> Stefan Santesson
>>> Senior Program Manager
>>> Windows Security, Standards
>>>
>>>
>>>       
>>>> From: Peter Rybar [mailto:[email-masked]]
>>>> Sent: den 28 september 2006 15:20
>>>> To: Stefan Santesson; '"JosÃ© A. MaÃ±as"'; 'Stephen Kent'
>>>> Cc: 'Russ Housley'; [email-masked]
>>>> Subject: RE: New time stamping standard by ISO
>>>>
>>>>
>>>>
>>>>         
>>>>> the TSA becomes signer of the document without ever have seen it.
>>>>>
>>>>>           
>>>> Timestamp is a simple automatic application, which signs binary
>>>> document specified in RFC 3161 as TSTInfo and this binary TSTInfo
>>>> document is included in CMS internal signature created by TSA.
>>>>
>>>> First module: The timestamp application module which creates binary
>>>> TSTInfo document can be stand-alone with trusted source of time.
>>>>
>>>> Second module: The signing CMS module can have more then one HSM and
>>>>         
>> it
>>     
>>>> signs only some data like TSTInfo with specific requirement of CMS
>>>> attributes:
>>>> (
>>>>   eContentType within SignedData is id-ct-TSTInfo
>>>>   eContent within SignedData is TSTInfo
>>>>
>>>>   signedAttrs within SignerInfo contain contentType (1 2 840 113549
>>>>         
>> 1 9
>>     
>>>> 3)
>>>>        within OBJECT IDENTIFIER id-ct-TSTInfo(1 2 840 113549 1 9 16
>>>>         
>> 1
>>     
>>>> 4)
>>>>   ...
>>>> )
>>>>
>>>> Binary TSTInfo document contains especially trusted connection
>>>>         
>> between
>>     
>>>> HASH in messageImprint and the trusted time in genTime. TSTInfo
>>>> contains also another useful attributes like TSA Policy Id in the
>>>> policy attribute.
>>>>
>>>> It means that the timestamp is CMS signature which can be used as a
>>>> proof that something from which  HASH was generated had been present
>>>> before the time when the TSTInfo document was created and signed.
>>>>
>>>> It can by used as  mentioned in RFC 3126:
>>>>   id-aa-ets-contentTimestamp = The value of messageImprint field
>>>>         
>> within
>>     
>>>> TimeStampToken must be hash of the value of eContent field within
>>>> encapContentInfo within the signedData.
>>>> (HASH of the signed document which can be added during the signature
>>>>         
>> as
>>     
>>>> a proof that signed document has existed before the signing time)
>>>>
>>>> Or it can be a id-aa-signatureTimeStampToken, id-aa-ets-
>>>>         
>> escTimeStamp,
>>     
>>>> id-aa-ets-certCRLTimestamp, id-aa-ets-archiveTimestamp.
>>>>
>>>> Peter Rybar
>>>>
>>>>
>>>> TSTInfo ::= SEQUENCE  {
>>>>    version                      INTEGER  { v1(1) },
>>>>    policy                       TSAPolicyId,
>>>>    messageImprint               MessageImprint,
>>>>      -- MUST have the same value as the similar field in
>>>>      -- TimeStampReq
>>>>    serialNumber                 INTEGER,
>>>>     -- Time-Stamping users MUST be ready to accommodate integers
>>>>     -- up to 160 bits.
>>>>    genTime                      GeneralizedTime,
>>>>    accuracy                     Accuracy                 OPTIONAL,
>>>>    ordering                     BOOLEAN             DEFAULT FALSE,
>>>>    nonce                        INTEGER                  OPTIONAL,
>>>>      -- MUST be present if the similar field was present
>>>>      -- in TimeStampReq.  In that case it MUST have the same value.
>>>>    tsa                          [0] GeneralName          OPTIONAL,
>>>>    extensions                   [1] IMPLICIT Extensions   OPTIONAL
>>>>         
>> }
>>     
>>>>
>>>> [email-masked]] On Behalf Of Stefan Santesson
>>>> Sent: Wednesday, September 27, 2006 5:42 PM
>>>> To: "JosÃ© A. MaÃ±as"; Stephen Kent
>>>> Cc: Russ Housley; [email-masked]
>>>> Subject: RE: New time stamping standard by ISO
>>>>
>>>>
>>>> You sign the document bits by encrypting the hash of the document in
>>>>         
>> a
>>     
>>>> signing context. So Yes, according to the CMS format (which defines
>>>>         
>> the
>>     
>>>> signing context for SignerInfos in SignedData), the TSA becomes
>>>>         
>> signer
>>     
>>>> of the document without ever have seen it.
>>>>
>>>> I think that is bad design of a standard and the motivation for it
>>>> still escapes me.
>>>>
>>>> Stefan Santesson
>>>> Senior Program Manager
>>>> Windows Security, Standards
>>>>
>>>>
>>>>         
>>>>> From: "JosÃ© A. MaÃ±as" [mailto:[email-masked]]
>>>>> Sent: den 27 september 2006 08:08
>>>>> To: Stephen Kent
>>>>> Cc: Stefan Santesson; Russ Housley; [email-masked]
>>>>> Subject: Re: New time stamping standard by ISO
>>>>>
>>>>> Stephen Kent wrote:
>>>>>
>>>>>           
>>>>>> Stefan,
>>>>>>
>>>>>> I too am not comfortable with a TSA signing a document, vs.
>>>>>>             
>> signing
>>     
>>>> a
>>>>
>>>>         
>>>>>> hash of a document, as a way to time stamp the data contained in
>>>>>>
>>>>>>             
>>>> the
>>>>
>>>>         
>>>>>> document.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>>
>>>>>>             
>>>>> the tsa is not signing any document bits, but only the hash of them
>>>>>
>>>>> however, I understand that technically (bits on the asn1 construct)
>>>>> the signer info does not make any structural difference
>>>>>
>>>>> jam
>>>>>
>>>>>           
>>>
>>>
>>>
>>>       
>> --
>> 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.
>>     
>
>
>
>
>   

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

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

--------------ms090905000309040000050404--

Date: Thu, 28 Sep 2006 18:48:22 +0200
From: Peter Sylvester <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Peter Rybar <[email-masked]>, =?UTF-8?B?Ikpvc8OpIEEuIE1hw7FhcyI=?= <[email-masked]>, Stephen Kent <[email-masked]>, Russ Housley <[email-masked]>, [email-masked]
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060207000202040501000302
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I am not so sure.  I think the assumption is to use a countersignature.

What is the context of a countersignature. The input of the 
countersignature is
the signature, and not the document that was signed, at least if my
reading of CMS is correct.:CMS does not say anything
about whether you should first validate a signature before creating a 
countersignature
or else. A countersignature can simply be a confirmation that the signer had
the right to sign.

A timestamp formatted as a countersignature goes indeed a little bit 
further because
you would only give a hash.

Again, since I do not have the proposed text, I do not know how the 
content data
of the TSTInfor would be replaced by signed attributes or so for example.

Peter

Stefan Santesson wrote:
> Peter,
>
> It appears to me that you are describing (and defending) the RFC 3161 time-stamp protocol, which we all agree are correct and which does not make the TSA a signer of the document.
>
> The discussion here is that an ISO standard under development (ISO/IEC WD 18014-2.3) has expanded on the RFC 3161 time-stamping model, and offer an alternative where the TSTInfo is provided as a signed attribute of a SignerInfo amended to the original document, making the TSA signer of the document.
>
> Did I misunderstand you?
>
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
>   
>> From: Peter Rybar [mailto:[email-masked]]
>> Sent: den 28 september 2006 15:20
>> To: Stefan Santesson; '"JosÃ© A. MaÃ±as"'; 'Stephen Kent'
>> Cc: 'Russ Housley'; [email-masked]
>> Subject: RE: New time stamping standard by ISO
>>
>>
>>     
>>> the TSA becomes signer of the document without ever have seen it.
>>>       
>> Timestamp is a simple automatic application, which signs binary
>> document specified in RFC 3161 as TSTInfo and this binary TSTInfo
>> document is included in CMS internal signature created by TSA.
>>
>> First module: The timestamp application module which creates binary
>> TSTInfo document can be stand-alone with trusted source of time.
>>
>> Second module: The signing CMS module can have more then one HSM and it
>> signs only some data like TSTInfo with specific requirement of CMS
>> attributes:
>> (
>>   eContentType within SignedData is id-ct-TSTInfo
>>   eContent within SignedData is TSTInfo
>>
>>   signedAttrs within SignerInfo contain contentType (1 2 840 113549 1 9
>> 3)
>>        within OBJECT IDENTIFIER id-ct-TSTInfo(1 2 840 113549 1 9 16 1
>> 4)
>>   ...
>> )
>>
>> Binary TSTInfo document contains especially trusted connection between
>> HASH in messageImprint and the trusted time in genTime. TSTInfo
>> contains also another useful attributes like TSA Policy Id in the
>> policy attribute.
>>
>> It means that the timestamp is CMS signature which can be used as a
>> proof that something from which  HASH was generated had been present
>> before the time when the TSTInfo document was created and signed.
>>
>> It can by used as  mentioned in RFC 3126:
>>   id-aa-ets-contentTimestamp = The value of messageImprint field within
>> TimeStampToken must be hash of the value of eContent field within
>> encapContentInfo within the signedData.
>> (HASH of the signed document which can be added during the signature as
>> a proof that signed document has existed before the signing time)
>>
>> Or it can be a id-aa-signatureTimeStampToken, id-aa-ets-escTimeStamp,
>> id-aa-ets-certCRLTimestamp, id-aa-ets-archiveTimestamp.
>>
>> Peter Rybar
>>
>>
>> TSTInfo ::= SEQUENCE  {
>>    version                      INTEGER  { v1(1) },
>>    policy                       TSAPolicyId,
>>    messageImprint               MessageImprint,
>>      -- MUST have the same value as the similar field in
>>      -- TimeStampReq
>>    serialNumber                 INTEGER,
>>     -- Time-Stamping users MUST be ready to accommodate integers
>>     -- up to 160 bits.
>>    genTime                      GeneralizedTime,
>>    accuracy                     Accuracy                 OPTIONAL,
>>    ordering                     BOOLEAN             DEFAULT FALSE,
>>    nonce                        INTEGER                  OPTIONAL,
>>      -- MUST be present if the similar field was present
>>      -- in TimeStampReq.  In that case it MUST have the same value.
>>    tsa                          [0] GeneralName          OPTIONAL,
>>    extensions                   [1] IMPLICIT Extensions   OPTIONAL  }
>>
>>
>>
>> [email-masked]] On Behalf Of Stefan Santesson
>> Sent: Wednesday, September 27, 2006 5:42 PM
>> To: "JosÃ© A. MaÃ±as"; Stephen Kent
>> Cc: Russ Housley; [email-masked]
>> Subject: RE: New time stamping standard by ISO
>>
>>
>> You sign the document bits by encrypting the hash of the document in a
>> signing context. So Yes, according to the CMS format (which defines the
>> signing context for SignerInfos in SignedData), the TSA becomes signer
>> of the document without ever have seen it.
>>
>> I think that is bad design of a standard and the motivation for it
>> still escapes me.
>>
>> Stefan Santesson
>> Senior Program Manager
>> Windows Security, Standards
>>
>>     
>>> From: "JosÃ© A. MaÃ±as" [mailto:[email-masked]]
>>> Sent: den 27 september 2006 08:08
>>> To: Stephen Kent
>>> Cc: Stefan Santesson; Russ Housley; [email-masked]
>>> Subject: Re: New time stamping standard by ISO
>>>
>>> Stephen Kent wrote:
>>>       
>>>> Stefan,
>>>>
>>>> I too am not comfortable with a TSA signing a document, vs. signing
>>>>         
>> a
>>     
>>>> hash of a document, as a way to time stamp the data contained in
>>>>         
>> the
>>     
>>>> document.
>>>>
>>>> Steve
>>>>
>>>>         
>>> the tsa is not signing any document bits, but only the hash of them
>>>
>>> however, I understand that technically (bits on the asn1 construct)
>>> the signer info does not make any structural difference
>>>
>>> jam
>>>       
>>     
>
>
>
>
>   

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

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

--------------ms060207000202040501000302--

Content-class: urn:content-classes:message
Subject: RE: 3280bis  redefines HTTP
Date: Thu, 28 Sep 2006 10:18:55 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6E322.02FD19A5
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

There is a minor problem here and a significant error.
=20
The minor problem is the use of the term 'file' in place of 'resource'. =
Since a file is merely an abstraction for a bag of bits this does not =
worry me very much. Some people assume that file must mean a resource =
stored on disk. It worried some people in the context of http and they =
started using the term resource.
=20
The more troubling issue is the use of the file extension rather than =
the mime content type. This is likely to cause problems in quite a few =
deployments. It is clearly an error, it might be a mistake.
=20
=20
On the wording for logotypes I would be happier with stating that there =
SHOULD be an HTTP uri and that FTP and LDAP SHOULD NOT be used. =
Mandating HTTP is likely to be a problem down the road when we have =
something better. Its not a major concern unless someone thought it was =
OK to write code that would actually break if it saw a non HTTP URI.
=20
Prohibiting LDAP and FTP does make good sense, they are both less =
efficient than HTTP. FTP is much less efficient and less reliable =
through NAT.

________________________________

	From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Anders Rundgren
	Sent: Wednesday, September 27, 2006 2:50 PM
	To: [email-masked]
	Subject: 3280bis redefines HTTP
=09
=09
	Talking about standards, the following extract from 3280bis contains an =
interpretation of HTTP which is quite unique:
	=20
	=20
	   Where the information is available via HTTP or FTP, accessLocation =20
	   MUST be a uniformResourceIdentifier and the URI MUST point to a =
certificate file.=20
	   The certificate file MUST contain either a single
	   DER encoded certificate (indicated by the .cer file extension) or a
	   collection of certificates (indicated by the .p7c file extension):
	=20
	=20
	=20
	Outside of 3280bis, HTTP UIRs like
	=20
	http://example.com/index.html
	http://example.com/index.asp
	http://example.com/home
	http://example.com/library?id=3D2
	=20
	work flawlessly in spite of either using a real file extension (.html), =
a file extension which as no meaning for a client (.asp), or  having no =
extensions at all.  If the underlaying object is a "file" or not is =
totally ireelvant.  In fact, the depencdy on file extension for HTTP =
URIs complicates deployment if you want to use a Servlet or similar =
rather than a file.  The Apache web-server requires a change in the MIME =
master table in order to do this.  But such a change affects static =
contents and is therefore highly impopular.  MIME-types represent the =
established way of associating HTTP objects with consuming applications.
	=20
	Putting this in a typical CA context it is probably a good idea =
publishing certficates in an LDAP directory.  If you want to provide =
HTTP access as well, a trivial way would be to wrap a suitable LDAP call =
in a JSP page or .NET appication. Such applications do normally not use =
file extensions except ..jsp and aspx.  =
http://example.com/respository/certs.aspx?id=3D455 works just  fine.
	=20
	Using FTP, you indeed need to bother about file-names, but FTP is =
another protocol, not to be confused with HTTP.  Since LDAP got its own =
wording, you might do the same with HTTP.
	=20
	Anders
	=20
	=20
	----- Original Message -----=20
	From: Stephen Kent <mailto:[email-masked]> =20
	To: Anders Rundgren <mailto:[email-masked]> =20
	Cc: Sharon Boeyen <mailto:[email-masked]>  ; 'Stefan =
Santesson' <mailto:[email-masked]>  ; [email-masked]=20
	Sent: Wednesday, September 27, 2006 00:04
	Subject: Re: 3280bis AIA RFC2585 and RFC2797 deviations

		Sharon & Stefan,

		I did not write that AIA -aIssuers should be mandatory, or even be =
recommended.

		=20

		I simply asked you to lower the bar for clients in order to improve =
interoperability.

		Since the CA defines this property unilaterally, it is kind of =
critical that it is usable.

		=20

		I noted that in the Logotypes RFC, HTTP is a MUST.  In what aspect are =
certificates files different from image files with respect to access?  =
IMO, not at all.=20

	certs are nominally available via a wide range of ways, which are under =
the control of CAs and others who choose to operate repositories. The =
AIA and SIA extensions allow specification of various access methods to =
accommodate such diversity. The logotypes extension defined a new data =
item and Stefan, as the author, chose a particular method of making them =
accessible. Nobody argued for other access methods at the time this was =
proposed, so ...

		 Regarding "alien" file-extensions and MIME-types: I believe it is =
prudent documenting established practices rather than hoping that nobody =
will notice the glitches that will result by ignoring them.

	An established practice that is not the product of an IETF WG can be =
documented via an informational RFC written by the folks who established =
the practice. Including comments about such practices in a standards =
track RFC obscures the distinction.

		 Since a CA is usually server you can put higher requirements on a CA =
than on clients, there seems to be a reasonable compromise:

	CAs are not servers acting as repositories. While a CA may choose to =
operate a repository for the certs and CRLs is issues, prudent security =
practice often calls for a machine signing certs to not be directly =
accessible in the same fashion as a repository.  So maybe what you meant =
to say above was that IF a CA operates a repository for such data, then =
it is likely to be a highly available machine.

		HTTP and LDAP could be RECOMMENDED for AIA-caIssuers-using CAs.  There =
isn't a "certificate-user" (it is a program) that can't handle at least =
one of these.  Often both.

		=20

		http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf =
<http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf>=20

		"AIA extensions include both LDAP and HTTP URIs for id-ad-caIssuers =
access method"

		=20

=09
=09
	This is a U.S. Government PKI profile, but that does not make it a =
global standard of the sort we develop in the IETF.

	Steve

------_=_NextPart_001_01C6E322.02FD19A5
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><TITLE>Re: 3280bis AIA RFC2585 and RFC2797 =
deviations</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.2873" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D263330117-28092006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>There is a minor problem here and a significant =

error.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D263330117-28092006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D263330117-28092006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>The minor problem is the use of the term 'file' =
in place of=20
'resource'. Since a file is merely an abstraction for a bag of bits this =
does=20
not worry me very much. Some people assume that file must mean a =
resource stored=20
on disk. It worried some people in the context of http and they started =
using=20
the term resource.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D263330117-28092006>The=20
more troubling issue is the use of the file extension rather than the =
mime=20
content type. This is likely to cause problems in quite a few =
deployments. It is=20
clearly an error, it might be a&nbsp;mistake.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D263330117-28092006><FONT face=3DArial color=3D#0000ff =
size=3D2>On the=20
wording for logotypes I would be happier with stating that there SHOULD =
be an=20
HTTP uri and that FTP and LDAP SHOULD NOT be used. Mandating HTTP is =
likely to=20
be a problem down the road when we have something better. Its not a =
major=20
concern unless someone thought it was OK to write code that would =
actually break=20
if it saw a non HTTP URI.</FONT></SPAN></DIV>
<DIV><SPAN class=3D263330117-28092006><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D263330117-28092006><FONT face=3DArial color=3D#0000ff =

size=3D2>Prohibiting LDAP and FTP does make good sense, they are both =
less=20
efficient than HTTP. FTP is much less efficient and less reliable =
through=20
NAT.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><BR></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =

  [mailto:[email-masked]] <B>On Behalf Of </B>Anders=20
  Rundgren<BR><B>Sent:</B> Wednesday, September 27, 2006 2:50 =
PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> 3280bis redefines=20
  HTTP<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial size=3D2>Talking about standards, the =
following extract=20
  from 3280bis contains an interpretation of HTTP which is quite=20
  unique:</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; Where the information is =
available=20
  via HTTP or FTP, accessLocation&nbsp;&nbsp;</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; MUST be a =
uniformResourceIdentifier=20
  and the URI MUST point to a certificate <EM><FONT=20
  color=3D#ff0000>file</FONT></EM>.&nbsp;</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; The certificate file =
MUST contain=20
  either a single<BR>&nbsp;&nbsp; DER encoded certificate (indicated by =
the .cer=20
  file extension) or a<BR>&nbsp;&nbsp; collection of certificates =
(indicated by=20
  the .p7c file extension):</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Outside of 3280bis, HTTP UIRs =
like</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><A=20
  =
href=3D"http://example.com/index.html">http://example.com/index.html</A><=
/FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><A=20
  =
href=3D"http://example.com/index.asp">http://example.com/index.asp</A></F=
ONT></DIV>
  <DIV><FONT face=3DArial size=3D2><A=20
  =
href=3D"http://example.com/home">http://example.com/home</A></FONT></DIV>=

  <DIV><FONT face=3DArial size=3D2><A=20
  =
href=3D"http://example.com/library?id=3D2">http://example.com/library?id=3D=
2</A></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>work flawlessly in spite of either =
using a real=20
  file extension (.html), a file&nbsp;extension which as no =
meaning&nbsp;for=20
  a&nbsp;client (.asp),&nbsp;or&nbsp; having no extensions at all.&nbsp; =
<EM>If=20
  the underlaying object is a "file" or not is totally =
ireelvant.</EM>&nbsp; In=20
  fact, the depencdy on file extension for HTTP URIs complicates =
deployment if=20
  you want to use a Servlet or similar rather than a file.&nbsp; The =
Apache=20
  web-server requires a change in the MIME master table in order to do=20
  this.&nbsp; But such a change affects static contents and is therefore =
highly=20
  impopular.&nbsp; MIME-types&nbsp;represent the established way of =
associating=20
  HTTP objects&nbsp;with consuming applications.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Putting this in a typical CA context =
it is=20
  probably a&nbsp;good idea publishing certficates in an LDAP =
directory.&nbsp;=20
  If you want to provide HTTP access as well, a trivial way would be to =
wrap a=20
  suitable LDAP call in a JSP page or .NET appication. Such applications =
do=20
  normally not use file extensions except ..jsp and aspx.&nbsp; <A=20
  =
href=3D"http://example.com/respository/certs.aspx?id=3D455">http://exampl=
e.com/respository/certs.aspx?id=3D455</A></FONT><FONT=20
  face=3DArial size=3D2>&nbsp;works just &nbsp;fine.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Using FTP, you indeed need to bother=20
  about&nbsp;file-names, but FTP is <EM>another</EM> protocol, <EM>not =
to be=20
  confused with HTTP</EM>.&nbsp; Since LDAP got its own wording, you =
might do=20
  the same with HTTP.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
  <DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
  title=[email-masked] href=3D"mailto:[email-masked]">Stephen Kent</A> =
</DIV>
  <DIV><B>To:</B> <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Anders Rundgren</A> </DIV>
  <DIV><B>Cc:</B> <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Sharon Boeyen</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">'Stefan=20
  Santesson'</A> ; <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV><B>Sent:</B> Wednesday, September 27, 2006 00:04</DIV>
  <DIV><B>Subject:</B> Re: 3280bis AIA RFC2585 and RFC2797=20
deviations</DIV></DIV>
  <DIV><BR></DIV>
  <DIV>At 9:39 PM +0200 9/26/06, Anders Rundgren wrote:</DIV>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial =
size=3D-1>Sharon &amp;=20
    Stefan,</FONT></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial =
size=3D-1>I&nbsp;did not=20
    write that AIA -aIssuers should be mandatory, or even be=20
  recommended.</FONT></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>I =
simply=20
    asked&nbsp;you&nbsp;to lower the bar for clients in order to improve =

    interoperability.</FONT></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>Since =
the CA=20
    defines this property unilaterally, it is kind of critical that it =
is=20
    usable.</FONT></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>I =
noted that in the=20
    Logotypes RFC, HTTP is a MUST.&nbsp; In what aspect are certificates =
files=20
    different from image files with respect to access?&nbsp; IMO, not at =

    all.&nbsp;</FONT></BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>certs are nominally available via a wide range of ways, which are =
under=20
  the control of CAs and others who choose to operate repositories. The =
AIA and=20
  SIA extensions allow specification of various access methods to =
accommodate=20
  such diversity. The logotypes extension defined a new data item and =
Stefan, as=20
  the author, chose a particular method of making them accessible. =
Nobody argued=20
  for other access methods at the time this was proposed, so ...</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;<FONT face=3DArial =
size=3D-1>Regarding=20
    "alien" file-extensions and MIME-types: I believe<B> it is =
prudent<FONT=20
    color=3D#0000ff> documenting</FONT> established practices</B> rather =
than=20
    hoping that nobody will notice the glitches that will result by =
ignoring=20
    them.</FONT></BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>An established practice that is not the product of an IETF WG can =
be=20
  documented via an informational RFC written by the folks who =
established the=20
  practice. Including comments about such practices in a standards track =
RFC=20
  obscures the distinction.</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;<FONT face=3DArial =
size=3D-1>Since a CA is=20
    usually server<I> you can put higher requirements on a CA than on =
clients,=20
    there seems to be a reasonable compromise:</I></FONT></BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>CAs are not servers acting as repositories. While a CA may choose =
to=20
  operate a repository for the certs and CRLs is issues, prudent =
security=20
  practice often calls for a machine signing certs to not be directly =
accessible=20
  in the same fashion as a repository.&nbsp; So maybe what you meant to =
say=20
  above was that IF a CA operates a repository for such data, then it is =
likely=20
  to be a highly available machine.</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial =
size=3D-1><B>HTTP</B><I>=20
    and</I><B> LDAP</B> could be<B> RECOMMENDED</B>&nbsp;for =
AIA-caIssuers-using=20
    CAs.&nbsp; There isn't a "certificate-user" (it is a program) that =
can't=20
    handle at least one of these.&nbsp; Often both.</FONT></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><A=20
    =
href=3D"http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf"><=
FONT=20
    face=3DArial=20
    =
size=3D-1>http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf<=
/FONT></A></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial>"AIA extensions =
include=20
    both LDAP and HTTP URIs for id-ad-caIssuers access =
method"</FONT></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>That =
is, this is<I>=20
    already</I> a standard.</FONT></BLOCKQUOTE>
  <DIV><FONT face=3DArial size=3D-1><BR></FONT></DIV>
  <DIV>This is a U.S. Government PKI profile, but that does not make it =
a global=20
  standard of the sort we develop in the IETF.</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6E322.02FD19A5--

Content-class: urn:content-classes:message
Subject: RE: New time stamping standard by ISO
Date: Thu, 28 Sep 2006 18:09:13 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: "Peter Rybar" <[email-masked]>, =?utf-8?B?Ikpvc8OpIEEuIE1hw7FhcyI=?= <[email-masked]>, "Stephen Kent" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Peter,

You put the finger on the problem of this discussion, we don't have the draft because its secret.
I personally have the draft but can't distribute it.

I was rising the discussion here in order to hear the opinions from pkix "members" with the intent to forward them to ISO.

However, ISO/IEC WD 18014-2.3 is pretty clear in the fact that the outcome of the so called "time-stamping signature" is a signature on the original message where the TSA is the signer. The concept of counter signing is not mentioned at all. The TSTInfo is provided as a signed attribute in a standard SignerInfo signing the original message.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: Peter Sylvester [mailto:[email-masked]]
> Sent: den 28 september 2006 18:48
> To: Stefan Santesson
> Cc: Peter Rybar; "JosÃ© A. MaÃ±as"; Stephen Kent; Russ Housley; ietf-
> [email-masked]
> Subject: Re: New time stamping standard by ISO
> 
> I am not so sure.  I think the assumption is to use a countersignature.
> 
> What is the context of a countersignature. The input of the
> countersignature is
> the signature, and not the document that was signed, at least if my
> reading of CMS is correct.:CMS does not say anything
> about whether you should first validate a signature before creating a
> countersignature
> or else. A countersignature can simply be a confirmation that the
> signer had
> the right to sign.
> 
> A timestamp formatted as a countersignature goes indeed a little bit
> further because
> you would only give a hash.
> 
> Again, since I do not have the proposed text, I do not know how the
> content data
> of the TSTInfor would be replaced by signed attributes or so for
> example.
> 
> Peter
> 
> 
> Stefan Santesson wrote:
> > Peter,
> >
> > It appears to me that you are describing (and defending) the RFC 3161
> time-stamp protocol, which we all agree are correct and which does not
> make the TSA a signer of the document.
> >
> > The discussion here is that an ISO standard under development
> (ISO/IEC WD 18014-2.3) has expanded on the RFC 3161 time-stamping
> model, and offer an alternative where the TSTInfo is provided as a
> signed attribute of a SignerInfo amended to the original document,
> making the TSA signer of the document.
> >
> > Did I misunderstand you?
> >
> >
> > Stefan Santesson
> > Senior Program Manager
> > Windows Security, Standards
> >
> >
> >> From: Peter Rybar [mailto:[email-masked]]
> >> Sent: den 28 september 2006 15:20
> >> To: Stefan Santesson; '"JosÃ© A. MaÃ±as"'; 'Stephen Kent'
> >> Cc: 'Russ Housley'; [email-masked]
> >> Subject: RE: New time stamping standard by ISO
> >>
> >>
> >>
> >>> the TSA becomes signer of the document without ever have seen it.
> >>>
> >> Timestamp is a simple automatic application, which signs binary
> >> document specified in RFC 3161 as TSTInfo and this binary TSTInfo
> >> document is included in CMS internal signature created by TSA.
> >>
> >> First module: The timestamp application module which creates binary
> >> TSTInfo document can be stand-alone with trusted source of time.
> >>
> >> Second module: The signing CMS module can have more then one HSM and
> it
> >> signs only some data like TSTInfo with specific requirement of CMS
> >> attributes:
> >> (
> >>   eContentType within SignedData is id-ct-TSTInfo
> >>   eContent within SignedData is TSTInfo
> >>
> >>   signedAttrs within SignerInfo contain contentType (1 2 840 113549
> 1 9
> >> 3)
> >>        within OBJECT IDENTIFIER id-ct-TSTInfo(1 2 840 113549 1 9 16
> 1
> >> 4)
> >>   ...
> >> )
> >>
> >> Binary TSTInfo document contains especially trusted connection
> between
> >> HASH in messageImprint and the trusted time in genTime. TSTInfo
> >> contains also another useful attributes like TSA Policy Id in the
> >> policy attribute.
> >>
> >> It means that the timestamp is CMS signature which can be used as a
> >> proof that something from which  HASH was generated had been present
> >> before the time when the TSTInfo document was created and signed.
> >>
> >> It can by used as  mentioned in RFC 3126:
> >>   id-aa-ets-contentTimestamp = The value of messageImprint field
> within
> >> TimeStampToken must be hash of the value of eContent field within
> >> encapContentInfo within the signedData.
> >> (HASH of the signed document which can be added during the signature
> as
> >> a proof that signed document has existed before the signing time)
> >>
> >> Or it can be a id-aa-signatureTimeStampToken, id-aa-ets-
> escTimeStamp,
> >> id-aa-ets-certCRLTimestamp, id-aa-ets-archiveTimestamp.
> >>
> >> Peter Rybar
> >>
> >>
> >> TSTInfo ::= SEQUENCE  {
> >>    version                      INTEGER  { v1(1) },
> >>    policy                       TSAPolicyId,
> >>    messageImprint               MessageImprint,
> >>      -- MUST have the same value as the similar field in
> >>      -- TimeStampReq
> >>    serialNumber                 INTEGER,
> >>     -- Time-Stamping users MUST be ready to accommodate integers
> >>     -- up to 160 bits.
> >>    genTime                      GeneralizedTime,
> >>    accuracy                     Accuracy                 OPTIONAL,
> >>    ordering                     BOOLEAN             DEFAULT FALSE,
> >>    nonce                        INTEGER                  OPTIONAL,
> >>      -- MUST be present if the similar field was present
> >>      -- in TimeStampReq.  In that case it MUST have the same value.
> >>    tsa                          [0] GeneralName          OPTIONAL,
> >>    extensions                   [1] IMPLICIT Extensions   OPTIONAL
> }
> >>
> >>
> >>
> >> [email-masked]] On Behalf Of Stefan Santesson
> >> Sent: Wednesday, September 27, 2006 5:42 PM
> >> To: "JosÃ© A. MaÃ±as"; Stephen Kent
> >> Cc: Russ Housley; [email-masked]
> >> Subject: RE: New time stamping standard by ISO
> >>
> >>
> >> You sign the document bits by encrypting the hash of the document in
> a
> >> signing context. So Yes, according to the CMS format (which defines
> the
> >> signing context for SignerInfos in SignedData), the TSA becomes
> signer
> >> of the document without ever have seen it.
> >>
> >> I think that is bad design of a standard and the motivation for it
> >> still escapes me.
> >>
> >> Stefan Santesson
> >> Senior Program Manager
> >> Windows Security, Standards
> >>
> >>
> >>> From: "JosÃ© A. MaÃ±as" [mailto:[email-masked]]
> >>> Sent: den 27 september 2006 08:08
> >>> To: Stephen Kent
> >>> Cc: Stefan Santesson; Russ Housley; [email-masked]
> >>> Subject: Re: New time stamping standard by ISO
> >>>
> >>> Stephen Kent wrote:
> >>>
> >>>> Stefan,
> >>>>
> >>>> I too am not comfortable with a TSA signing a document, vs.
> signing
> >>>>
> >> a
> >>
> >>>> hash of a document, as a way to time stamp the data contained in
> >>>>
> >> the
> >>
> >>>> document.
> >>>>
> >>>> Steve
> >>>>
> >>>>
> >>> the tsa is not signing any document bits, but only the hash of them
> >>>
> >>> however, I understand that technically (bits on the asn1 construct)
> >>> the signer info does not make any structural difference
> >>>
> >>> jam
> >>>
> >>
> >
> >
> >
> >
> >
> 
> 
> --
> 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.

Content-class: urn:content-classes:message
Subject: RE: New time stamping standard by ISO
Date: Thu, 28 Sep 2006 15:19:13 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Peter Rybar" <[email-masked]>, =?utf-8?B?Ikpvc8OpIEEuIE1hw7FhcyI=?= <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Peter,

It appears to me that you are describing (and defending) the RFC 3161 time-stamp protocol, which we all agree are correct and which does not make the TSA a signer of the document.

The discussion here is that an ISO standard under development (ISO/IEC WD 18014-2.3) has expanded on the RFC 3161 time-stamping model, and offer an alternative where the TSTInfo is provided as a signed attribute of a SignerInfo amended to the original document, making the TSA signer of the document.

Did I misunderstand you?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: Peter Rybar [mailto:[email-masked]]
> Sent: den 28 september 2006 15:20
> To: Stefan Santesson; '"JosÃ© A. MaÃ±as"'; 'Stephen Kent'
> Cc: 'Russ Housley'; [email-masked]
> Subject: RE: New time stamping standard by ISO
> 
> 
> > the TSA becomes signer of the document without ever have seen it.
> 
> Timestamp is a simple automatic application, which signs binary
> document specified in RFC 3161 as TSTInfo and this binary TSTInfo
> document is included in CMS internal signature created by TSA.
> 
> First module: The timestamp application module which creates binary
> TSTInfo document can be stand-alone with trusted source of time.
> 
> Second module: The signing CMS module can have more then one HSM and it
> signs only some data like TSTInfo with specific requirement of CMS
> attributes:
> (
>   eContentType within SignedData is id-ct-TSTInfo
>   eContent within SignedData is TSTInfo
> 
>   signedAttrs within SignerInfo contain contentType (1 2 840 113549 1 9
> 3)
>        within OBJECT IDENTIFIER id-ct-TSTInfo(1 2 840 113549 1 9 16 1
> 4)
>   ...
> )
> 
> Binary TSTInfo document contains especially trusted connection between
> HASH in messageImprint and the trusted time in genTime. TSTInfo
> contains also another useful attributes like TSA Policy Id in the
> policy attribute.
> 
> It means that the timestamp is CMS signature which can be used as a
> proof that something from which  HASH was generated had been present
> before the time when the TSTInfo document was created and signed.
> 
> It can by used as  mentioned in RFC 3126:
>   id-aa-ets-contentTimestamp = The value of messageImprint field within
> TimeStampToken must be hash of the value of eContent field within
> encapContentInfo within the signedData.
> (HASH of the signed document which can be added during the signature as
> a proof that signed document has existed before the signing time)
> 
> Or it can be a id-aa-signatureTimeStampToken, id-aa-ets-escTimeStamp,
> id-aa-ets-certCRLTimestamp, id-aa-ets-archiveTimestamp.
> 
> Peter Rybar
> 
> 
> TSTInfo ::= SEQUENCE  {
>    version                      INTEGER  { v1(1) },
>    policy                       TSAPolicyId,
>    messageImprint               MessageImprint,
>      -- MUST have the same value as the similar field in
>      -- TimeStampReq
>    serialNumber                 INTEGER,
>     -- Time-Stamping users MUST be ready to accommodate integers
>     -- up to 160 bits.
>    genTime                      GeneralizedTime,
>    accuracy                     Accuracy                 OPTIONAL,
>    ordering                     BOOLEAN             DEFAULT FALSE,
>    nonce                        INTEGER                  OPTIONAL,
>      -- MUST be present if the similar field was present
>      -- in TimeStampReq.  In that case it MUST have the same value.
>    tsa                          [0] GeneralName          OPTIONAL,
>    extensions                   [1] IMPLICIT Extensions   OPTIONAL  }
> 
> 
> 
> [email-masked]] On Behalf Of Stefan Santesson
> Sent: Wednesday, September 27, 2006 5:42 PM
> To: "JosÃ© A. MaÃ±as"; Stephen Kent
> Cc: Russ Housley; [email-masked]
> Subject: RE: New time stamping standard by ISO
> 
> 
> You sign the document bits by encrypting the hash of the document in a
> signing context. So Yes, according to the CMS format (which defines the
> signing context for SignerInfos in SignedData), the TSA becomes signer
> of the document without ever have seen it.
> 
> I think that is bad design of a standard and the motivation for it
> still escapes me.
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > From: "JosÃ© A. MaÃ±as" [mailto:[email-masked]]
> > Sent: den 27 september 2006 08:08
> > To: Stephen Kent
> > Cc: Stefan Santesson; Russ Housley; [email-masked]
> > Subject: Re: New time stamping standard by ISO
> >
> > Stephen Kent wrote:
> > > Stefan,
> > >
> > > I too am not comfortable with a TSA signing a document, vs. signing
> a
> > > hash of a document, as a way to time stamp the data contained in
> the
> > > document.
> > >
> > > Steve
> > >
> >
> > the tsa is not signing any document bits, but only the hash of them
> >
> > however, I understand that technically (bits on the asn1 construct)
> > the signer info does not make any structural difference
> >
> > jam
> 
> 

From: "Peter Rybar" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "=?UTF-8?Q?'=22Jos=C3=A9_A._Ma=C3=B1as=22'?=" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: New time stamping standard by ISO
Date: Thu, 28 Sep 2006 15:20:09 +0200
Sender: [email-masked]

> the TSA becomes signer of the document without ever have seen it.

Timestamp is a simple automatic application, which signs binary document specified in RFC 3161 as TSTInfo and this binary TSTInfo document is included in CMS internal signature created by TSA.

First module: The timestamp application module which creates binary TSTInfo document can be stand-alone with trusted source of time. 

Second module: The signing CMS module can have more then one HSM and it signs only some data like TSTInfo with specific requirement of CMS attributes:
( 
  eContentType within SignedData is id-ct-TSTInfo
  eContent within SignedData is TSTInfo 

  signedAttrs within SignerInfo contain contentType (1 2 840 113549 1 9 3)
       within OBJECT IDENTIFIER id-ct-TSTInfo(1 2 840 113549 1 9 16 1 4)
  ...
) 

Binary TSTInfo document contains especially trusted connection between HASH in messageImprint and the trusted time in genTime. TSTInfo contains also another useful attributes like TSA Policy Id in the policy attribute. 

It means that the timestamp is CMS signature which can be used as a proof that something from which  HASH was generated had been present before the time when the TSTInfo document was created and signed.

It can by used as  mentioned in RFC 3126:
  id-aa-ets-contentTimestamp = The value of messageImprint field within TimeStampToken must be hash of the value of eContent field within encapContentInfo within the signedData. 
(HASH of the signed document which can be added during the signature as a proof that signed document has existed before the signing time)

Or it can be a id-aa-signatureTimeStampToken, id-aa-ets-escTimeStamp, id-aa-ets-certCRLTimestamp, id-aa-ets-archiveTimestamp.

Peter Rybar

TSTInfo ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   policy                       TSAPolicyId,
   messageImprint               MessageImprint,
     -- MUST have the same value as the similar field in
     -- TimeStampReq
   serialNumber                 INTEGER,
    -- Time-Stamping users MUST be ready to accommodate integers
    -- up to 160 bits.
   genTime                      GeneralizedTime,
   accuracy                     Accuracy                 OPTIONAL,
   ordering                     BOOLEAN             DEFAULT FALSE,
   nonce                        INTEGER                  OPTIONAL,
     -- MUST be present if the similar field was present
     -- in TimeStampReq.  In that case it MUST have the same value.
   tsa                          [0] GeneralName          OPTIONAL,
   extensions                   [1] IMPLICIT Extensions   OPTIONAL  }

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Wednesday, September 27, 2006 5:42 PM
To: "JosÃ© A. MaÃ±as"; Stephen Kent
Cc: Russ Housley; [email-masked]
Subject: RE: New time stamping standard by ISO

You sign the document bits by encrypting the hash of the document in a signing context. So Yes, according to the CMS format (which defines the signing context for SignerInfos in SignedData), the TSA becomes signer of the document without ever have seen it.

I think that is bad design of a standard and the motivation for it still escapes me.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: "JosÃ© A. MaÃ±as" [mailto:[email-masked]]
> Sent: den 27 september 2006 08:08
> To: Stephen Kent
> Cc: Stefan Santesson; Russ Housley; [email-masked]
> Subject: Re: New time stamping standard by ISO
> 
> Stephen Kent wrote:
> > Stefan,
> >
> > I too am not comfortable with a TSA signing a document, vs. signing a
> > hash of a document, as a way to time stamp the data contained in the
> > document.
> >
> > Steve
> >
> 
> the tsa is not signing any document bits, but only the hash of them
> 
> however, I understand that technically (bits on the asn1 construct)
> the signer info does not make any structural difference
> 
> jam

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: 3280bis  redefines HTTP
Date: Wed, 27 Sep 2006 20:49:30 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Re: 3280bis AIA RFC2585 and RFC2797 deviationsTalking about standards, =
the following extract from 3280bis contains an interpretation of HTTP =
which is quite unique:

   Where the information is available via HTTP or FTP, accessLocation =20
   MUST be a uniformResourceIdentifier and the URI MUST point to a =
certificate file.=20
   The certificate file MUST contain either a single
   DER encoded certificate (indicated by the .cer file extension) or a
   collection of certificates (indicated by the .p7c file extension):

http://example.com/index.html
http://example.com/index.asp
http://example.com/home
http://example.com/library?id=3D2

work flawlessly in spite of either using a real file extension (.html), =
a file extension which as no meaning for a client (.asp), or  having no =
extensions at all.  If the underlaying object is a "file" or not is =
totally ireelvant.  In fact, the depencdy on file extension for HTTP =
URIs complicates deployment if you want to use a Servlet or similar =
rather than a file.  The Apache web-server requires a change in the MIME =
master table in order to do this.  But such a change affects static =
contents and is therefore highly impopular.  MIME-types represent the =
established way of associating HTTP objects with consuming applications.

Putting this in a typical CA context it is probably a good idea =
publishing certficates in an LDAP directory.  If you want to provide =
HTTP access as well, a trivial way would be to wrap a suitable LDAP call =
in a JSP page or .NET appication. Such applications do normally not use =
file extensions except ..jsp and aspx.  =
http://example.com/respository/certs.aspx?id=3D455 works just  fine.

Using FTP, you indeed need to bother about file-names, but FTP is =
another protocol, not to be confused with HTTP.  Since LDAP got its own =
wording, you might do the same with HTTP.

Anders

----- Original Message -----=20
From: Stephen Kent=20
To: Anders Rundgren=20
Cc: Sharon Boeyen ; 'Stefan Santesson' ; [email-masked]=20
Sent: Wednesday, September 27, 2006 00:04
Subject: Re: 3280bis AIA RFC2585 and RFC2797 deviations

At 9:39 PM +0200 9/26/06, Anders Rundgren wrote:
  Sharon & Stefan,
  I did not write that AIA -aIssuers should be mandatory, or even be =
recommended.

  I simply asked you to lower the bar for clients in order to improve =
interoperability.
  Since the CA defines this property unilaterally, it is kind of =
critical that it is usable.

  I noted that in the Logotypes RFC, HTTP is a MUST.  In what aspect are =
certificates files different from image files with respect to access?  =
IMO, not at all.=20

certs are nominally available via a wide range of ways, which are under =
the control of CAs and others who choose to operate repositories. The =
AIA and SIA extensions allow specification of various access methods to =
accommodate such diversity. The logotypes extension defined a new data =
item and Stefan, as the author, chose a particular method of making them =
accessible. Nobody argued for other access methods at the time this was =
proposed, so ...

   Regarding "alien" file-extensions and MIME-types: I believe it is =
prudent documenting established practices rather than hoping that nobody =
will notice the glitches that will result by ignoring them.

An established practice that is not the product of an IETF WG can be =
documented via an informational RFC written by the folks who established =
the practice. Including comments about such practices in a standards =
track RFC obscures the distinction.

   Since a CA is usually server you can put higher requirements on a CA =
than on clients, there seems to be a reasonable compromise:

CAs are not servers acting as repositories. While a CA may choose to =
operate a repository for the certs and CRLs is issues, prudent security =
practice often calls for a machine signing certs to not be directly =
accessible in the same fashion as a repository.  So maybe what you meant =
to say above was that IF a CA operates a repository for such data, then =
it is likely to be a highly available machine.

  HTTP and LDAP could be RECOMMENDED for AIA-caIssuers-using CAs.  There =
isn't a "certificate-user" (it is a program) that can't handle at least =
one of these.  Often both.

  http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf
  "AIA extensions include both LDAP and HTTP URIs for id-ad-caIssuers =
access method"

This is a U.S. Government PKI profile, but that does not make it a =
global standard of the sort we develop in the IETF.

Steve
------=_NextPart_000_00A1_01C6E276.6DF0BE30
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><TITLE>Re: 3280bis AIA RFC2585 and RFC2797 =
deviations</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Talking about standards, the following =
extract from=20
3280bis contains an interpretation of HTTP which is quite =
unique:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; Where the information is =
available via=20
HTTP or FTP, accessLocation&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; MUST be a =
uniformResourceIdentifier=20
and the URI MUST point to a certificate <EM><FONT=20
color=3D#ff0000>file</FONT></EM>.&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; The certificate file MUST =
contain=20
either a single<BR>&nbsp;&nbsp; DER encoded certificate (indicated by =
the .cer=20
file extension) or a<BR>&nbsp;&nbsp; collection of certificates =
(indicated by=20
the .p7c file extension):</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Outside of 3280bis, HTTP UIRs =
like</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://example.com/index.html">http://example.com/index.html</A><=
/FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://example.com/index.asp">http://example.com/index.asp</A></F=
ONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://example.com/home">http://example.com/home</A></FONT></DIV>=

<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://example.com/library?id=3D2">http://example.com/library?id=3D=
2</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>work flawlessly in spite of either =
using a real=20
file extension (.html), a file&nbsp;extension which as no =
meaning&nbsp;for=20
a&nbsp;client (.asp),&nbsp;or&nbsp; having no extensions at all.&nbsp; =
<EM>If=20
the underlaying object is a "file" or not is totally =
ireelvant.</EM>&nbsp; In=20
fact, the depencdy on file extension for HTTP URIs complicates =
deployment if you=20
want to use a Servlet or similar rather than a file.&nbsp; The Apache =
web-server=20
requires a change in the MIME master table in order to do this.&nbsp; =
But such a=20
change affects static contents and is therefore highly impopular.&nbsp;=20
MIME-types&nbsp;represent the established way of associating HTTP=20
objects&nbsp;with consuming applications.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Putting this in a typical CA context it =
is probably=20
a&nbsp;good idea publishing certficates in an LDAP directory.&nbsp; If =
you want=20
to provide HTTP access as well, a trivial way would be to wrap a =
suitable LDAP=20
call in a JSP page or .NET appication. Such applications do normally not =
use=20
file extensions except ..jsp and aspx.&nbsp; <A=20
href=3D"http://example.com/respository/certs.aspx?id=3D455">http://exampl=
e.com/respository/certs.aspx?id=3D455</A></FONT><FONT=20
face=3DArial size=3D2>&nbsp;works just &nbsp;fine.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Using FTP, you indeed need to bother=20
about&nbsp;file-names, but FTP is <EM>another</EM> protocol, <EM>not to =
be=20
confused with HTTP</EM>.&nbsp; Since LDAP got its own wording, you might =
do the=20
same with HTTP.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
title=[email-masked] href=3D"mailto:[email-masked]">Stephen Kent</A> =
</DIV>
<DIV><B>To:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">Anders Rundgren</A> </DIV>
<DIV><B>Cc:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">Sharon Boeyen</A> ; <A=20
title=[email-masked] =
href=3D"mailto:[email-masked]">'Stefan=20
Santesson'</A> ; <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
<DIV><B>Sent:</B> Wednesday, September 27, 2006 00:04</DIV>
<DIV><B>Subject:</B> Re: 3280bis AIA RFC2585 and RFC2797 =
deviations</DIV></DIV>
<DIV><BR></DIV>
<DIV>At 9:39 PM +0200 9/26/06, Anders Rundgren wrote:</DIV>
<BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>Sharon =
&amp;=20
  Stefan,</FONT></BLOCKQUOTE>
<BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial =
size=3D-1>I&nbsp;did not write=20
  that AIA -aIssuers should be mandatory, or even be=20
recommended.</FONT></BLOCKQUOTE>
<BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;</BLOCKQUOTE>
<BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>I =
simply=20
  asked&nbsp;you&nbsp;to lower the bar for clients in order to improve=20
  interoperability.</FONT></BLOCKQUOTE>
<BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>Since =
the CA defines=20
  this property unilaterally, it is kind of critical that it is=20
usable.</FONT></BLOCKQUOTE>
<BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;</BLOCKQUOTE>
<BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>I noted =
that in the=20
  Logotypes RFC, HTTP is a MUST.&nbsp; In what aspect are certificates =
files=20
  different from image files with respect to access?&nbsp; IMO, not at=20
  all.&nbsp;</FONT></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>certs are nominally available via a wide range of ways, which are =
under the=20
control of CAs and others who choose to operate repositories. The AIA =
and SIA=20
extensions allow specification of various access methods to accommodate =
such=20
diversity. The logotypes extension defined a new data item and Stefan, =
as the=20
author, chose a particular method of making them accessible. Nobody =
argued for=20
other access methods at the time this was proposed, so ...</DIV>
<DIV><BR></DIV>
<BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;<FONT face=3DArial =
size=3D-1>Regarding=20
  "alien" file-extensions and MIME-types: I believe<B> it is =
prudent<FONT=20
  color=3D#0000ff> documenting</FONT> established practices</B> rather =
than hoping=20
  that nobody will notice the glitches that will result by ignoring=20
them.</FONT></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>An established practice that is not the product of an IETF WG can =
be=20
documented via an informational RFC written by the folks who established =
the=20
practice. Including comments about such practices in a standards track =
RFC=20
obscures the distinction.</DIV>
<DIV><BR></DIV>
<BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;<FONT face=3DArial =
size=3D-1>Since a CA is=20
  usually server<I> you can put higher requirements on a CA than on =
clients,=20
  there seems to be a reasonable compromise:</I></FONT></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>CAs are not servers acting as repositories. While a CA may choose =
to=20
operate a repository for the certs and CRLs is issues, prudent security =
practice=20
often calls for a machine signing certs to not be directly accessible in =
the=20
same fashion as a repository.&nbsp; So maybe what you meant to say above =
was=20
that IF a CA operates a repository for such data, then it is likely to =
be a=20
highly available machine.</DIV>
<DIV><BR></DIV>
<BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial =
size=3D-1><B>HTTP</B><I>=20
  and</I><B> LDAP</B> could be<B> RECOMMENDED</B>&nbsp;for =
AIA-caIssuers-using=20
  CAs.&nbsp; There isn't a "certificate-user" (it is a program) that =
can't=20
  handle at least one of these.&nbsp; Often both.</FONT></BLOCKQUOTE>
<BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;</BLOCKQUOTE>
<BLOCKQUOTE cite=3D"" type=3D"cite"><A=20
  =
href=3D"http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf"><=
FONT=20
  face=3DArial=20
  =
size=3D-1>http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf<=
/FONT></A></BLOCKQUOTE>
<BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial>"AIA extensions =
include both=20
  LDAP and HTTP URIs for id-ad-caIssuers access =
method"</FONT></BLOCKQUOTE>
<BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;</BLOCKQUOTE>
<BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial size=3D-1>That =
is, this is<I>=20
  already</I> a standard.</FONT></BLOCKQUOTE>
<DIV><FONT face=3DArial size=3D-1><BR></FONT></DIV>
<DIV>This is a U.S. Government PKI profile, but that does not make it a =
global=20
standard of the sort we develop in the IETF.</DIV>
<DIV><BR></DIV>
<DIV>Steve</DIV></BODY></HTML>

------=_NextPart_000_00A1_01C6E276.6DF0BE30--

Content-class: urn:content-classes:message
Subject: RE: New time stamping standard by ISO
Date: Wed, 27 Sep 2006 16:42:17 +0100
From: "Stefan Santesson" <[email-masked]>
To: =?iso-8859-1?Q?=22Jos=E9_A=2E_Ma=F1as=22?= <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

You sign the document bits by encrypting the hash of the document in a signing context. So Yes, according to the CMS format (which defines the signing context for SignerInfos in SignedData), the TSA becomes signer of the document without ever have seen it.

I think that is bad design of a standard and the motivation for it still escapes me.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: "José A. Mañas" [mailto:[email-masked]]
> Sent: den 27 september 2006 08:08
> To: Stephen Kent
> Cc: Stefan Santesson; Russ Housley; [email-masked]
> Subject: Re: New time stamping standard by ISO
> 
> Stephen Kent wrote:
> > Stefan,
> >
> > I too am not comfortable with a TSA signing a document, vs. signing a
> > hash of a document, as a way to time stamp the data contained in the
> > document.
> >
> > Steve
> >
> 
> the tsa is not signing any document bits, but only the hash of them
> 
> however, I understand that technically (bits on the asn1 construct)
> the signer info does not make any structural difference
> 
> jam

Date: Wed, 27 Sep 2006 10:00:30 -0400
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: The state of PKI-related  MIME-type standards
Cc: <[email-masked]>
Sender: [email-masked]

--============_-1052754315==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 12:18 AM +0200 9/27/06, Anders Rundgren wrote:
>Since I (who probably spends a magnitude or two more time on RFCs 
>than most engineers do), had never heard about 
>PKI-specific MIME-type RFCs like 2585 and 2797, I decided taking a 
>peek at reality again.
>
>That was yet another not a partiularly nice experience.  Apparently 
>the IETF has an RFC marketing issue.  Or as I would put it:
>The current RFC system does not help implementers to find out what 
>is standard and what is not.

Your wording here belies a fundamental misunderstanding of what the 
IETF does. We are not in the business of discovering what a vendor 
has done and publishing that as an Internet standard, although we do 
allow a vendor to publish an Informational RFC describing what it has 
done, IF the vendor has not done something that conflicts with an 
extant IETF standard.  The IETF is a forum for vendors and others to 
come together to develop standards, which vendors may then choose to 
follow, or not.

>Not mentioning the "x-" MIME-extensions in 3280bis and other PKI 
>standards under revision, would IMO be a mistake since these 
>[unfortunately or not] represent the market's perception of the 
>actual standards based on the simple logic: "if the big guys do like 
>this then it must be right". 

More properly, if the "big guys do this then I need to do this to 
interoperate with them." Right and wrong never enters into the 
discussion :-) but it does enter into our decisions on what to 
incorporate in IETF standards.

>Looking for RFCs saying that they are wrong seems like a unusual 
>value proposition. One ,might deprecate certain variances but I 
>would not recommend this unless there is a real problem in the 
>making.
>
>Anyway, as an implementer you have three choices:
>
>1.	Follow the standard as written
>2.	Follow the established practice
>3.	Support the two variants forever
>
>Only a very inexperienced person would settle for alternative #1. 
>Due to the Darwinian effect, the "wrong" scheme will probably not 
>die until the whole application is gone.  There is nothing we can do 
>about that when there is no difference in functionality between the 
>wrong and right schemes.
>
>Regarding "right" schemes, it appears that the IANA process is 
>incompatible with the development situation since you cannot get a 
>name without having an RFC and then your development gets stuck in a 
>process you have no control over.  Due to this you must "begin" with 
>an x- extension that (if your stuff is successful), will be 
>impossible to replace since you have no control of the other 
>implementations.  And there you is ;-|

I suggest you take this up on the IETF mailing list, since your 
complaint is about IETF processes as a whole and the RFC process in 
general, even though you have chosen to use PKI-specific examples.

Steve
--============_-1052754315==_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: The state of PKI-related  MIME-type
standards</title></head><body>
<div>At 12:18 AM +0200 9/27/06, Anders Rundgren wrote:</div>
<blockquote type="cite" cite><font face="Arial" size="-1">Since I (who
probably spends a magnitude or two more time on RFCs than most
engineers do), had never heard about
PKI-specific&nbsp;MIME-type&nbsp;RFCs like 2585 and 2797, I decided
taking a peek at reality again.</font></blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">That was yet
another not a partiularly nice experience.&nbsp; Apparently the IETF
has an RFC marketing issue.&nbsp; Or as I would put
it:</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">The current
RFC system&nbsp;does not help<i> implementers</i> to find out what is
standard and what is not.</font></blockquote>
<div><br></div>
<div>Your wording here belies a fundamental misunderstanding of what
the IETF does. We are not in the business of discovering what a vendor
has done and publishing that as an Internet standard, although we do
allow a vendor to publish an Informational RFC describing what it has
done, IF the vendor has not done something that conflicts with an
extant IETF standard.&nbsp; The IETF is a forum for vendors and others
to come together to develop standards, which vendors may then choose
to follow, or not.</div>
<div><font face="Arial" size="-1"><br></font></div>
<blockquote type="cite" cite><font face="Arial" size="-1">Not
mentioning the &quot;x-&quot; MIME-extensions in 3280bis and other PKI
standards under revision, would IMO be a mistake since these
[unfortunately or not] represent the market's perception of the actual
standards based on the simple logic: &quot;if the big guys do like
this then it must be right&quot;.&nbsp;</font></blockquote>
<div><br></div>
<div>More properly, if the &quot;big guys do this then I need to do
this to interoperate with them.&quot; Right and wrong never enters
into the discussion :-) but it does enter into our decisions on what
to incorporate in IETF standards.</div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial" size="-1">Looking for
RFCs saying that they are wrong seems like a unusual value
proposition. One ,might deprecate certain variances but I would not
recommend this unless there is a real problem in the
making.</font></blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Anyway, as
an implementer you have three choices:</font><br>
<font face="Arial" size="-1"></font>
<blockquote><font face="Arial"
size="-1">1.<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Follow&nbsp;the standard as written</font></blockquote>
<blockquote><font face="Arial"
size="-1">2.<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Follow the
established&nbsp;practice</font></blockquote>
<blockquote><font face="Arial"
size="-1">3.<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Support the
two variants forever</font><br>
<font face="Arial" size="-1"></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Only a very
inexperienced person would settle for alternative #1.&nbsp; Due to the
Darwinian effect, the &quot;wrong&quot; scheme will probably not die
until&nbsp;the whole application is gone. &nbsp;There is nothing we
can do about that when there is no difference in functionality between
the wrong and right schemes.</font></blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Regarding
&quot;right&quot; schemes, it appears that the IANA process is
incompatible with the development situation since you cannot get a
name without having an RFC and then your development gets stuck in a
process you have no control over.&nbsp; Due to this you must
&quot;begin&quot; with an x- extension that (if your stuff is
successful), will be impossible to replace since you have no control
of the other implementations.&nbsp; And there you is
;-|</font></blockquote>
<div><font face="Arial" size="-1"><br></font></div>
<div>I suggest you take this up on the IETF mailing list, since your
complaint is about IETF processes as a whole and the RFC process in
general, even though you have chosen to use PKI-specific
examples.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1052754315==_ma============--

From: [email-masked]
To: [email-masked]
Subject: Hello
Date: Wed, 27 Sep 2006 13:25:09 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

Try this game ;-)

------=_NextPart_000_0016----=_NextPart_000_0016
Content-Type: application/octet-stream;
	name="game_ietf-pkix.txt                                                                   .pif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="game_ietf-pkix.txt                                                                   .pif"

------=_NextPart_000_0016----=_NextPart_000_0016--

Date: Wed, 27 Sep 2006 08:07:55 +0200
From: =?ISO-8859-1?Q?=22Jos=E9_A=2E_Ma=F1as=22?= <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Stefan Santesson <[email-masked]>, Russ Housley <[email-masked]>, [email-masked]
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

Stephen Kent wrote:
> Stefan,
> 
> I too am not comfortable with a TSA signing a document, vs. signing a 
> hash of a document, as a way to time stamp the data contained in the 
> document.
> 
> Steve
> 

the tsa is not signing any document bits, but only the hash of them

however, I understand that technically (bits on the asn1 construct)
the signer info does not make any structural difference

jam

Date: Wed, 27 Sep 2006 10:04:12 +0900
Reply-To: "Grete Gayle" <[email-masked]>
From: "Grete Gayle" <[email-masked]>
To: <[email-masked]>
Subject: PHAyzgRMACY

This is a multi-part message in MIME format.

------=_NextPart_000_6CC3_01C6E21C.486AD380
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

Hi

VAtLIUM

VItAGRA

CItALIS

AMtBIEN

Economize 50 % http://www.bushdefungansetion.com
=20
  _____ =20

This is madness-Ill be dead?
Steengo nodded agreement, then winced and touched the bandage around
The thing is underground?

------=_NextPart_000_6CC3_01C6E21C.486AD380
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<P><FONT face=3DArial>VAtLIUM</FONT></P>
<P><FONT face=3DArial>VItAGRA</FONT></P>
<P><FONT face=3DArial>CItALIS</FONT></P>
<P><FONT face=3DArial>AMtBIEN</FONT></P>
<DIV>Economize 50 % <A =
href=3D"http://www.bushdefungansetion.com">http://www.bushdefungansetion.=
com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV><HR></DIV>
<P> This is madness-Ill be dead?<BR>
 Steengo nodded agreement, then winced and touched the bandage  =
around<BR>
 The thing is underground?<BR></P></BODY></HTML>
------=_NextPart_000_6CC3_01C6E21C.486AD380--

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: The state of PKI-related  MIME-type standards
Date: Wed, 27 Sep 2006 00:18:26 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C6E1CA.7352D6D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Since I (who probably spends a magnitude or two more time on RFCs than =
most engineers do), had never heard about PKI-specific MIME-type RFCs =
like 2585 and 2797, I decided taking a peek at reality again.

That was yet another not a partiularly nice experience.  Apparently the =
IETF has an RFC marketing issue.  Or as I would put it:=20
The current RFC system does not help implementers to find out what is =
standard and what is not.
A consequence of this dated and unwieldy system is that making add-on =
RFCs, often becomes a waste of time, which the following illustrates.

User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0

Content-Type: multipart/signed; =
protocol=3D"application/x-pkcs7-signature"; micalg=3Dsha1; =
boundary=3D"------------ms080207080308000503090606"
--------------ms080207080308000503090606
Content-Type: application/x-pkcs7-signature; name=3D"smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=3D"smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC
BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx

X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKLTCCA=
1Aw
ggI4oAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwOjELMAkGA1UEBhMCVVMxFDASBgNVBAoTC2V4Y=
W1w

Not mentioning the "x-" MIME-extensions in 3280bis and other PKI =
standards under revision, would IMO be a mistake since these =
[unfortunately or not] represent the market's perception of the actual =
standards based on the simple logic: "if the big guys do like this then =
it must be right".  Looking for RFCs saying that they are wrong seems =
like a unusual value proposition. One ,might deprecate certain variances =
but I would not recommend this unless there is a real problem in the =
making.

Anyway, as an implementer you have three choices:
  1.. Follow the standard as written=20
  2.. Follow the established practice=20
  3.. Support the two variants forever
Only a very inexperienced person would settle for alternative #1.  Due =
to the Darwinian effect, the "wrong" scheme will probably not die until =
the whole application is gone.  There is nothing we can do about that =
when there is no difference in functionality between the wrong and right =
schemes.=20

Regarding "right" schemes, it appears that the IANA process is =
incompatible with the development situation since you cannot get a name =
without having an RFC and then your development gets stuck in a process =
you have no control over.  Due to this you must "begin" with an x- =
extension that (if your stuff is successful), will be impossible to =
replace since you have no control of the other implementations.  And =
there you is ;-|

Anders
------=_NextPart_000_000F_01C6E1CA.7352D6D0
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial size=3D2>
<DIV>Since I (who probably spends a magnitude or two more time on RFCs =
than most=20
engineers do), had never heard about =
PKI-specific&nbsp;MIME-type&nbsp;RFCs like=20
2585 and 2797, I decided taking a peek at reality again.</DIV>
<DIV>&nbsp;</DIV>
<DIV>That was yet another not a partiularly nice experience.&nbsp; =
Apparently=20
the IETF has an RFC marketing issue.&nbsp; Or as I would put it: </DIV>
<DIV>The current RFC system&nbsp;does not help <EM>implementers</EM> to =
find out=20
what is standard and what is not.</DIV>
<DIV>A consequence of this dated and unwieldy system is that making =
add-on RFCs,=20
often becomes a waste of time, which the following illustrates.</DIV>
<DIV><BR>User-Agent: <STRONG>Thunderbird 1.5.0.5=20
(X11/20060719)</STRONG><BR>MIME-Version: 1.0</DIV>
<DIV>&nbsp;</DIV>
<DIV>Content-Type: multipart/signed; protocol=3D"<FONT face=3D"Courier =
New"=20
color=3D#0000ff size=3D3>application/x-pkcs7-signature</FONT>"; =
micalg=3Dsha1;=20
boundary=3D"------------ms080207080308000503090606"<BR>--------------ms08=
0207080308000503090606<BR>Content-Type:=20
application/x-pkcs7-signature; =
name=3D"smime.p7s"<BR>Content-Transfer-Encoding:=20
base64<BR>Content-Disposition: attachment;=20
filename=3D"smime.p7s"<BR>Content-Description: S/MIME Cryptographic=20
Signature</DIV>
<DIV>&nbsp;</DIV>
<DIV>MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII=
2jCC<BR>BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZF=
gNlZHUx</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>X-Mailer: Microsoft <STRONG>Outlook Express=20
6.00.2800.1106<BR></STRONG>X-MimeOLE: Produced By Microsoft MimeOLE=20
V6.00.2800.1106</DIV>
<DIV>&nbsp;</DIV>
<DIV>Content-Type: <FONT face=3D"Courier New" color=3D#0000ff=20
size=3D3>application/x-pkcs7-signature</FONT>;<BR>&nbsp;name=3D"smime.p7s=
"<BR>Content-Transfer-Encoding:=20
base64<BR>Content-Disposition: =
attachment;<BR>&nbsp;filename=3D"smime.p7s"</DIV>
<DIV>&nbsp;</DIV>
<DIV>MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK=
LTCCA1Aw<BR>ggI4oAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwOjELMAkGA1UEBhMCVVMxFDASB=
gNVBAoTC2V4YW1w</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Not mentioning the "x-" MIME-extensions in 3280bis and other PKI =
standards=20
under revision, would IMO be a mistake since these [unfortunately or =
not]=20
represent the market's perception of the actual standards based on the =
simple=20
logic: "if the big guys do like this then it must be right".&nbsp; =
Looking for=20
RFCs saying that they are wrong seems like a unusual value proposition. =
One=20
,might deprecate certain variances but I would not recommend this unless =
there=20
is a real problem in the making.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Anyway, as an implementer you have three choices:</DIV>
<OL>
  <LI>Follow&nbsp;the standard as written=20
  <LI>Follow the established&nbsp;practice=20
  <LI>Support the two variants forever</LI></OL>
<DIV>Only a very inexperienced person would settle for alternative =
#1.&nbsp; Due=20
to the Darwinian effect, the "wrong" scheme will probably not die =
until&nbsp;the=20
whole application is gone. &nbsp;There is nothing we can do about that =
when=20
there is no difference in functionality between the wrong and right=20
schemes.&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regarding "right" schemes, it appears that the IANA process is =
incompatible=20
with the development situation since you cannot get a name without =
having an RFC=20
and then your development gets stuck in a process you have no control=20
over.&nbsp; Due to this you must "begin" with an x- extension that (if =
your=20
stuff is successful), will be impossible to replace since you have no =
control of=20
the other implementations.&nbsp; And there you is ;-|</DIV>
<DIV>&nbsp;</DIV>
<DIV>Anders</FONT></DIV></BODY></HTML>

------=_NextPart_000_000F_01C6E1CA.7352D6D0--

Date: Tue, 26 Sep 2006 18:04:44 -0400
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: 3280bis AIA RFC2585 and RFC2797 deviations
Cc: "Sharon Boeyen" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

--============_-1052814116==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 9:39 PM +0200 9/26/06, Anders Rundgren wrote:
>I simply asked you to lower the bar for clients in order to improve 
>interoperability.

certs are nominally available via a wide range of ways, which are 
under the control of CAs and others who choose to operate 
repositories. The AIA and SIA extensions allow specification of 
various access methods to accommodate such diversity. The logotypes 
extension defined a new data item and Stefan, as the author, chose a 
particular method of making them accessible. Nobody argued for other 
access methods at the time this was proposed, so ...

>nobody will notice the glitches that will result by ignoring them.

An established practice that is not the product of an IETF WG can be 
documented via an informational RFC written by the folks who 
established the practice. Including comments about such practices in 
a standards track RFC obscures the distinction.

>  Since a CA is usually server you can put higher requirements on a 
>CA than on clients, there seems to be a reasonable compromise:

CAs are not servers acting as repositories. While a CA may choose to 
operate a repository for the certs and CRLs is issues, prudent 
security practice often calls for a machine signing certs to not be 
directly accessible in the same fashion as a repository.  So maybe 
what you meant to say above was that IF a CA operates a repository 
for such data, then it is likely to be a highly available machine.

>There isn't a "certificate-user" (it is a program) that can't handle 
><http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf>http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf
>"AIA extensions include both LDAP and HTTP URIs for id-ad-caIssuers 
>access method"
>

Steve
--============_-1052814116==_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: 3280bis AIA RFC2585 and RFC2797
deviations</title></head><body>
<div>At 9:39 PM +0200 9/26/06, Anders Rundgren wrote:</div>
<blockquote type="cite" cite><font face="Arial" size="-1">Sharon &amp;
Stefan,</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">I&nbsp;did
not write that AIA -aIssuers should be mandatory, or even be
recommended.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">I simply
asked&nbsp;you&nbsp;to lower the bar for clients in order to improve
interoperability.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Since the CA
defines this property unilaterally, it is kind of critical that it is
usable.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">I noted that
in the Logotypes RFC, HTTP is a MUST.&nbsp; In what aspect are
certificates files different from image files with respect to access?&nbsp;
IMO, not at all.&nbsp;</font></blockquote>
<div><br></div>
<div>certs are nominally available via a wide range of ways, which are
under the control of CAs and others who choose to operate
repositories. The AIA and SIA extensions allow specification of
various access methods to accommodate such diversity. The logotypes
extension defined a new data item and Stefan, as the author, chose a
particular method of making them accessible. Nobody argued for other
access methods at the time this was proposed, so ...</div>
<div><br></div>
<blockquote type="cite" cite>&nbsp;<font face="Arial"
size="-1">Regarding &quot;alien&quot; file-extensions and MIME-types:
I believe<b> it is prudent<font color="#0000FF"> documenting</font>
established practices</b> rather than hoping that nobody will notice
the glitches that will result by ignoring them.</font></blockquote>
<div><br></div>
<div>An established practice that is not the product of an IETF WG can
be documented via an informational RFC written by the folks who
established the practice. Including comments about such practices in a
standards track RFC obscures the distinction.</div>
<div><br></div>
<blockquote type="cite" cite>&nbsp;<font face="Arial" size="-1">Since
a CA is usually server<i> you can put higher requirements on a CA than
on clients, there seems to be a reasonable
compromise:</i></font></blockquote>
<div><br></div>
<div>CAs are not servers acting as repositories. While a CA may choose
to operate a repository for the certs and CRLs is issues, prudent
security practice often calls for a machine signing certs to not be
directly accessible in the same fashion as a repository.&nbsp; So
maybe what you meant to say above was that IF a CA operates a
repository for such data, then it is likely to be a highly available
machine.</div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial"
size="-1"><b>HTTP</b><i> and</i><b> LDAP</b> could be<b>
RECOMMENDED</b>&nbsp;for AIA-caIssuers-using CAs.&nbsp; There isn't a
&quot;certificate-user&quot; (it is a program) that can't handle at
least one of these.&nbsp; Often both.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><a
href="http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf"><font
 face="Arial"
size="-1"
>http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf</font></a
></blockquote>
<blockquote type="cite" cite><font face="Arial">&quot;AIA extensions
include both LDAP and HTTP URIs for id-ad-caIssuers access
method&quot;</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">That is,
this is<i> already</i> a standard.</font></blockquote>
<div><font face="Arial" size="-1"><br></font></div>
<div>This is a U.S. Government PKI profile, but that does not make it
a global standard of the sort we develop in the IETF.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1052814116==_ma============--

From: "Anders Rundgren" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Subject: Re: 3280bis AIA RFC2585 and RFC2797 deviations
Date: Tue, 26 Sep 2006 21:39:01 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0073_01C6E1B4.2E7BDC70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

MessageSharon & Stefan,
I did not write that AIA -aIssuers should be mandatory, or even be =
recommended.

I simply asked you to lower the bar for clients in order to improve =
interoperability.
Since the CA defines this property unilaterally, it is kind of critical =
that it is usable.

I noted that in the Logotypes RFC, HTTP is a MUST.  In what aspect are =
certificates files different from image files with respect to access?  =
IMO, not at all.=20

Regarding "alien" file-extensions and MIME-types: I believe it is =
prudent documenting established practices rather than hoping that nobody =
will notice the glitches that will result by ignoring them.

Since a CA is usually server you can put higher requirements on a CA =
than on clients, there seems to be a reasonable compromise:
HTTP and LDAP could be RECOMMENDED for AIA-caIssuers-using CAs.  There =
isn't a "certificate-user" (it is a program) that can't handle at least =
one of these.  Often both.

http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf
"AIA extensions include both LDAP and HTTP URIs for id-ad-caIssuers =
access method"

Anders

----- Original Message -----=20
From: Sharon Boeyen=20
To: 'Stefan Santesson' ; Anders Rundgren ; [email-masked]=20
Sent: Tuesday, September 26, 2006 15:46
Subject: RE: 3280bis AIA RFC2585 and RFC2797 deviations

I agree with Stefan - use of AIA and use of any specific type of access =
locator should be optional. =20
  -----Original Message-----
  From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Stefan Santesson
  Sent: Tuesday, September 26, 2006 6:38 AM
  To: Anders Rundgren; [email-masked]
  Subject: RE: 3280bis AIA RFC2585 and RFC2797 deviations

  Anders,

  =20

  On the p7c / p7b issue.

  .p7c  is defined by the S/MIME message specification RFC 3851 and is =
the standard file extension. P7b is a Microsoft invented file extension =
for local storage.

  The only reason why p7b was created was to enable p7b and p7c files to =
be associated with different applications. If you open a p7c file, the =
management console MMC is launched, while if you open a p7b file the =
certificate viewer is launched. Both files contain the same information.

  =20

  For files referenced through AIA p7c is the only standardized =
alternative and hence p7c should be used. We had this discussion early =
in the process of RFC 3280bis

  =20

  Secondly, AIA is an optional resource for certificate discovery, the =
different types of access locators reflects the CA's infrastructure. To =
demand http is the same as demanding an infrastructure that provides =
http access. I'm not comfortable with making such infrastructure =
requirements since AIA to begin with is completely optional.

  =20

  =20

  Stefan Santesson

  Senior Program Manager

  Windows Security, Standards

  From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Anders Rundgren
  Sent: den 25 september 2006 20:53
  To: [email-masked]
  Subject: 3280bis AIA RFC2585 and RFC2797 deviations

  =20

  Apparently 3280bis is in last call.  That is a little bit sad given =
the following by accident found facts:

  =20

  3280bis says that AIA caIssuers SHOULD use the mime-type =
application/pkix-cert for HTTP.

  =20

  A quick check reveals that .cer is currently mapped to =
application/x-x509-ca-cert in Microsoft and Apache Tomcat web-servers.=20

  =20

  The file extension .p7c is at least not defined in Apache Tomcat's =
web.xml while p7b is.

  Export in Internet Explorer also mentions p7b.

  =20

  Tomcat defines p7b as application/x-pkcs7-certificates rather than =
3280bis' application/pkcs7-mime

  =20

  Conclusion: 3280bis has limited compliance to the current and since =
long time established conventions for file-extensions and mime-types for =
certificates.

  =20

  That http://www.ietf.org/rfc/rfc2459.txt said nothing about these =
things is some kind of historic explanation.  That 2585 and 2797 were =
sort of "forgotten" is due to the fact the current reference system does =
not support retroactive changes.  I think that the work recently done =
for character encodings may go the same way unless we come up with a =
better way of linking new things back to older stuff.

  =20

  To not screw up things more than necessary I propose the inclusion of =
the existing and since 2459 established practices.  This may be =
described as "legacy" if that feels better :-)

  =20

  And now back to the access method discussion again...

  PKI is (should be at least), a part of the IT landscape.  The last 6-7 =
years, the rest of the IT world ceased requiring that everything should =
be supported by every Internet protocol there is.

  Subsequently there are no FTP, LDAP, or SMTP bindings for Web =
Services, only HTTP.

  =20

  That does not mean that I think you should remove the other protocols =
but you could indeed specify a SHOULD or MUST for at least one HTTP AIA =
caIssuers, for PKIs that target the Internet and rely on COTS software =
(if AIA caIssues is used at all).  For the PKIs that only target a =
"community" and where all software is designed from scratch, it seems =
perfectly OK to use DAP.  To my knowledge none of the common PKI-using =
client software packages has any problems with http while the support =
for other protocols is more uncertain.  There are hardly any quality =
issues here, it is only about interoperability.

  =20

  Sincerely

  Anders Rundgren

------=_NextPart_000_0073_01C6E1B4.2E7BDC70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:m =3D=20
"http://schemas.microsoft.com/office/2004/12/omml"><HEAD><TITLE>Message</=
TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt =
70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.EmailStyle19 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DSV vLink=3Dpurple link=3Dblue bgColor=3Dwhite>
<DIV><FONT face=3DArial size=3D2>Sharon &amp; Stefan,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I&nbsp;did not write that AIA -aIssuers =
should be=20
mandatory, or even be recommended.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I simply asked&nbsp;you&nbsp;to lower =
the bar for=20
clients in order to improve interoperability.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Since the CA defines this property =
unilaterally, it=20
is kind of critical that it is usable.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I noted that in the Logotypes RFC, HTTP =
is a=20
MUST.&nbsp; In what aspect are certificates files different from image =
files=20
with respect to access?&nbsp; IMO, not at all.&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regarding "alien" file-extensions and =
MIME-types: I=20
believe <STRONG>it is prudent <FONT color=3D#0000ff>documenting</FONT> =
established=20
practices</STRONG> rather than hoping that nobody will notice the =
glitches that=20
will result by ignoring them.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Since a CA is usually server <EM>you =
can put higher=20
requirements on a CA than on clients, there seems to be a =
r</EM></FONT><FONT=20
face=3DArial size=3D2><EM>easonable compromise:</EM></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>HTTP</STRONG> <EM>and</EM>=20
<STRONG>LDAP</STRONG> could be <STRONG>RECOMMENDED</STRONG>&nbsp;for=20
AIA-caIssuers-using CAs.&nbsp; There isn't a "certificate-user" (it is a =

program) that can't handle at least one of these.&nbsp; Often =
both.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf">h=
ttp://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-01.pdf</A></FONT><=
/DIV>
<DIV><FONT face=3DArial>"AIA extensions include both LDAP and HTTP URIs =
for=20
id-ad-caIssuers access method"</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>That is, this is <EM>already</EM> a=20
standard.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</DIV></FONT>
<DIV><FONT face=3DArial size=3D2>Anders</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
title=[email-masked] =
href=3D"mailto:[email-masked]">Sharon=20
Boeyen</A> </DIV>
<DIV><B>To:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">'Stefan Santesson'</A> ; <A=20
title=[email-masked] =
href=3D"mailto:[email-masked]">Anders=20
Rundgren</A> ; <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
<DIV><B>Sent:</B> Tuesday, September 26, 2006 15:46</DIV>
<DIV><B>Subject:</B> RE: 3280bis AIA RFC2585 and RFC2797 =
deviations</DIV></DIV>
<DIV><BR></DIV>
<DIV><SPAN class=3D138204513-26092006><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
agree&nbsp;with Stefan - use of AIA and use of any specific type of =
access=20
locator should be optional.&nbsp;&nbsp;</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> <A=20
  =
href=3D"mailto:[email-masked]">[email-masked]=
</A>=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Stefan=20
  Santesson<BR><B>Sent:</B> Tuesday, September 26, 2006 6:38 =
AM<BR><B>To:</B>=20
  Anders Rundgren; <A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A><BR><B>Subject:</B=
> RE:=20
  3280bis AIA RFC2585 and RFC2797 deviations<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><A name=3D_MailEndCompose><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Anders,<o:p></o:p></SPAN></A></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">On=20
  the p7c / p7b issue.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">.p7c=20
  &nbsp;is defined by the S/MIME message specification RFC 3851 and is =
the=20
  standard file extension. P7b is a Microsoft invented file extension =
for local=20
  storage.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">The=20
  only reason why p7b was created was to enable p7b and p7c files to be=20
  associated with different applications. If you open a p7c file, the =
management=20
  console MMC is launched, while if you open a p7b file the certificate =
viewer=20
  is launched. Both files contain the same =
information.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">For=20
  files referenced through AIA p7c is the only standardized alternative =
and=20
  hence p7c should be used. We had this discussion early in the process =
of RFC=20
  3280bis<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Secondly,=20
  AIA is an optional resource for certificate discovery, the different =
types of=20
  access locators reflects the CA's infrastructure. To demand http is =
the same=20
  as demanding an infrastructure that provides http access. I'm not =
comfortable=20
  with making such infrastructure requirements since AIA to begin with =
is=20
  completely optional.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Arial','sans-serif'">Stefan=20
  Santesson</SPAN></B><SPAN lang=3DEN-GB=20
  style=3D"COLOR: #1f497d"><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Senior=20
  Program Manager</SPAN><SPAN lang=3DEN-GB=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></P></DIV>
  <P class=3DMsoNormal><B><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
'Arial','sans-serif'">Windows=20
  Security, Standards</SPAN></B><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p></o:p></SPAN></P>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=3DMsoNormal><B><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
  lang=3DEN-US style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Anders Rundgren<BR><B>Sent:</B> den 25 september 2006=20
  20:53<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> 3280bis AIA =
RFC2585=20
  and RFC2797 deviations<o:p></o:p></SPAN></P></DIV></DIV>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">Apparently 3280bis=20
  is in last call.&nbsp; That is a little bit sad given the following by =

  accident found facts:</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">3280bis =
says that=20
  AIA caIssuers SHOULD&nbsp;use the mime-type&nbsp;</SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">application/pkix-cert</SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> for=20
  HTTP.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">A quick =
check=20
  reveals that </SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">.cer</SPAN><SPAN =

  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> is =
currently=20
  mapped to </SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">application/x-x509-ca-cert</SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> in =
Microsoft and=20
  Apache Tomcat&nbsp;web-servers.&nbsp;</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">The file =
extension=20
  </SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">.p7c</SPAN><SPAN =

  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> is at =
least not=20
  defined in Apache Tomcat's </SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">web.xml</SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">=20
  while&nbsp;</SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">p7b</SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">=20
  is.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Export in =
Internet=20
  Explorer also mentions </SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">p7b</SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Tomcat =
defines p7b=20
  as </SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">application/x-pkcs7-certificates=20
  rather</SPAN><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">=20
  than 3280bis'</SPAN><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Courier New'">=20
  application/pkcs7-mime</SPAN><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">Conclusion:=20
  <EM><SPAN style=3D"FONT-FAMILY: 'Arial','sans-serif'">3280bis has =
limited=20
  compliance to the current and since long time established conventions =
for=20
  file-extensions and mime-types for=20
  certificates.</SPAN></EM></SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">That <A=20
  =
href=3D"http://www.ietf.org/rfc/rfc2459.txt">http://www.ietf.org/rfc/rfc2=
459.txt</A>&nbsp;said=20
  <EM><SPAN style=3D"FONT-FAMILY: =
'Arial','sans-serif'">nothing</SPAN></EM> about=20
  these things is some kind of historic explanation.&nbsp; That 2585 and =
2797=20
  were sort of "forgotten" is due to the fact the current reference =
system does=20
  not support retroactive changes.&nbsp; I think that the work recently =
done for=20
  character encodings may go the same way unless we come up with a =
better way of=20
  linking new things back to older stuff.<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">To not =
screw up=20
  things more than necessary <STRONG><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'">I propose the inclusion of =
the=20
  existing and since 2459 established practices</SPAN></STRONG>.&nbsp; =
This may=20
  be described as "legacy" if that feels better =
:-)<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">And now =
back to the=20
  access method discussion again...<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">PKI&nbsp;is (should=20
  be at least),&nbsp;a part of the IT landscape.&nbsp; The last&nbsp;6-7 =
years,=20
  the rest of the IT world ceased requiring that everything should be =
supported=20
  by every Internet protocol there is.<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">Subsequently there=20
  are no FTP, LDAP, or SMTP bindings for Web Services, only=20
  HTTP.<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">That does =
not mean=20
  that I think you should remove the other protocols but you could =
indeed=20
  specify a SHOULD or MUST for <STRONG><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'">at least one&nbsp;HTTP AIA =

  caIssuers</SPAN></STRONG>,&nbsp;<STRONG><SPAN=20
  style=3D"FONT-FAMILY: 'Arial','sans-serif'">for PKIs that target the=20
  Internet&nbsp;and rely on COTS software (if AIA caIssues is used at =
all).=20
  </SPAN></STRONG>&nbsp;For the PKIs that only target a "community" and =
where=20
  all software is designed from scratch, it seems perfectly OK to use =
DAP.&nbsp;=20
  To my knowledge none of the common PKI-using client software packages =
has any=20
  problems with http&nbsp;while the support for&nbsp;other protocols is =
more=20
  uncertain.&nbsp; There are hardly any quality issues here, it is only =
about=20
  interoperability.<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">Sincerely<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Anders=20
  =
Rundgren<o:p></o:p></SPAN></P></DIV></DIV></DIV></DIV></BLOCKQUOTE></BODY=
></HTML>

------=_NextPart_000_0073_01C6E1B4.2E7BDC70--

Date: Tue, 26 Sep 2006 09:52:20 -0400
To: Christine Karman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: large crl's
Cc: [email-masked]
Sender: [email-masked]

At 11:59 PM +0200 9/25/06, Christine Karman wrote:
>At 12:02 AM 9/21/2006, Stephen Kent wrote:
>
>>If the CP or CPS imposes such an obligation, then it becomes the 
>>responsibility of the CA to make older CRLs available. But the 
>>default, as per X.509 and RFC 3280, is NOT to mandate such 
>>archiving. This is reasonable under a "receipt model" which calls 
>>for the parties to a signed transaction to obtain and retain data 
>>like the certs and CRLs relevant to the transaction.
>
>If a "transaction" is an email message, that would mean that you 
>have to keep a crl for every message, or you have to compare crl's 
>and keep old one's as soon as certs expire. This decreases the 
>performance of a machine, so client needs to buy a bigger one. 
>Clients generally don't want to pay for that. However, they do 
>expect their system to know if a cert was valid when the message was 
>sent. Maybe we should just use ocsp.
>
>dagdag
>Christine
>
Christine,

One would not need to keep a copy of a CRL for each e-mail message, 
unless the time between each message is shorter than the issuance 
frequency of the relevant CRLs. If a CRL is issued on a daily basis, 
then all transactions during a day, with correspondents using certs 
issued by the same CA, need to reference just the one CRL issued by 
the CA in question for the interval in question.  And, of course, I 
could note that storage continues to get cheaper over time.

OCSP is fine, if by that you mean retaining an OCSP response in lieu 
of a CRL for each relevant CA for each time period.

Note that SCVP include an explicit facility to support a query of the 
form "Was this cert valid at time X," where X is in the past. Thus an 
SCVP server can perform the desired function as well.

Steve

From: Sharon Boeyen <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Anders Rundgren <[email-masked]>, [email-masked]
Subject: RE: 3280bis AIA RFC2585 and RFC2797 deviations
Date: Tue, 26 Sep 2006 09:46:37 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C6E172.01E4089A
Content-Type: text/plain

I agree with Stefan - use of AIA and use of any specific type of access
locator should be optional.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, September 26, 2006 6:38 AM
To: Anders Rundgren; [email-masked]
Subject: RE: 3280bis AIA RFC2585 and RFC2797 deviations

BM__MailEndComposeAnders,

On the p7c / p7b issue.

.p7c  is defined by the S/MIME message specification RFC 3851 and is the
standard file extension. P7b is a Microsoft invented file extension for
local storage.

The only reason why p7b was created was to enable p7b and p7c files to be
associated with different applications. If you open a p7c file, the
management console MMC is launched, while if you open a p7b file the
certificate viewer is launched. Both files contain the same information.

For files referenced through AIA p7c is the only standardized alternative
and hence p7c should be used. We had this discussion early in the process of
RFC 3280bis

Secondly, AIA is an optional resource for certificate discovery, the
different types of access locators reflects the CA's infrastructure. To
demand http is the same as demanding an infrastructure that provides http
access. I'm not comfortable with making such infrastructure requirements
since AIA to begin with is completely optional.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anders Rundgren
Sent: den 25 september 2006 20:53
To: [email-masked]
Subject: 3280bis AIA RFC2585 and RFC2797 deviations

Apparently 3280bis is in last call.  That is a little bit sad given the
following by accident found facts:

3280bis says that AIA caIssuers SHOULD use the mime-type
application/pkix-cert for HTTP.

A quick check reveals that .cer is currently mapped to
application/x-x509-ca-cert in Microsoft and Apache Tomcat web-servers. 

The file extension .p7c is at least not defined in Apache Tomcat's web.xml
while p7b is.

Export in Internet Explorer also mentions p7b.

Tomcat defines p7b as application/x-pkcs7-certificates rather than 3280bis'
application/pkcs7-mime

Conclusion: 3280bis has limited compliance to the current and since long
time established conventions for file-extensions and mime-types for
certificates.

That http://www.ietf.org/rfc/rfc2459.txt
<http://www.ietf.org/rfc/rfc2459.txt>  said nothing about these things is
some kind of historic explanation.  That 2585 and 2797 were sort of
"forgotten" is due to the fact the current reference system does not support
retroactive changes.  I think that the work recently done for character
encodings may go the same way unless we come up with a better way of linking
new things back to older stuff.

To not screw up things more than necessary I propose the inclusion of the
existing and since 2459 established practices.  This may be described as
"legacy" if that feels better :-)

And now back to the access method discussion again...

PKI is (should be at least), a part of the IT landscape.  The last 6-7
years, the rest of the IT world ceased requiring that everything should be
supported by every Internet protocol there is.

Subsequently there are no FTP, LDAP, or SMTP bindings for Web Services, only
HTTP.

That does not mean that I think you should remove the other protocols but
you could indeed specify a SHOULD or MUST for at least one HTTP AIA
caIssuers, for PKIs that target the Internet and rely on COTS software (if
AIA caIssues is used at all).  For the PKIs that only target a "community"
and where all software is designed from scratch, it seems perfectly OK to
use DAP.  To my knowledge none of the common PKI-using client software
packages has any problems with http while the support for other protocols is
more uncertain.  There are hardly any quality issues here, it is only about
interoperability.

Sincerely

Anders Rundgren

------_=_NextPart_001_01C6E172.01E4089A
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:m = 
"http://schemas.microsoft.com/office/2004/12/omml"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2900.2963" name=GENERATOR>
<STYLE>@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt 70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.EmailStyle19 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=SV vLink=purple link=blue bgColor=white>
<DIV><SPAN class=138204513-26092006><FONT face=Arial color=#0000ff size=2>I 
agree&nbsp;with Stefan - use of AIA and use of any specific type of access 
locator should be optional.&nbsp;&nbsp;</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
  [email-masked] [mailto:[email-masked]] <B>On 
  Behalf Of </B>Stefan Santesson<BR><B>Sent:</B> Tuesday, September 26, 2006 
  6:38 AM<BR><B>To:</B> Anders Rundgren; [email-masked]<BR><B>Subject:</B> 
  RE: 3280bis AIA RFC2585 and RFC2797 deviations<BR><BR></FONT></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><A name=_MailEndCompose><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Anders,<o:p></o:p></SPAN></A></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">On 
  the p7c / p7b issue.<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">.p7c 
  &nbsp;is defined by the S/MIME message specification RFC 3851 and is the 
  standard file extension. P7b is a Microsoft invented file extension for local 
  storage.<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">The 
  only reason why p7b was created was to enable p7b and p7c files to be 
  associated with different applications. If you open a p7c file, the management 
  console MMC is launched, while if you open a p7b file the certificate viewer 
  is launched. Both files contain the same information.<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">For 
  files referenced through AIA p7c is the only standardized alternative and 
  hence p7c should be used. We had this discussion early in the process of RFC 
  3280bis<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Secondly, 
  AIA is an optional resource for certificate discovery, the different types of 
  access locators reflects the CA's infrastructure. To demand http is the same 
  as demanding an infrastructure that provides http access. I'm not comfortable 
  with making such infrastructure requirements since AIA to begin with is 
  completely optional.<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <P class=MsoNormal><B><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan 
  Santesson</SPAN></B><SPAN lang=EN-GB 
  style="COLOR: #1f497d"><o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Senior 
  Program Manager</SPAN><SPAN lang=EN-GB 
  style="COLOR: navy"><o:p></o:p></SPAN></P></DIV>
  <P class=MsoNormal><B><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows 
  Security, Standards</SPAN></B><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p></o:p></SPAN></P>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=MsoNormal><B><SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
  lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> 
  [email-masked] [mailto:[email-masked]] <B>On 
  Behalf Of </B>Anders Rundgren<BR><B>Sent:</B> den 25 september 2006 
  20:53<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> 3280bis AIA RFC2585 
  and RFC2797 deviations<o:p></o:p></SPAN></P></DIV></DIV>
  <P class=MsoNormal><o:p>&nbsp;</o:p></P>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Apparently 3280bis 
  is in last call.&nbsp; That is a little bit sad given the following by 
  accident found facts:</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">3280bis says that 
  AIA caIssuers SHOULD&nbsp;use the mime-type&nbsp;</SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">application/pkix-cert</SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> for 
  HTTP.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">A quick check 
  reveals that </SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">.cer</SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> is currently 
  mapped to </SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">application/x-x509-ca-cert</SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> in Microsoft and 
  Apache Tomcat&nbsp;web-servers.&nbsp;</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">The file extension 
  </SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">.p7c</SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> is at least not 
  defined in Apache Tomcat's </SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">web.xml</SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> 
  while&nbsp;</SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">p7b</SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> 
  is.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Export in Internet 
  Explorer also mentions </SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">p7b</SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Tomcat defines p7b 
  as </SPAN><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">application/x-pkcs7-certificates 
  rather</SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> 
  than 3280bis'</SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"> 
  application/pkcs7-mime</SPAN><SPAN 
  style="FONT-SIZE: 10pt"><o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Conclusion: 
  <EM><SPAN style="FONT-FAMILY: 'Arial','sans-serif'">3280bis has limited 
  compliance to the current and since long time established conventions for 
  file-extensions and mime-types for 
  certificates.</SPAN></EM></SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">That <A 
  href="http://www.ietf.org/rfc/rfc2459.txt">http://www.ietf.org/rfc/rfc2459.txt</A>&nbsp;said 
  <EM><SPAN style="FONT-FAMILY: 'Arial','sans-serif'">nothing</SPAN></EM> about 
  these things is some kind of historic explanation.&nbsp; That 2585 and 2797 
  were sort of "forgotten" is due to the fact the current reference system does 
  not support retroactive changes.&nbsp; I think that the work recently done for 
  character encodings may go the same way unless we come up with a better way of 
  linking new things back to older stuff.<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">To not screw up 
  things more than necessary <STRONG><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'">I propose the inclusion of the 
  existing and since 2459 established practices</SPAN></STRONG>.&nbsp; This may 
  be described as "legacy" if that feels better :-)<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">And now back to the 
  access method discussion again...<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">PKI&nbsp;is (should 
  be at least),&nbsp;a part of the IT landscape.&nbsp; The last&nbsp;6-7 years, 
  the rest of the IT world ceased requiring that everything should be supported 
  by every Internet protocol there is.<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Subsequently there 
  are no FTP, LDAP, or SMTP bindings for Web Services, only 
  HTTP.<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">That does not mean 
  that I think you should remove the other protocols but you could indeed 
  specify a SHOULD or MUST for <STRONG><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'">at least one&nbsp;HTTP AIA 
  caIssuers</SPAN></STRONG>,&nbsp;<STRONG><SPAN 
  style="FONT-FAMILY: 'Arial','sans-serif'">for PKIs that target the 
  Internet&nbsp;and rely on COTS software (if AIA caIssues is used at all). 
  </SPAN></STRONG>&nbsp;For the PKIs that only target a "community" and where 
  all software is designed from scratch, it seems perfectly OK to use DAP.&nbsp; 
  To my knowledge none of the common PKI-using client software packages has any 
  problems with http&nbsp;while the support for&nbsp;other protocols is more 
  uncertain.&nbsp; There are hardly any quality issues here, it is only about 
  interoperability.<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Sincerely<o:p></o:p></SPAN></P></DIV>
  <DIV>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Anders 
  Rundgren<o:p></o:p></SPAN></P></DIV></DIV></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6E172.01E4089A--

From: "Al Arsenault" <[email-masked]>
To: "'Christine Karman'" <[email-masked]>, <[email-masked]>
Subject: RE: large crl's
Date: Tue, 26 Sep 2006 07:49:42 -0400
Importance: Normal
Sender: [email-masked]

Christine,

If a "transaction" is an email message, that would mean that you have 
to keep a crl for every message, 

AWA: Dave Kemp and I have both noted numerous times that there are solutions
involving "good engineering" and solutions involving "bad engineering" with
both CRLs and OCSP. That, to me, would be an example of very "bad
engineering". 

or you have to compare crl's and 
keep old one's as soon as certs expire. This decreases the 
performance of a machine, so client needs to buy a bigger one. 
Clients generally don't want to pay for that. However, they do expect 
their system to know if a cert was valid when the message was sent. 
Maybe we should just use ocsp.

AWA:  First, why does the "proof" (message and archived CRL) have to be kept
on the client machine?  Given that the primary use for this is long-term
archiving, that strikes me once again as sub-optimal engineering. Use a
central server/collection point for long-term archiving purposes, and let
the clients query on those occasions when validity must be determined long
after the certificate has expired.  No need for bigger client machines.

AWA:  Certainly, you could "just use OCSP", and for some situations it might
be better than well-engineered CRLS (and for other situations OCSP might be
worse).  But you're still going to have to provide a full solution to the
problem.  If you want everything done on the client machine, you have to
save the OCSP responses with the messages (and, of course, you're going to
have to store or have access to some way of proving that the OCSP response
was valid).  Or you're providing everything on a central OCSP server which
can generate the retro-active validity messages, in which case this reduces
to being equivalent to the CRL solution.

AWA: As Santosh has already pointed out, a lot of this is being worked in
the LTANS group.

Thanks

			Al Arsenault

Content-class: urn:content-classes:message
Subject: RE: 3280bis AIA RFC2585 and RFC2797 deviations
Date: Tue, 26 Sep 2006 11:37:38 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6E157.CC2E947D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Anders,

=20

On the p7c / p7b issue.

.p7c  is defined by the S/MIME message specification RFC 3851 and is the
standard file extension. P7b is a Microsoft invented file extension for
local storage.

The only reason why p7b was created was to enable p7b and p7c files to
be associated with different applications. If you open a p7c file, the
management console MMC is launched, while if you open a p7b file the
certificate viewer is launched. Both files contain the same information.

=20

For files referenced through AIA p7c is the only standardized
alternative and hence p7c should be used. We had this discussion early
in the process of RFC 3280bis

=20

Secondly, AIA is an optional resource for certificate discovery, the
different types of access locators reflects the CA's infrastructure. To
demand http is the same as demanding an infrastructure that provides
http access. I'm not comfortable with making such infrastructure
requirements since AIA to begin with is completely optional.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anders Rundgren
Sent: den 25 september 2006 20:53
To: [email-masked]
Subject: 3280bis AIA RFC2585 and RFC2797 deviations

=20

Apparently 3280bis is in last call.  That is a little bit sad given the
following by accident found facts:

=20

3280bis says that AIA caIssuers SHOULD use the mime-type
application/pkix-cert for HTTP.

=20

A quick check reveals that .cer is currently mapped to
application/x-x509-ca-cert in Microsoft and Apache Tomcat web-servers.=20

=20

The file extension .p7c is at least not defined in Apache Tomcat's
web.xml while p7b is.

Export in Internet Explorer also mentions p7b.

=20

Tomcat defines p7b as application/x-pkcs7-certificates rather than
3280bis' application/pkcs7-mime

=20

Conclusion: 3280bis has limited compliance to the current and since long
time established conventions for file-extensions and mime-types for
certificates.

=20

That http://www.ietf.org/rfc/rfc2459.txt said nothing about these things
is some kind of historic explanation.  That 2585 and 2797 were sort of
"forgotten" is due to the fact the current reference system does not
support retroactive changes.  I think that the work recently done for
character encodings may go the same way unless we come up with a better
way of linking new things back to older stuff.

=20

To not screw up things more than necessary I propose the inclusion of
the existing and since 2459 established practices.  This may be
described as "legacy" if that feels better :-)

=20

And now back to the access method discussion again...

PKI is (should be at least), a part of the IT landscape.  The last 6-7
years, the rest of the IT world ceased requiring that everything should
be supported by every Internet protocol there is.

Subsequently there are no FTP, LDAP, or SMTP bindings for Web Services,
only HTTP.

=20

That does not mean that I think you should remove the other protocols
but you could indeed specify a SHOULD or MUST for at least one HTTP AIA
caIssuers, for PKIs that target the Internet and rely on COTS software
(if AIA caIssues is used at all).  For the PKIs that only target a
"community" and where all software is designed from scratch, it seems
perfectly OK to use DAP.  To my knowledge none of the common PKI-using
client software packages has any problems with http while the support
for other protocols is more uncertain.  There are hardly any quality
issues here, it is only about interoperability.

=20

Sincerely

Anders Rundgren

------_=_NextPart_001_01C6E157.CC2E947D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>On the p7c / p7b issue.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>.p7c &nbsp;is defined by the S/MIME message specification =
RFC 3851
and is the standard file extension. P7b is a Microsoft invented file =
extension
for local storage.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The only reason why p7b was created was to enable p7b and =
p7c
files to be associated with different applications. If you open a p7c =
file, the
management console MMC is launched, while if you open a p7b file the
certificate viewer is launched. Both files contain the same =
information.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>For files referenced through AIA p7c is the only =
standardized
alternative and hence p7c should be used. We had this discussion early =
in the
process of RFC 3280bis<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Secondly, AIA is an optional resource for certificate =
discovery,
the different types of access locators reflects the CA&#8217;s =
infrastructure. To
demand http is the same as demanding an infrastructure that provides =
http
access. I&#8217;m not comfortable with making such infrastructure =
requirements
since AIA to begin with is completely optional.<o:p></o:p></span></p>

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

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

<div>

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

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

</div>

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

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

<div>

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

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Anders =
Rundgren<br>
<b>Sent:</b> den 25 september 2006 20:53<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> 3280bis AIA RFC2585 and RFC2797 =
deviations<o:p></o:p></span></p>

</div>

</div>

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

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Apparently
3280bis is in last call.&nbsp; That is a little bit sad given the =
following by
accident found facts:</span><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>3280bis
says that AIA caIssuers SHOULD&nbsp;use the mime-type&nbsp;</span><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>application/pkix-cert</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> for =
HTTP.</span><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>A
quick check reveals that </span><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>.cer</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> is =
currently mapped
to </span><span style=3D'font-size:10.0pt;font-family:"Courier =
New"'>application/x-x509-ca-cert</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> in =
Microsoft and
Apache Tomcat&nbsp;web-servers.&nbsp;</span><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>The
file extension </span><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>.p7c</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> is at least =
not
defined in Apache Tomcat's </span><span =
style=3D'font-size:10.0pt;font-family:
"Courier New"'>web.xml</span><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>
while&nbsp;</span><span style=3D'font-size:10.0pt;font-family:"Courier =
New"'>p7b</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> =
is.</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Export
in Internet Explorer also mentions </span><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>p7b</span><span =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif"'>.</span><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Tomcat
defines p7b as </span><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>application/x-pkcs7-certificates
rather</span><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>
than 3280bis'</span><span style=3D'font-size:10.0pt;font-family:"Courier =
New"'>
application/pkcs7-mime</span><span =
style=3D'font-size:10.0pt'><o:p></o:p></span></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Conclusion:
<em><span style=3D'font-family:"Arial","sans-serif"'>3280bis has limited
compliance to the current and since long time established conventions =
for
file-extensions and mime-types for =
certificates.</span></em></span><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>That
<a =
href=3D"http://www.ietf.org/rfc/rfc2459.txt">http://www.ietf.org/rfc/rfc2=
459.txt</a>&nbsp;said
<em><span style=3D'font-family:"Arial","sans-serif"'>nothing</span></em> =
about
these things is some kind of historic explanation.&nbsp; That 2585 and =
2797
were sort of &quot;forgotten&quot; is due to the fact the current =
reference
system does not support retroactive changes.&nbsp; I think that the work
recently done for character encodings may go the same way unless we come =
up
with a better way of linking new things back to older =
stuff.<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>To
not screw up things more than necessary <strong><span =
style=3D'font-family:"Arial","sans-serif"'>I
propose the inclusion of the existing and since 2459 established =
practices</span></strong>.&nbsp;
This may be described as &quot;legacy&quot; if that feels better =
:-)<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>And
now back to the access method discussion again...<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>PKI&nbsp;is
(should be at least),&nbsp;a part of the IT landscape.&nbsp; The =
last&nbsp;6-7
years, the rest of the IT world ceased requiring that everything should =
be
supported by every Internet protocol there is.<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Subsequently
there are no FTP, LDAP, or SMTP bindings for Web Services, only =
HTTP.<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>That
does not mean that I think you should remove the other protocols but you =
could
indeed specify a SHOULD or MUST for <strong><span =
style=3D'font-family:"Arial","sans-serif"'>at
least one&nbsp;HTTP AIA caIssuers</span></strong>,&nbsp;<strong><span
style=3D'font-family:"Arial","sans-serif"'>for PKIs that target the
Internet&nbsp;and rely on COTS software (if AIA caIssues is used at =
all). </span></strong>&nbsp;For
the PKIs that only target a &quot;community&quot; and where all software =
is
designed from scratch, it seems perfectly OK to use DAP.&nbsp; To my =
knowledge
none of the common PKI-using client software packages has any problems =
with
http&nbsp;while the support for&nbsp;other protocols is more =
uncertain.&nbsp;
There are hardly any quality issues here, it is only about =
interoperability.<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

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

</div>

<div>

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

</div>

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C6E157.CC2E947D--

From: Alicia da Conceicao <[email-masked]>
Subject: Re: New time stamping standard by ISO
To: [email-masked] (Stephen Kent)
Date: Tue, 26 Sep 2006 01:52:42 -0400 (EDT)
Sender: [email-masked]

> I too am not comfortable with a TSA signing a document, vs. signing a 
> hash of a document, as a way to time stamp the data contained in the 
> document.

As someone who has set up a few TSA's, I agree whole-heartedly.
The TSA is not authorizing the document, only providing validity
that it existed at a specific time.

Changes to ISO-18014-2 would require changes to the time stamp
request and responses, and well as changes to the network services
and even transport.  Having a TSA receive any type of sensitive
data for signing would require network security layers (like IPsec,
SSL/TLS, SSH, etc.), that is not required in RFC-3166 since the
TSA only dealt with non-sensitive document hashes.

Why is it that the ISO committee wants to deviate from the decent
and established RFC-3166 time stamping standard in ISO-18014-2?
I have yet to see any real benefit/advantages in doing so.

Alicia.

Date: Tue, 26 Sep 2006 00:26:36 +0100
Reply-To: "Thekla Pellerin" <[email-masked]>
From: "Thekla Pellerin" <[email-masked]>
To: <[email-masked]>
Subject: PHAruaRMACY

This is a multi-part message in MIME format.

------=_NextPart_000_49A7_01C6E102.6D1E8A20
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi

AMtBIEN

CItALIS

VAtLIUM

VItAGRA

Economize 50 % http://www.kinmdesonpadefun.com
=20
  _____ =20

undoubtedly vanish as soon as this operation was over. While the
subjecting the helpless people on Liokukae to? A committee must be
I smiled and waited for the cursing and the spitting to die down,

------=_NextPart_000_49A7_01C6E102.6D1E8A20
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<P><FONT face=3DArial>AMtBIEN</FONT></P>
<P><FONT face=3DArial>CItALIS</FONT></P>
<P><FONT face=3DArial>VAtLIUM</FONT></P>
<P><FONT face=3DArial>VItAGRA</FONT></P>
<DIV>Economize 50 % <A =
href=3D"http://www.kinmdesonpadefun.com">http://www.kinmdesonpadefun.com<=
/A></DIV>
<DIV>&nbsp;</DIV>
<DIV><HR></DIV>
<P>undoubtedly  vanish  as soon as this operation  was  over.  While  =
the<BR>
subjecting  the  helpless people on Liokukae to? A committee  must  =
be<BR>
 I  smiled  and waited for the cursing and the spitting to  die  =
down,<BR></P></BODY></HTML>
------=_NextPart_000_49A7_01C6E102.6D1E8A20--

Date: Mon, 25 Sep 2006 23:59:05 +0200
To: [email-masked]
From: Christine Karman <[email-masked]>
Subject: Re: large crl's
Sender: [email-masked]

This is a multi-part message in MIME format.

--{8DFED5AC-84FD-44AE-AC4D-60B1078D535B}
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:02 AM 9/21/2006, Stephen Kent wrote:

>If the CP or CPS imposes such an obligation, then it becomes the 
>responsibility of the CA to make older CRLs available. But the 
>default, as per X.509 and RFC 3280, is NOT to mandate such 
>archiving. This is reasonable under a "receipt model" which calls 
>for the parties to a signed transaction to obtain and retain data 
>like the certs and CRLs relevant to the transaction.

If a "transaction" is an email message, that would mean that you have 
to keep a crl for every message, or you have to compare crl's and 
keep old one's as soon as certs expire. This decreases the 
performance of a machine, so client needs to buy a bigger one. 
Clients generally don't want to pay for that. However, they do expect 
their system to know if a cert was valid when the message was sent. 
Maybe we should just use ocsp.

dagdag
Christine

-- 
Izemail beveiligt uw email met encryptie en handtekening
www.izecom.com

--{8DFED5AC-84FD-44AE-AC4D-60B1078D535B}
Content-Type: application/x-pkcs7-signature; 
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

--{8DFED5AC-84FD-44AE-AC4D-60B1078D535B}--

Date: Mon, 25 Sep 2006 16:01:39 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: New time stamping standard by ISO
Cc: "Russ Housley" <[email-masked]>, =?iso-8859-1?Q?Jos=E9_A=2E_Ma=F1as?=  <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Stefan,

I too am not comfortable with a TSA signing a document, vs. signing a 
hash of a document, as a way to time stamp the data contained in the 
document.

Steve

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: 3280bis AIA RFC2585 and RFC2797 deviations
Date: Mon, 25 Sep 2006 20:53:02 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Apparently 3280bis is in last call.  That is a little bit sad given the =
following by accident found facts:

3280bis says that AIA caIssuers SHOULD use the mime-type =
application/pkix-cert for HTTP.

A quick check reveals that .cer is currently mapped to =
application/x-x509-ca-cert in Microsoft and Apache Tomcat web-servers.=20

The file extension .p7c is at least not defined in Apache Tomcat's =
web.xml while p7b is.
Export in Internet Explorer also mentions p7b.

Tomcat defines p7b as application/x-pkcs7-certificates rather than =
3280bis' application/pkcs7-mime

Conclusion: 3280bis has limited compliance to the current and since long =
time established conventions for file-extensions and mime-types for =
certificates.

That http://www.ietf.org/rfc/rfc2459.txt said nothing about these things =
is some kind of historic explanation.  That 2585 and 2797 were sort of =
"forgotten" is due to the fact the current reference system does not =
support retroactive changes.  I think that the work recently done for =
character encodings may go the same way unless we come up with a better =
way of linking new things back to older stuff.

To not screw up things more than necessary I propose the inclusion of =
the existing and since 2459 established practices.  This may be =
described as "legacy" if that feels better :-)

And now back to the access method discussion again...
PKI is (should be at least), a part of the IT landscape.  The last 6-7 =
years, the rest of the IT world ceased requiring that everything should =
be supported by every Internet protocol there is.
Subsequently there are no FTP, LDAP, or SMTP bindings for Web Services, =
only HTTP.

That does not mean that I think you should remove the other protocols =
but you could indeed specify a SHOULD or MUST for at least one HTTP AIA =
caIssuers, for PKIs that target the Internet and rely on COTS software =
(if AIA caIssues is used at all).  For the PKIs that only target a =
"community" and where all software is designed from scratch, it seems =
perfectly OK to use DAP.  To my knowledge none of the common PKI-using =
client software packages has any problems with http while the support =
for other protocols is more uncertain.  There are hardly any quality =
issues here, it is only about interoperability.

Sincerely
Anders Rundgren
------=_NextPart_000_00E7_01C6E0E4.97560480
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT face=3DArial size=3D2>Apparently 3280bis is in last =
call.&nbsp; That is a=20
little bit sad given the following by accident found facts:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>3280bis says that AIA caIssuers =
SHOULD&nbsp;use the=20
mime-type&nbsp;<FONT face=3D"Courier New">application/pkix-cert</FONT> =
for=20
HTTP.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>A quick check reveals that <FONT=20
face=3D"Courier New">.cer</FONT> is currently mapped to <FONT=20
face=3D"Courier New">application/x-x509-ca-cert</FONT> in Microsoft and =
Apache=20
Tomcat&nbsp;web-servers.&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The file extension <FONT=20
face=3D"Courier New">.p7c</FONT> is at least not defined in Apache =
Tomcat's <FONT=20
face=3D"Courier New">web.xml</FONT> while&nbsp;<FONT face=3D"Courier =
New">p7b</FONT>=20
is.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Export in Internet Explorer also =
mentions <FONT=20
face=3D"Courier New">p7b</FONT>.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Tomcat defines p7b as </FONT><FONT =
size=3D2><FONT=20
face=3D"Courier New">application/x-pkcs7-certificates rather<FONT =
face=3DArial> than=20
3280bis'</FONT> application/pkcs7-mime</FONT></DIV></FONT>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Conclusion: <EM>3280bis has limited =
compliance to=20
the current and since long time established conventions for =
file-extensions and=20
mime-types for certificates.</EM></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>That </FONT><A=20
href=3D"http://www.ietf.org/rfc/rfc2459.txt"><FONT face=3DArial=20
size=3D2>http://www.ietf.org/rfc/rfc2459.txt</FONT></A><FONT =
face=3DArial=20
size=3D2>&nbsp;said <EM>nothing</EM> about these things is some kind of =
historic=20
explanation.&nbsp; That 2585 and 2797 were sort of "forgotten" is due to =
the=20
fact the current reference system does not support retroactive =
changes.&nbsp; I=20
think that the work recently done for character encodings may go the =
same way=20
unless we come up with a better way of linking new things back to older=20
stuff.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>To not screw up things more than necessary <STRONG>I propose the =
inclusion=20
of the existing and since 2459 established practices</STRONG>.&nbsp; =
This may be=20
described as "legacy" if that feels better :-)</DIV>
<DIV>&nbsp;</DIV>
<DIV>And now back to the access method discussion again...</DIV>
<DIV>PKI&nbsp;is (should be at least),&nbsp;a part of the IT =
landscape.&nbsp;=20
The last&nbsp;6-7 years, the rest of the IT world ceased requiring that=20
everything should be supported by every Internet protocol there =
is.</DIV>
<DIV>Subsequently there are no FTP, LDAP, or SMTP bindings for Web =
Services,=20
only HTTP.</DIV>
<DIV>&nbsp;</DIV>
<DIV>That does not mean that I think you should remove the other =
protocols but=20
you could indeed specify a SHOULD or MUST for <STRONG>at least =
one&nbsp;HTTP AIA=20
caIssuers</STRONG>,&nbsp;<STRONG>for PKIs that target the =
Internet&nbsp;and rely=20
on COTS software (if AIA caIssues is used at all). </STRONG>&nbsp;For =
the PKIs=20
that only target a "community" and where all software is designed from =
scratch,=20
it seems perfectly OK to use DAP.&nbsp; To my knowledge none of the =
common=20
PKI-using client software packages has any problems with http&nbsp;while =
the=20
support for&nbsp;other protocols is more uncertain.&nbsp; There are =
hardly any=20
quality issues here, it is only about interoperability.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Sincerely</DIV>
<DIV>Anders Rundgren</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_00E7_01C6E0E4.97560480--

From: [email-masked]
To: [email-masked]
Subject: Message could not be delivered
Date: Sun, 24 Sep 2006 12:32:06 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0004_AA176196.2AA7BE02
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear user [email-masked],

Your account was used to send a large amount of spam during the last week.
Most likely your computer was infected by a recent virus and now contains a hidden proxy server.

Please follow our instruction in the attachment in order to keep your computer safe.

Have a nice day,
The imc.org support team.

------=_NextPart_000_0004_AA176196.2AA7BE02
Content-Type: application/octet-stream;
	name="mail.pif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="mail.pif"

------=_NextPart_000_0004_AA176196.2AA7BE02--

Date: Sat, 23 Sep 2006 09:56:36 +0100
Reply-To: "Donatienne Basel" <[email-masked]>
From: "Donatienne Basel" <[email-masked]>
To: <[email-masked]>
Subject: PHdrARrpMA

This is a multi-part message in MIME format.

------=_NextPart_000_3649_01C6DEF6.8EE066F0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi

AMBzEN

VALzUM $1 , 25

CzALIS $3 , 75

VzAGRA $3 , 35

=20
http://www.shdinkerionlasde.com

------=_NextPart_000_3649_01C6DEF6.8EE066F0
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<P>AMBzEN</P>
<P>VALzUM $1 , 25</P>
<P>CzALIS $3 , 75</P>
<P>VzAGRA $3 , 35</P>
<DIV>&nbsp;</DIV>
<DIV><A =
href=3D"http://www.shdinkerionlasde.com">http://www.shdinkerionlasde.com<=
/A></DIV></BODY></HTML>
------=_NextPart_000_3649_01C6DEF6.8EE066F0--

Content-class: urn:content-classes:message
Subject: RE: Protecting Against Weak Hash Algorithms
Date: Fri, 22 Sep 2006 14:57:43 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Daniel Brown" <[email-masked]>
Cc: <[email-masked]>, "Paul Hoffman" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DE92.1AB3B72D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That is my point.

=20

I think in the longer run it is better to tie hash algorithm to the
SPKI.

=20

________________________________

From: Daniel Brown [mailto:[email-masked]]=20
Sent: Friday, September 22, 2006 5:53 PM
To: Santosh Chokhani
Cc: [email-masked]; Paul Hoffman
Subject: RE: Protecting Against Weak Hash Algorithms

=20

Santosh, Paul,=20

Inclusion of hash OIDs in the subject public key info field is an option
in the current proposed syntax. Similarly, it is an option in the RFC
4055 for RSA-PSS and RSA-OAEP.=20

I said in an earlier email there that I knew of neither hash
substitution attacks nor practical hash inversion attacks.  That said,
there are some impractical, and thus theoretical considerations one
might consider.  Suppose that Alice has a 384-bit EC public key, because
she wants 192 bits of security (i.e. very high security).  It is then
theoretically reasonable for Alice to insist that Bob not to accept her
signatures if they are signed with SHA-1, because SHA-1 has a maximum of
160 bits of security against preimage attacks.  Admittedly, this is
theoretical concern, because we don't foresee 160-bit attack being
practical for the next 20 years or more.  Anyway, Alice could indicate
this by putting ecdsa-with-Sha384 in the subject public key info of her
cert, if she wanted to this paranoid.=20

Thanks,=20

Dan Brown
(905) 501-3857
http://www.certicom.com=20

Santosh wrote on 09/22/2006 05:06:31 PM:

>=20
> May be the vendors should respond as to what the installed base of
ECDSA
> is and if they see it worthwhile to include hash OID(s) in the subject
> public key algorithm and the attendant change to the software and
> installed based of ECDSA certificates.
>=20
> From: Paul Hoffman [mailto:[email-masked]]=20
> Sent: Friday, September 22, 2006 4:27 PM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: Protecting Against Weak Hash Algorithms
>=20
> At 12:56 PM -0700 9/22/06, Santosh Chokhani wrote:
> >Do you see interoperability problems with defining new ECDSA OIDs?
>=20
> Of course, if people are still expecting the old ones in certs they
> receive.
>=20
> --Paul Hoffman, Director
> --VPN Consortium
>=20

------_=_NextPart_001_01C6DE92.1AB3B72D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:sans-serif;
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:11.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
tt
	{font-family:"Courier New";}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I think in the longer run it is =
better to
tie hash algorithm to the SPKI.<o:p></o:p></span></font></p>

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Daniel Brown
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, September =
22, 2006
5:53 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Santosh
 Chokhani</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [email-masked]; =
Paul
Hoffman<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Protecting =
Against
Weak Hash Algorithms</span></font><o:p></o:p></p>

</div>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><br>
</span></font><font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;
font-family:sans-serif'>Santosh, Paul,</span></font> <br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Inclusion
of hash OIDs in the subject public key info field is an option in the =
current
proposed syntax. Similarly, it is an option in the RFC 4055 for RSA-PSS =
and
RSA-OAEP.</span></font> <br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>I
said in an earlier email there that I knew of neither hash substitution =
attacks
nor practical hash inversion attacks. &nbsp;That said, there are some
impractical, and thus theoretical considerations one might consider. =
&nbsp;Suppose
that <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Alice</st1:place></st1:City> has
a 384-bit EC public key, because she wants 192 bits of security (i.e. =
very high
security). &nbsp;It is then theoretically reasonable for <st1:City =
w:st=3D"on"><st1:place
 w:st=3D"on">Alice</st1:place></st1:City> to insist that Bob not to =
accept her
signatures if they are signed with SHA-1, because SHA-1 has a maximum of =
160
bits of security against preimage attacks. &nbsp;Admittedly, this is
theoretical concern, because we don't foresee 160-bit attack being =
practical
for the next 20 years or more. &nbsp;Anyway, <st1:City =
w:st=3D"on"><st1:place
 w:st=3D"on">Alice</st1:place></st1:City> could indicate this by putting
ecdsa-with-Sha384 in the subject public key info of her cert, if she =
wanted to
this paranoid.</span></font> <br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Thanks,</span></font>
<br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Dan
Brown<br>
(905) 501-3857<br>
http://www.certicom.com</span></font> <br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Santosh
wrote on 09/22/2006 05:06:31 PM:</span></font></tt><font size=3D2
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<br>
<tt><font face=3D"Courier New">&gt; </font></tt><br>
<tt><font face=3D"Courier New">&gt; May be the vendors should respond as =
to what
the installed base of ECDSA</font></tt><br>
<tt><font face=3D"Courier New">&gt; is and if they see it worthwhile to =
include
hash OID(s) in the subject</font></tt><br>
<tt><font face=3D"Courier New">&gt; public key algorithm and the =
attendant change
to the software and</font></tt><br>
<tt><font face=3D"Courier New">&gt; installed based of ECDSA =
certificates.</font></tt><br>
<tt><font face=3D"Courier New">&gt; </font></tt><br>
<tt><font face=3D"Courier New">&gt; -----Original =
Message-----</font></tt><br>
<tt><font face=3D"Courier New">&gt; From: Paul Hoffman
[mailto:[email-masked]] </font></tt><br>
<tt><font face=3D"Courier New">&gt; Sent: Friday, September 22, 2006 =
4:27 PM</font></tt><br>
<tt><font face=3D"Courier New">&gt; To: <st1:PersonName =
w:st=3D"on">Santosh
 Chokhani</st1:PersonName>; [email-masked]</font></tt><br>
<tt><font face=3D"Courier New">&gt; Subject: RE: Protecting Against Weak =
Hash
Algorithms</font></tt><br>
<tt><font face=3D"Courier New">&gt; </font></tt><br>
<tt><font face=3D"Courier New">&gt; At 12:56 PM -0700 9/22/06, =
<st1:PersonName
w:st=3D"on">Santosh Chokhani</st1:PersonName> wrote:</font></tt><br>
<tt><font face=3D"Courier New">&gt; &gt;Do you see interoperability =
problems with
defining new ECDSA OIDs?</font></tt><br>
<tt><font face=3D"Courier New">&gt; </font></tt><br>
<tt><font face=3D"Courier New">&gt; Of course, if people are still =
expecting the
old ones in certs they</font></tt><br>
<tt><font face=3D"Courier New">&gt; receive.</font></tt><br>
<tt><font face=3D"Courier New">&gt; </font></tt><br>
<tt><font face=3D"Courier New">&gt; --Paul Hoffman, =
Director</font></tt><br>
<tt><font face=3D"Courier New">&gt; --VPN Consortium</font></tt><br>
<tt><font face=3D"Courier New">&gt; =
</font></tt></span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6DE92.1AB3B72D--

To: "Santosh Chokhani" <[email-masked]>
Cc: [email-masked], "Paul Hoffman" <[email-masked]>
Subject: RE: Protecting Against Weak Hash Algorithms
From: Daniel Brown <[email-masked]>
Date: Fri, 22 Sep 2006 17:52:48 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 0078B064852571F1_=
Content-Type: text/plain; charset="US-ASCII"

Santosh, Paul,

Inclusion of hash OIDs in the subject public key info field is an option 
in the current proposed syntax. Similarly, it is an option in the RFC 4055 
for RSA-PSS and RSA-OAEP.

I said in an earlier email there that I knew of neither hash substitution 
attacks nor practical hash inversion attacks.  That said, there are some 
impractical, and thus theoretical considerations one might consider. 
Suppose that Alice has a 384-bit EC public key, because she wants 192 bits 
of security (i.e. very high security).  It is then theoretically 
reasonable for Alice to insist that Bob not to accept her signatures if 
they are signed with SHA-1, because SHA-1 has a maximum of 160 bits of 
security against preimage attacks.  Admittedly, this is theoretical 
concern, because we don't foresee 160-bit attack being practical for the 
next 20 years or more.  Anyway, Alice could indicate this by putting 
ecdsa-with-Sha384 in the subject public key info of her cert, if she 
wanted to this paranoid.

Thanks,

Dan Brown
(905) 501-3857
http://www.certicom.com

Santosh wrote on 09/22/2006 05:06:31 PM:

> 
> May be the vendors should respond as to what the installed base of ECDSA
> is and if they see it worthwhile to include hash OID(s) in the subject
> public key algorithm and the attendant change to the software and
> installed based of ECDSA certificates.
> 
> From: Paul Hoffman [mailto:[email-masked]] 
> Sent: Friday, September 22, 2006 4:27 PM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: Protecting Against Weak Hash Algorithms
> 
> At 12:56 PM -0700 9/22/06, Santosh Chokhani wrote:
> >Do you see interoperability problems with defining new ECDSA OIDs?
> 
> Of course, if people are still expecting the old ones in certs they
> receive.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 

--=_alternative 0078B064852571F1_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">Santosh, Paul,</font>
<br>
<br><font size=2 face="sans-serif">Inclusion of hash OIDs in the subject
public key info field is an option in the current proposed syntax. Similarly,
it is an option in the RFC 4055 for RSA-PSS and RSA-OAEP.</font>
<br>
<br><font size=2 face="sans-serif">I said in an earlier email there that
I knew of neither hash substitution attacks nor practical hash inversion
attacks. &nbsp;That said, there are some impractical, and thus theoretical
considerations one might consider. &nbsp;Suppose that Alice has a 384-bit
EC public key, because she wants 192 bits of security (i.e. very high security).
&nbsp;It is then theoretically reasonable for Alice to insist that Bob
not to accept her signatures if they are signed with SHA-1, because SHA-1
has a maximum of 160 bits of security against preimage attacks. &nbsp;Admittedly,
this is theoretical concern, because we don't foresee 160-bit attack being
practical for the next 20 years or more. &nbsp;Anyway, Alice could indicate
this by putting ecdsa-with-Sha384 in the subject public key info of her
cert, if she wanted to this paranoid.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br><font size=2 face="sans-serif">Dan Brown<br>
(905) 501-3857<br>
http://www.certicom.com</font>
<br>
<br><tt><font size=2>Santosh wrote on 09/22/2006 05:06:31 PM:<br>
<br>
&gt; <br>
&gt; May be the vendors should respond as to what the installed base of
ECDSA<br>
&gt; is and if they see it worthwhile to include hash OID(s) in the subject<br>
&gt; public key algorithm and the attendant change to the software and<br>
&gt; installed based of ECDSA certificates.<br>
&gt; <br>
&gt; -----Original Message-----<br>
&gt; From: Paul Hoffman [mailto:[email-masked]] <br>
&gt; Sent: Friday, September 22, 2006 4:27 PM<br>
&gt; To: Santosh Chokhani; [email-masked]<br>
&gt; Subject: RE: Protecting Against Weak Hash Algorithms<br>
&gt; <br>
&gt; At 12:56 PM -0700 9/22/06, Santosh Chokhani wrote:<br>
&gt; &gt;Do you see interoperability problems with defining new ECDSA OIDs?<br>
&gt; <br>
&gt; Of course, if people are still expecting the old ones in certs they<br>
&gt; receive.<br>
&gt; <br>
&gt; --Paul Hoffman, Director<br>
&gt; --VPN Consortium<br>
&gt; <br>
</font></tt>
--=_alternative 0078B064852571F1_=--

Date: Fri, 22 Sep 2006 14:46:13 -0700
To: Daniel Brown <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: Protecting Against Weak Hash Algorithms
Cc: "Santosh Chokhani" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 5:31 PM -0400 9/22/06, Daniel Brown wrote:
>The new ECDSA OIDs from X9.62 that I've proposed for PKIX use the 
>old ecdsa-with-Sha1 OID to indicate that a signature is signed with 
>SHA-1.  Therefore old and new implementations should be able to 
>interopate.

So, it sounds like Santosh's suggestion isn't needed for ECDSA.

>I'm not aware of any practical preimage attack on the currently 
>specified hash functions for ECDSA.

Right. It seems like the attack is not practical.

--Paul Hoffman, Director
--VPN Consortium

To: Paul Hoffman <[email-masked]>
Cc: "Santosh Chokhani" <[email-masked]>, [email-masked]
Subject: RE: Protecting Against Weak Hash Algorithms
From: Daniel Brown <[email-masked]>
Date: Fri, 22 Sep 2006 17:31:24 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 0076BAC9852571F1_=
Content-Type: text/plain; charset="US-ASCII"

Paul, Santosh,

Regarding your discussion of interoperability and ECDSA:

The new ECDSA OIDs from X9.62 that I've proposed for PKIX use the old 
ecdsa-with-Sha1 OID to indicate that a signature is signed with SHA-1. 
Therefore old and new implementations should be able to interopate.

If a signature is not signed with Sha-1, then are several options.  The 
preferred option are the fixed OIDs, such as ecdsa-with-Sha256 is SHA-256 
is used.  Another option is ecdsa-with-Specified, where a hash OID is put 
in the parameters field.  Note that only approved hash functions are 
allowed to go in the parameters field.  (This makes it slightly easier new 
hash functions, e.g. AHS). A third option is ecdsa-with-Recommended, which 
was intended to bind the hash function to the public key size, but that 
seems impractical now because of the uncertainty about hash functions.  If 
new implementations cannot agree on which of the three options, then 
there's interop problems.  If they all agree to support the fixed OID 
option, which is the preferred choice, then they should be fine.

As for security: 

I'm not aware of any practical preimage attack on the currently specified 
hash functions for ECDSA.   Suppose, however that a verifier was persuaded 
to use ecdsa-with-Specified with some illegal pre-image-weak hash OID in 
the parameter.  (Note again, this defies the currently specified ASN.1 
syntax.)   It is tempting to think that an attacker would then want to 
re-use an existing signature as singnature for some other message computed 
as the preimage of the hahs of the truly signed message.  However, it is 
well-known that if a hash is preimage-weak, then an attacker can directly 
forge ECDSA signatures.  (The same applies to DSA).  For example, see 
Section 6 of http://eprint.iacr.org/2002/026 .  Therefore, standards for 
ECDSA need to be very strict about what hash can be used.  Signatures for 
RSA may be a little different in this regard: a hash inverter may be 
insufficient for existential forgery.  However, a hash inverter + an 
existing signature may lead to a forgery.  This, there is a weak rationale 
for putting a hash id "firewall" in a RSA signature to prevent the 
substitution by a weak hash.  ECDSA and DSA simply have to directly 
disallow hash substituion.

I hope that helps,

Thanks,

Dan Brown
(905) 501-3857
http://www.certicom.com

Paul Hoffman wrote on 09/22/2006 04:27:09 PM:

> 
> At 12:56 PM -0700 9/22/06, Santosh Chokhani wrote:
> >Do you see interoperability problems with defining new ECDSA OIDs?
> 
> Of course, if people are still expecting the old ones in certs they 
receive.
> --Paul Hoffman, Director
> --VPN Consortium

--=_alternative 0076BAC9852571F1_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">Paul, Santosh,</font>
<br>
<br><font size=2 face="sans-serif">Regarding your discussion of interoperability
and ECDSA:</font>
<br>
<br><font size=2 face="sans-serif">The new ECDSA OIDs from X9.62 that I've
proposed for PKIX use the old ecdsa-with-Sha1 OID to indicate that a signature
is signed with SHA-1. &nbsp;Therefore old and new implementations should
be able to interopate.</font>
<br>
<br><font size=2 face="sans-serif">If a signature is not signed with Sha-1,
then are several options. &nbsp;The preferred option are the fixed OIDs,
such as ecdsa-with-Sha256 is SHA-256 is used. &nbsp;Another option is ecdsa-with-Specified,
where a hash OID is put in the parameters field. &nbsp;Note that only approved
hash functions are allowed to go in the parameters field. &nbsp;(This makes
it slightly easier new hash functions, e.g. AHS). A third option is ecdsa-with-Recommended,
which was intended to bind the hash function to the public key size, but
that seems impractical now because of the uncertainty about hash functions.
&nbsp;If new implementations cannot agree on which of the three options,
then there's interop problems. &nbsp;If they all agree to support the fixed
OID option, which is the preferred choice, then they should be fine.</font>
<br>
<br><font size=2 face="sans-serif">As for security: </font>
<br>
<br><font size=2 face="sans-serif">I'm not aware of any practical preimage
attack on the currently specified hash functions for ECDSA. &nbsp; Suppose,
however that a verifier was persuaded to use ecdsa-with-Specified with
some illegal pre-image-weak hash OID in the parameter. &nbsp;(Note again,
this defies the currently specified ASN.1 syntax.) &nbsp; It is tempting
to think that an attacker would then want to re-use an existing signature
as singnature for some other message computed as the preimage of the hahs
of the truly signed message. &nbsp;However, it is well-known that if a
hash is preimage-weak, then an attacker can directly forge ECDSA signatures.
&nbsp;(The same applies to DSA). &nbsp;For example, see Section 6 of http://eprint.iacr.org/2002/026
. &nbsp;Therefore, standards for ECDSA need to be very strict about what
hash can be used. &nbsp;Signatures for RSA may be a little different in
this regard: a hash inverter may be insufficient for existential forgery.
&nbsp;However, a hash inverter + an existing signature may lead to a forgery.
&nbsp;This, there is a weak rationale for putting a hash id &quot;firewall&quot;
in a RSA signature to prevent the substitution by a weak hash. &nbsp;ECDSA
and DSA simply have to directly disallow hash substituion.</font>
<br>
<br><font size=2 face="sans-serif">I hope that helps,</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br><font size=2 face="sans-serif">Dan Brown<br>
(905) 501-3857<br>
http://www.certicom.com</font>
<br>
<br><tt><font size=2>Paul Hoffman wrote on 09/22/2006 04:27:09 PM:<br>
<br>
&gt; <br>
&gt; At 12:56 PM -0700 9/22/06, Santosh Chokhani wrote:<br>
&gt; &gt;Do you see interoperability problems with defining new ECDSA OIDs?<br>
&gt; <br>
&gt; Of course, if people are still expecting the old ones in certs they
receive.<br>
&gt; <br>
&gt; --Paul Hoffman, Director<br>
&gt; --VPN Consortium<br>
&gt; <br>
</font></tt>
--=_alternative 0076BAC9852571F1_=--

Content-class: urn:content-classes:message
Subject: RE: Protecting Against Weak Hash Algorithms
Date: Fri, 22 Sep 2006 14:06:31 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

May be the vendors should respond as to what the installed base of ECDSA
is and if they see it worthwhile to include hash OID(s) in the subject
public key algorithm and the attendant change to the software and
installed based of ECDSA certificates.

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Friday, September 22, 2006 4:27 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Protecting Against Weak Hash Algorithms

At 12:56 PM -0700 9/22/06, Santosh Chokhani wrote:
>Do you see interoperability problems with defining new ECDSA OIDs?

Of course, if people are still expecting the old ones in certs they
receive.

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 22 Sep 2006 13:27:09 -0700
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: Protecting Against Weak Hash Algorithms
Sender: [email-masked]

At 12:56 PM -0700 9/22/06, Santosh Chokhani wrote:
>Do you see interoperability problems with defining new ECDSA OIDs?

Of course, if people are still expecting the old ones in certs they receive.

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: Protecting Against Weak Hash Algorithms
Date: Fri, 22 Sep 2006 12:56:23 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Paul,

Do you see interoperability problems with defining new ECDSA OIDs?

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Friday, September 22, 2006 3:54 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Protecting Against Weak Hash Algorithms

At 12:29 PM -0700 9/22/06, Santosh Chokhani wrote:
>When you register a new OID for subject public key information and that
>OID has in its parameters list the possible hash OIDs, that is not a
>change to the certificate syntax since it is dependent on the OID for
>the subject public key information.

Thank you for the clarification. If you want people to use new OIDs 
(such as "RSA over SHA-1" instead of today's "RSA"), then people 
using the new OID would have their signatures rejected by receiving 
software that didn't know the new OID, even though the receiving 
software has all the bits needed to validate the signature. I suggest 
that this is not a good idea, and that it will be terribly confusing 
to both software vendors ("which of the OIDs should I use here") and 
users ("he says he signed it with RSA and SHA-1, and I can read other 
certs with those algorithms, why can't I read his?").

>As to weak and strong hash, I would assume MD4 followed by MD5 and some
>day SHA-1 could be candidates.

Sorry to be so repetitive, but please define "weak". From this 
sentence, you seem to be saying "weak" means has less that expected 
collision resistance because there have been no practical preimage 
attacks on the functions you list. So, either you mean that your 
proposed attack works with a collision attack, or you believe that 
there are practical preimage attacks on those functions. Please 
specify which you believe to be true.

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 22 Sep 2006 12:54:07 -0700
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: Protecting Against Weak Hash Algorithms
Sender: [email-masked]

At 12:29 PM -0700 9/22/06, Santosh Chokhani wrote:
>When you register a new OID for subject public key information and that
>OID has in its parameters list the possible hash OIDs, that is not a
>change to the certificate syntax since it is dependent on the OID for
>the subject public key information.

Thank you for the clarification. If you want people to use new OIDs 
(such as "RSA over SHA-1" instead of today's "RSA"), then people 
using the new OID would have their signatures rejected by receiving 
software that didn't know the new OID, even though the receiving 
software has all the bits needed to validate the signature. I suggest 
that this is not a good idea, and that it will be terribly confusing 
to both software vendors ("which of the OIDs should I use here") and 
users ("he says he signed it with RSA and SHA-1, and I can read other 
certs with those algorithms, why can't I read his?").

>As to weak and strong hash, I would assume MD4 followed by MD5 and some
>day SHA-1 could be candidates.

Sorry to be so repetitive, but please define "weak". From this 
sentence, you seem to be saying "weak" means has less that expected 
collision resistance because there have been no practical preimage 
attacks on the functions you list. So, either you mean that your 
proposed attack works with a collision attack, or you believe that 
there are practical preimage attacks on those functions. Please 
specify which you believe to be true.

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: Protecting Against Weak Hash Algorithms
Date: Fri, 22 Sep 2006 12:29:01 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Paul,

When you register a new OID for subject public key information and that
OID has in its parameters list the possible hash OIDs, that is not a
change to the certificate syntax since it is dependent on the OID for
the subject public key information.

As to weak and strong hash, I would assume MD4 followed by MD5 and some
day SHA-1 could be candidates.

The one advantage the approach has as we try to revise/define ECDSA OIDs
and syntaxes is that the approach will let the infrastructure dictate
when to stop using SHA-1 by defining the certificate life or by revoking
certificates (e.g., simply a CA certificate).

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Friday, September 22, 2006 3:19 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Protecting Against Weak Hash Algorithms

At 12:07 PM -0700 9/22/06, Santosh Chokhani wrote:
>Sorry, I misunderstood. However, changing the *certificate* structure
>for an attack that has no practical basis is just as bad (if not
>worse) than changing the signature structure.
>[Santosh Chokhani] How do you see this as a change in certificate
>structure?  All that will be added is parameters to the subject public
>key which by definition are OID dependent.

Are you saying that adding parameters to the subject public key is 
not a change to the certificate?

>[Santosh Chokhani] The problem is that if there is a concern about the
>relying party being fooled into invoking a weak hash while signer used
a
>strong hash, how do we go about solving the problem.

If you are unwilling to define "weak hash" and "strong hash", I do 
not see how this group can decide whether or not your change is 
warranted.

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 22 Sep 2006 12:19:29 -0700
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: Protecting Against Weak Hash Algorithms
Sender: [email-masked]

At 12:07 PM -0700 9/22/06, Santosh Chokhani wrote:
>Sorry, I misunderstood. However, changing the *certificate* structure
>for an attack that has no practical basis is just as bad (if not
>worse) than changing the signature structure.
>[Santosh Chokhani] How do you see this as a change in certificate
>structure?  All that will be added is parameters to the subject public
>key which by definition are OID dependent.

Are you saying that adding parameters to the subject public key is 
not a change to the certificate?

>[Santosh Chokhani] The problem is that if there is a concern about the
>relying party being fooled into invoking a weak hash while signer used a
>strong hash, how do we go about solving the problem.

If you are unwilling to define "weak hash" and "strong hash", I do 
not see how this group can decide whether or not your change is 
warranted.

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: Protecting Against Weak Hash Algorithms
Date: Fri, 22 Sep 2006 12:07:59 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DE7A.60F3FCE5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Paul,

See responses in-line.

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]]=20
Sent: Friday, September 22, 2006 10:29 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: Protecting Against Weak Hash Algorithms

At 7:17 AM -0700 9/22/06, Santosh Chokhani wrote:
>The proposal is NOT to be change the signature structure.  The proposal
>is to define hash algorithm(s) as parameter(s) in subject public key
>information field.

Sorry, I misunderstood. However, changing the *certificate* structure=20
for an attack that has no practical basis is just as bad (if not=20
worse) than changing the signature structure.
[Santosh Chokhani] How do you see this as a change in certificate
structure?  All that will be added is parameters to the subject public
key which by definition are OID dependent.

[Santosh Chokhani] I do not think the characterization of attack is as
cut and dried.  If crypto mathematicians were saying in 2002 that what
hash function to use should be infrastructure decision, I would think
that will hold true more so today.=20

>Also, this is not a trust anchor issue.  A trust anchor is not
>susceptible to this since a trust anchor has addition requirements to
be
>stored securely.  Besides from the standards and security viewpoint,
>there is no need to verify signature on trust anchor.  So, your whole
>discussion regarding trust anchor is not germane.

Then I am completely confused by your message that started this=20
thread. If you could restate the problem (using more precise terms=20
than "weak" and "snookered") and give a real scenario, that would=20
help.

[Santosh Chokhani] The problem is that if there is a concern about the
relying party being fooled into invoking a weak hash while signer used a
strong hash, how do we go about solving the problem.

[Santosh Chokhani] I have attached the original posting that started the
thread.  I do not understand how you infer from this or other postings
in this thread from me that I am talking about a trust anchor format, a
change to signature format, or change to signature format.

--Paul Hoffman, Director
--VPN Consortium

------_=_NextPart_001_01C6DE7A.60F3FCE5
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit

X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Protecting Against Weak Hash Algorithms
Date: Wed, 20 Sep 2006 12:09:53 -0700
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Protecting Against Weak Hash Algorithms
Thread-Index: Acbc6FpnVYOWAh89Tpml7zf6RMeu4w==
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>

As you know the hashing algorithms are in state of flux (We know MD5 is
bad, SHA-1 is beginning to smell and so on).

=20

Also, we know that many relying parties implement many of these
algorithms.

=20

Also, Russ has been talking about making PKIX RFCs algorithm independent
so that algorithms can be easily swapped in and out.

=20

I think we should have a debate on security issues surrounding weak
hashes, specifically relying parties snookered into verifying a
signature using a weak hash that can easily create collision with
payload that was actually signed using a strong hash.

=20

While it will be a great deal of pain to the client software, but
subject public key information through OID or parameters could specify
one or more hash algorithms to be used with a signature key.  This will
protect against the spoofing of relying party into using a weak hash
during signature verification.  I thought while we are debating the
syntax for ECC based algorithms, this may be a good time to suffer that
pain.

=20

Santosh Chokhani=20
Orion Security Solutions, Inc.=20
(703) 401-7088=20
[email-masked]=20

=20

------_=_NextPart_001_01C6DE7A.60F3FCE5--

Content-class: urn:content-classes:message
Subject: RE: New time stamping standard by ISO
Date: Fri, 22 Sep 2006 17:05:51 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Russ Housley" <[email-masked]>, =?iso-8859-1?Q?Jos=E9_A=2E_Ma=F1as?= <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Russ,

There are 2 issues worth discussing as I see it. One directly related to RFC 3161 and one to S/MIME

1) Change of the TimeStampToken

RFC 3161 define:

TimeStampToken ::= ContentInfo
-- contentType is id-signedData ([CMS])
-- content is SignedData ([CMS])

ISO/IEC WD 18014-2.3 expand this to:

TimeStampToken ::= CHOICE {
cms ContentInfo,
signerInfo [1] EXPLICIT SignerInfo
-- room for additional formats
}

Two issues with this, it adds alternatives to how a TSA may respond to a timestamp request. Even it this fits on top of RFC 3161, it introduce the aspect and need for negotiating response formats, secondly, when ContentInfo is used, RFC 3161 requires contentType to be SignedData, ISO/IEC WD 18014-2.3 allows it to be almost anything.

2) Making the TSA signer of the document of a time-stamped signature
Traditionally a TSA has been seen as an entity signing the time of an event or the existence of a document, but not signing the document itself.
ISO/IEC WD 18014-2.3 changes this and introduces an alternative (where the TimStampToken takes the form of a SignerInfo). Here the TSA is signing BOTH the time stamped message AND the timestamp (TSTInfo) provided in a signed attribute. The TSA makes this with a certificate with an EKU explicitly restricted to time-stamping.

So we have a semi situation where the TSA kind of has signed the CMS message, but kind of not (if you care about the EKU).

The question is if this is a reasonable use of CMS, and if it is reasonable to have the TSA signing the message. I feel that this whole concept is shaky, stretching CMS semantics and I fear all sorts of unexpected errors. Basically, I don't like it.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> [email-masked]] On Behalf Of Russ Housley
> Sent: den 21 september 2006 23:55
> To: José A. Mañas
> Cc: [email-masked]
> Subject: Re: New time stamping standard by ISO
> 
> 
> Wouldn't it be better to explain the things that you see as
> shortcomings and work with the IETF PKIX WG to come to a mutually
> acceptable solution?
> 
> Russ
> 
> 
> At 08:21 AM 9/21/2006, José A. Mañas wrote:
> >I am working in the iso group updating the time-stamping standard.
> >It is not so much a brand-new standard.
> >
> >I think everyone in the group understands that backwards
> >compatibility with 3161 is a must;
> >then we try to improve, and basically to standardize
> >improvements so there is some agreed way of doing things right.
> >
> >The aims are
> >   - to keep 3161 tokens
> >   - to allow for cms "embeddable" tokens
> >   - to align xml and asn1 tokens
> >
> >The new standard is still in the working draft stage,
> >so there is room for listening as wide an audience as possible.
> >
> >Best
> >jam
> >
> >Peter Gutmann wrote:
> >>Russ Housley <[email-masked]> writes:
> >>
> >>>Yet, everyone implement it this way, right?
> >>Well of course they implement it that way, because the spec says
> >>they have to.
> >>If the spec said they had to run naked down the middle of the road
> >>in order to
> >>claim RFC 3161 compliance they'd do that too, even though it's not a
> sensible
> >>thing to do.
> >>
> >>>If there is a need for change, it should begin with an update to RFC
> 3161.
> >>This problem was pointed out years ago, when the RFC was still in
> >>draft stage.
> >>The authors ignored it, along with other comments people submitted
> >>about other
> >>issues.  So I think ISO is the only forum for change.
> >>Peter.
> >

Date: Fri, 22 Sep 2006 07:28:48 -0700
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: Protecting Against Weak Hash Algorithms
Sender: [email-masked]

At 7:17 AM -0700 9/22/06, Santosh Chokhani wrote:
>The proposal is NOT to be change the signature structure.  The proposal
>is to define hash algorithm(s) as parameter(s) in subject public key
>information field.

Sorry, I misunderstood. However, changing the *certificate* structure 
for an attack that has no practical basis is just as bad (if not 
worse) than changing the signature structure.

>Also, this is not a trust anchor issue.  A trust anchor is not
>susceptible to this since a trust anchor has addition requirements to be
>stored securely.  Besides from the standards and security viewpoint,
>there is no need to verify signature on trust anchor.  So, your whole
>discussion regarding trust anchor is not germane.

Then I am completely confused by your message that started this 
thread. If you could restate the problem (using more precise terms 
than "weak" and "snookered") and give a real scenario, that would 
help.

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: Protecting Against Weak Hash Algorithms
Date: Fri, 22 Sep 2006 07:17:18 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Paul,

The proposal is NOT to be change the signature structure.  The proposal
is to define hash algorithm(s) as parameter(s) in subject public key
information field.

Also, this is not a trust anchor issue.  A trust anchor is not
susceptible to this since a trust anchor has addition requirements to be
stored securely.  Besides from the standards and security viewpoint,
there is no need to verify signature on trust anchor.  So, your whole
discussion regarding trust anchor is not germane.

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Friday, September 22, 2006 10:12 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: Protecting Against Weak Hash Algorithms

If the only way to trigger this problem is to find a hash function 
that (a) is used in a certificate in someone's store of trust anchors 
and (b) is susceptible to a preimage attack and (c) no one has 
suggested any practical preimage attacks on those hash functions, 
then I am against changing the signature format for this attack.

If the attacker can create a preimage, they will do so for the the 
trusted root; this will take much less effort than creating a 
preimage that will match a valid message for a different trust 
anchor. Few applications that handle multiple trust anchors show the 
user which trust anchor is being used at the time of validation. 
Thus, an attacker would have many ripe targets without having to do 
the extra work of getting one message to match another from a 
"better" trust anchor.

Further, even if we decided that this was an actual problem, there 
are many other proposed changes to the signature structure that would 
both eliminate this attack and others at the same time. We don't get 
to change signature structures often; doing it for this minor case 
seems like a waste of effort.

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: Protecting Against Weak Hash Algorithms
Date: Fri, 22 Sep 2006 07:13:54 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DE51.51E11B56
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Denis,

=20

I suspect we are discussing different threats.  My suggestion is to deal
with the threat of an attacker exploiting existence of weak hash
algorithms in the relying party system.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Friday, September 22, 2006 8:24 AM
To: [email-masked]
Subject: Re: Protecting Against Weak Hash Algorithms

=20

Santosh,

=20

Why re-inventing the wheel ? There is another approach (Archive
validation data )

 that avoids to over-complexify the problem.

=20

Take a look at RFC 3126, page 20 :

=20

   Before the algorithms used in any of electronic signatures become or

   are likely, to be compromised or rendered vulnerable in the future,

   it is necessary to time-stamp the entire electronic signature,

   including all the values of the validation and user data as an ES

   with Archive validation data (ES-A).=20

=20

and page 76 :

=20

                                        The Archive validation data is

   necessary if the hash function and the crypto algorithms that were
used

      to create the signature are no longer secure.

=20

Denis

=20

________________________________

As you know the hashing algorithms are in state of flux (We know MD5 is
bad, SHA-1 is beginning to smell and so on).

Also, we know that many relying parties implement many of these
algorithms.

Also, Russ has been talking about making PKIX RFCs algorithm independent
so that algorithms can be easily swapped in and out.

I think we should have a debate on security issues surrounding weak
hashes, specifically relying parties snookered into verifying a
signature using a weak hash that can easily create collision with
payload that was actually signed using a strong hash.

While it will be a great deal of pain to the client software, but
subject public key information through OID or parameters could specify
one or more hash algorithms to be used with a signature key.  This will
protect against the spoofing of relying party into using a weak hash
during signature verification.  I thought while we are debating the
syntax for ECC based algorithms, this may be a good time to suffer that
pain.

Santosh Chokhani=20
Orion Security Solutions, Inc.=20
(703) 401-7088=20
[email-masked]=20

________________________________

------_=_NextPart_001_01C6DE51.51E11B56
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I suspect we are discussing =
different threats.&nbsp;
My suggestion is to deal with the threat of an attacker exploiting =
existence of
weak hash algorithms in the relying party =
system.<o:p></o:p></span></font></p>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Denis Pinkas<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, September =
22, 2006
8:24 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Protecting =
Against
Weak Hash Algorithms</span></font><o:p></o:p></p>

</div>

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

<div>

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

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Why re-inventing the wheel ? There is another approach =
(</span></font><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>Archive
validation data&nbsp;)</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;that avoids to&nbsp;over-complexify the =
problem.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Take a look at RFC 3126, page 20 :<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoPlainText style=3D'margin:0in;margin-bottom:.0001pt'><font =
size=3D2
face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
Before the algorithms used in any of electronic signatures become =
or</span><u1:p></u1:p></font><o:p></o:p></p>

<p class=3DMsoPlainText style=3D'margin:0in;margin-bottom:.0001pt'><font =
size=3D2
face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
are likely, to be compromised or rendered vulnerable in the =
future,</span><u1:p></u1:p></font><o:p></o:p></p>

<p class=3DMsoPlainText style=3D'margin:0in;margin-bottom:.0001pt'><font =
size=3D2
face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
it is necessary to time-stamp the entire electronic =
signature,</span><u1:p></u1:p></font><o:p></o:p></p>

<p class=3DMsoPlainText style=3D'margin:0in;margin-bottom:.0001pt'><font =
size=3D2
face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
including all the values of the validation and user data as an =
ES</span><u1:p></u1:p></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; with =
Archive validation
data (ES-A).</span></font>&nbsp;<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

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

</div>

<div>

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

</div>

<div>

<p class=3DMsoPlainText style=3D'margin:0in;margin-bottom:.0001pt'><font =
size=3D2
face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;
The Archive validation data is</span><u1:p></u1:p></font><o:p></o:p></p>

<p class=3DMsoPlainText style=3D'margin:0in;margin-bottom:.0001pt'><font =
size=3D2
face=3D"Courier New"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp;
necessary if the hash function and the crypto algorithms that =
were</span><u1:p></u1:p></font><span
lang=3DEN-GB> </span><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>used</span></font><o:p></o:p></p>

<p class=3DMsoPlainText style=3D'margin:0in;margin-bottom:.0001pt'><font =
size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font size=3D2 face=3D"Courier New"><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:"Courier New"'>to create the =
signature are
no longer secure.</span></font><o:p></o:p></p>

<p class=3DMsoPlainText style=3D'margin:0in;margin-bottom:.0001pt'><font =
size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

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

</div>

<div>

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

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

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

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>As you know
the hashing algorithms are in state of flux (We know MD5 is bad, SHA-1 =
is
beginning to smell and so on).<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><u1:p></u1:p>Also,
we know that many relying parties implement many of these =
algorithms.<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><u1:p></u1:p>Also,
Russ has been talking about making PKIX RFCs algorithm independent so =
that
algorithms can be easily swapped in and =
out.<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><u1:p></u1:p>I
think we should have a debate on security issues surrounding weak =
hashes,
specifically relying parties snookered into verifying a signature using =
a weak
hash that can easily create collision with payload that was actually =
signed
using a strong hash.<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><u1:p></u1:p>While
it will be a great deal of pain to the client software, but subject =
public key
information through OID or parameters could specify one or more hash =
algorithms
to be used with a signature key.&nbsp; This will protect against the =
spoofing
of relying party into using a weak hash during signature =
verification.&nbsp; I
thought while we are debating the syntax for ECC based algorithms, this =
may be
a good time to suffer that =
pain.<u1:p></u1:p></span></font><o:p></o:p></p>

<p><st1:PersonName u2:st=3D"on"><u1:p></u1:p><st1:PersonName =
w:st=3D"on"><font
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Santosh
 Chokhani</span></font></st1:PersonName></st1:PersonName> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Orion
Security Solutions, Inc.</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>(703)</span></font>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>401-7088</span></font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>[email-masked]</span>=
</font>&nbsp;<o:p></o:p></p>

</div>

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

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

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

</div>

</body>

</html>

------_=_NextPart_001_01C6DE51.51E11B56--

Date: Fri, 22 Sep 2006 07:11:35 -0700
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: Protecting Against Weak Hash Algorithms
Sender: [email-masked]

If the only way to trigger this problem is to find a hash function 
that (a) is used in a certificate in someone's store of trust anchors 
and (b) is susceptible to a preimage attack and (c) no one has 
suggested any practical preimage attacks on those hash functions, 
then I am against changing the signature format for this attack.

If the attacker can create a preimage, they will do so for the the 
trusted root; this will take much less effort than creating a 
preimage that will match a valid message for a different trust 
anchor. Few applications that handle multiple trust anchors show the 
user which trust anchor is being used at the time of validation. 
Thus, an attacker would have many ripe targets without having to do 
the extra work of getting one message to match another from a 
"better" trust anchor.

Further, even if we decided that this was an actual problem, there 
are many other proposed changes to the signature structure that would 
both eliminate this attack and others at the same time. We don't get 
to change signature structures often; doing it for this minor case 
seems like a waste of effort.

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 21 Sep 2006 17:54:47 -0400
To: "José A. Mañas" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: New time stamping standard by ISO
Cc: [email-masked]
Sender: [email-masked]

Wouldn't it be better to explain the things that you see as 
shortcomings and work with the IETF PKIX WG to come to a mutually 
acceptable solution?

Russ

At 08:21 AM 9/21/2006, José A. Mañas wrote:
>I am working in the iso group updating the time-stamping standard.
>It is not so much a brand-new standard.
>
>I think everyone in the group understands that backwards
>compatibility with 3161 is a must;
>then we try to improve, and basically to standardize
>improvements so there is some agreed way of doing things right.
>
>The aims are
>   - to keep 3161 tokens
>   - to allow for cms "embeddable" tokens
>   - to align xml and asn1 tokens
>
>The new standard is still in the working draft stage,
>so there is room for listening as wide an audience as possible.
>
>Best
>jam
>
>Peter Gutmann wrote:
>>Russ Housley <[email-masked]> writes:
>>
>>>Yet, everyone implement it this way, right?
>>Well of course they implement it that way, because the spec says 
>>they have to.
>>If the spec said they had to run naked down the middle of the road 
>>in order to
>>claim RFC 3161 compliance they'd do that too, even though it's not a sensible
>>thing to do.
>>
>>>If there is a need for change, it should begin with an update to RFC 3161.
>>This problem was pointed out years ago, when the RFC was still in 
>>draft stage.
>>The authors ignored it, along with other comments people submitted 
>>about other
>>issues.  So I think ISO is the only forum for change.
>>Peter.
>

Date: Fri, 22 Sep 2006 14:23:55 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Protecting Against Weak Hash Algorithms
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Santosh,

Why re-inventing the wheel ? There is another approach (Archive validation data )
 that avoids to over-complexify the problem.

Take a look at RFC 3126, page 20 :

   Before the algorithms used in any of electronic signatures become or
   are likely, to be compromised or rendered vulnerable in the future,
   it is necessary to time-stamp the entire electronic signature,
   including all the values of the validation and user data as an ES
   with Archive validation data (ES-A). 

and page 76 :

                                        The Archive validation data is
   necessary if the hash function and the crypto algorithms that were used
      to create the signature are no longer secure.

Denis

As you know the hashing algorithms are in state of flux (We know MD5 is bad, SHA-1 is beginning to smell and so on).
Also, we know that many relying parties implement many of these algorithms.
Also, Russ has been talking about making PKIX RFCs algorithm independent so that algorithms can be easily swapped in and out.
I think we should have a debate on security issues surrounding weak hashes, specifically relying parties snookered into verifying a signature using a weak hash that can easily create collision with payload that was actually signed using a strong hash.
While it will be a great deal of pain to the client software, but subject public key information through OID or parameters could specify one or more hash algorithms to be used with a signature key.  This will protect against the spoofing of relying party into using a weak hash during signature verification.  I thought while we are debating the syntax for ECC based algorithms, this may be a good time to suffer that pain.
Santosh Chokhani 
Orion Security Solutions, Inc. 
(703) 401-7088 
[email-masked] 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o xmlns:st1><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1528" name=GENERATOR></HEAD>
<BODY>
<DIV>Santosh,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Why re-inventing the wheel ? There is another approach (<FONT 
face="Courier New" size=2>Archive validation data&nbsp;)</FONT></DIV>
<DIV>&nbsp;that avoids to&nbsp;over-complexify the problem.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Take a look at RFC 3126, page 20 :</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Before the algorithms used in any 
of electronic signatures become or<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>are likely, to be compromised or 
rendered vulnerable in the future,<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>it is necessary to time-stamp the 
entire electronic signature,<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>including all the values of the 
validation and user data as an ES<o:p></o:p></FONT></FONT></SPAN></P><SPAN 
lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: FR; mso-bidi-language: AR-SA"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>with Archive validation data 
(ES-A).</SPAN>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>and page 76 :</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN></FONT></FONT></SPAN><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New">The 
Archive validation data is<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes">&nbsp;&nbsp; </SPAN>necessary if the hash function and 
the crypto algorithms that were<o:p></o:p></FONT></FONT></SPAN> <FONT 
face="Courier New" size=2>used</FONT></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<SPAN lang=EN-GB 
style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-ansi-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-fareast-language: FR; mso-bidi-language: AR-SA">to 
create the signature are no longer secure.</SPAN><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes"></SPAN></FONT></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT size=2><FONT face="Courier New"><SPAN 
style="mso-spacerun: yes"></SPAN></FONT></FONT></SPAN>&nbsp;</P></DIV>
<DIV>Denis</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
</DIV>
<DIV class=Section1>
<P class=MsoNormal><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt">As you 
know the hashing algorithms are in state of flux (We know MD5 is bad, SHA-1 is 
beginning to smell and so on).<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN 
style="FONT-SIZE: 10pt"><o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt">Also, 
we know that many relying parties implement many of these 
algorithms.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN 
style="FONT-SIZE: 10pt"><o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt">Also, 
Russ has been talking about making PKIX RFCs algorithm independent so that 
algorithms can be easily swapped in and out.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN 
style="FONT-SIZE: 10pt"><o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt">I think 
we should have a debate on security issues surrounding weak hashes, specifically 
relying parties snookered into verifying a signature using a weak hash that can 
easily create collision with payload that was actually signed using a strong 
hash.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN 
style="FONT-SIZE: 10pt"><o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN style="FONT-SIZE: 10pt">While 
it will be a great deal of pain to the client software, but subject public key 
information through OID or parameters could specify one or more hash algorithms 
to be used with a signature key.&nbsp; This will protect against the spoofing of 
relying party into using a weak hash during signature verification.&nbsp; I 
thought while we are debating the syntax for ECC based algorithms, this may be a 
good time to suffer that pain.<o:p></o:p></SPAN></FONT></P>
<P class=MsoNormal><FONT face=Arial size=2><SPAN 
style="FONT-SIZE: 10pt"><o:p></o:p></SPAN></FONT></P>
<P><st1:PersonName w:st="on"><FONT face=Arial size=2><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Santosh 
Chokhani</SPAN></FONT></st1:PersonName> <BR><FONT face=Arial size=2><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Orion Security Solutions, 
Inc.</SPAN></FONT> <BR><FONT face=Arial size=2><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">(703)</SPAN></FONT> <FONT face=Arial 
size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">401-7088</SPAN></FONT> 
<BR><FONT face=Arial size=2><SPAN 
style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">[email-masked]</SPAN></FONT>&nbsp;<BR></P></DIV>
<HR>
</BODY></HTML>

--=====003_Dragon416531282456_=====--

Content-class: urn:content-classes:message
Subject: RE: Protecting Against Weak Hash Algorithms
Date: Fri, 22 Sep 2006 03:26:58 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Paul,

See responses in-line.

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Thursday, September 21, 2006 10:22 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Protecting Against Weak Hash Algorithms

At 3:51 AM -0700 9/21/06, Santosh Chokhani wrote:
>Let us say that you as a signer is using SHA-1 and RSA.  I thought I
can
>keep your signature, but create a payload using a weak hash scheme (say
>MD-4 or chokhani Hash) that is still lying in the relying party system.

I think that is only true if "weak" means susceptible to a preimage 
attack, not to the collision attacks we have been seeing. To date, 
none of the hash functions in use have been shown to be susceptible 
to exploitable preimage attacks.
[Santosh Chokhani] Yes.

Also, it is only true if the output size of the two hashes are the same,
yes?
[Santosh Chokhani] I do not think so.  See the Kaliski paper I cited.

--Paul Hoffman, Director
--VPN Consortium

Importance: normal
Content-Class: urn:content-classes:message
Subject: R: R: Browser trust models & Smart cards
Date: Fri, 22 Sep 2006 09:23:39 +0200
From: "Santoni Adriano" <[email-masked]>
To: "pkix" <[email-masked]>
Sender: [email-masked]

It is not a "bad CA practice" question, in my opinion. Certificate extensions can be flagged critical for good reasons and according to standards.

Qualified certificates (especially those issued to natural persons vs. software applications) are recommended to have just the NR bit set in KeyUsage, and this latter flagged critical.

ETSI TS 102 280 reads: "In cases where a certificate is intended to be used to validate commitment to signed content, such as electronic signatures on agreements and/or transactions, then the key usage combination SHALL be limited to type A or B. This means that the non-repudiation bit (bit 1) SHALL be set. Of these alternatives it is RECOMMENDED to use the type A setting only (see the security note below)."

De facto, this recommendation has been followed by many CAs operating in compliance with national laws.

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Massimiliano Pala
Inviato: venerdì 15 settembre 2006 9.44
A: pkix
Oggetto: Re: R: Browser trust models & Smart cards

Santoni Adriano wrote:
> I fully agree with Anders.
[...]
> For instance, it rejects digital signature certificates as they were 
> unknown beasts. I mean, certificates with a critical KeyUsage 
> extension with the "nonRepudiation" bit raised. If you want to use the 
> signText() function with a qualified certificate, in Mozilla/Firefox, 
> you're out of luck. Why so? Nobody seems to know or care.

This is usually the case when *BAD* CA practice force the presence of critical extensions on very specific profiles. This is sometimes the case of some CAs that follow national signature laws... anyway have you submitted the bug/feature request to the Mozilla developers (bugzilla) ? If so, can you send (me) the number of the bug #ID ?

-- 

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 062                        Work Phone: +1 (603) 646-9226
--o------------------------------------------------------------------------

*******************Internet Email Confidentiality Footer*******************

Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati.
Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of ACTALIS S.p.A. Besides, The contents of this message shall be understood as neither given nor endorsed by ACTALIS S.p.A.. 
ACTALIS S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.

Date: Fri, 22 Sep 2006 07:59:04 +0200
From: =?ISO-8859-1?Q?=22Jos=E9_A=2E_Ma=F1as=22?= <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Peter Gutmann <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

Stefan Santesson wrote:
 > José
 >
 > Thanks for the answer. This gets more into a CMS discussion and maybe 
should be moved the the S/MIME group, but the basic issues are 2.
 >
 > 1) The changes/amendments to RFC 3161 (even if it is a single bit, 
but in fact it is more. RFC 3161 restrict the CMS type to SignedData, 
the ISO draft does not)
the one bit i refer to is between 18014-1:2002 and current drafts

the usage of other cms constructions has been there for years,
and it is not breaking cms at all: it is standard usage

 > 2) The appropriateness of letting the TSA actually sign the 
time-stamped message, not just the time stamp info (TSTInfo).

 >>> But basically it is a breach of semantics that may lead to unexpected
 >> behaviors in legacy applications trying to understand the signatures of
 >> the CMS object.
 >> Mmmm,
 >> do you mean in applications that do not care after the policy that
 >> the signer applies to the signature?
 >>
 >
 > I assume the choice of SignerInfo as alternative token structure is 
so that it will be included in a CMS SignedData.

the picture is that the contents gets several signatures
(either in parallel or nested)

each signature has its value; but all of them deal with the same contents

 > However, this is not explicitly stated. If it is then the TSA has, by 
CMS definitions, just become signer of the encapsulated data, not only 
the timestamp.
 > But at the same time it has an extended key usage in its certificate 
that is incompatible with this role as message signer. They way I read 
CMS and Signed Data, the TSA can not only sign the signed attribute in 
SignerInfo, it MUST also sign the encapsulated data in SidnedData.
 >
 > To me this feels like a conflict and I worry about how applications 
will deal with it.

theoretically, i'd say it is a new usage applications may (or may not) 
adapt to.
anyhow, from a business point of view, accepting a signature
without understanding its policy sounds strange;
i'd expect old applications to follow an
	adapt or ignore
policy with respect to this "strange" signerinfo

if you ignore the signature, there is no time-stamp
(by these means - still there are independent tokens,
and AdES formats; btw, also extended cms usage)

i do not foresee a big problem, but sure actual implementors have
something to say about

 > I have access to the drafts, but I was more interested in the review 
from other people in this group.

i think we can discuss on the list (and/or smime)
but distributing the documents is against iso nda
... as far as i know ...

jam

 >
 >
 > Stefan Santesson
 > Senior Program Manager
 > Windows Security, Standards

Date: Fri, 22 Sep 2006 07:53:40 +0100
Reply-To: "Iser Radford" <[email-masked]>
From: "Iser Radford" <[email-masked]>
To: <[email-masked]>
Subject: PHcqARfuMA

This is a multi-part message in MIME format.

------=_NextPart_000_02AF_01C6DE1C.382ECE80
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi

VALxUM $1 , 25

AMBxEN

CxALIS $3 , 75

VxAGRA $3 , 35

=20
http://www.jasedinkaslon.com

------=_NextPart_000_02AF_01C6DE1C.382ECE80
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<P>VALxUM $1 , 25</P>
<P>AMBxEN</P>
<P>CxALIS $3 , 75</P>
<P>VxAGRA $3 , 35</P>
<DIV>&nbsp;</DIV>
<DIV><A =
href=3D"http://www.jasedinkaslon.com">http://www.jasedinkaslon.com</A></D=
IV></BODY></HTML>
------=_NextPart_000_02AF_01C6DE1C.382ECE80--

Content-class: urn:content-classes:message
Subject: RE: New time stamping standard by ISO
Date: Fri, 22 Sep 2006 04:50:28 +0100
From: "Stefan Santesson" <[email-masked]>
To: =?iso-8859-1?Q?=22Jos=E9_A=2E_Ma=F1as=22?= <[email-masked]>
Cc: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

José

Thanks for the answer. This gets more into a CMS discussion and maybe should be moved the the S/MIME group, but the basic issues are 2.

1) The changes/amendments to RFC 3161 (even if it is a single bit, but in fact it is more. RFC 3161 restrict the CMS type to SignedData, the ISO draft does not)
2) The appropriateness of letting the TSA actually sign the time-stamped message, not just the time stamp info (TSTInfo).

> > But basically it is a breach of semantics that may lead to unexpected
> behaviors in legacy applications trying to understand the signatures of
> the CMS object.
> Mmmm,
> do you mean in applications that do not care after the policy that
> the signer applies to the signature?
>

I assume the choice of SignerInfo as alternative token structure is so that it will be included in a CMS SignedData.
However, this is not explicitly stated. If it is then the TSA has, by CMS definitions, just become signer of the encapsulated data, not only the timestamp.
But at the same time it has an extended key usage in its certificate that is incompatible with this role as message signer. They way I read CMS and Signed Data, the TSA can not only sign the signed attribute in SignerInfo, it MUST also sign the encapsulated data in SidnedData.

To me this feels like a conflict and I worry about how applications will deal with it. 

I have access to the drafts, but I was more interested in the review from other people in this group.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: "José A. Mañas" [mailto:[email-masked]]
> Sent: den 21 september 2006 16:23
> To: Stefan Santesson
> Cc: Peter Gutmann; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: New time stamping standard by ISO
> 
> Stefan Santesson wrote:
> > Hi José
> >
> > Since you participate in this effort in ISO, could you check if they
> for the interest of more effective liaison could make the draft
> available to people on this list.
> I can check, but the most likely answer is "no way".
> The right option is that you get involved as an sc27 expert in your
> country: you get drafts and the right to influence with your comments
> and your vote
> 
> > After personally reviewing this draft I discovered some compliance
> problems with rfc 3161 and I may no have caught it all.
> the iso standard is a 3 part standard
> 
> part 1 is rather stable, and just modifies one bit (on the wire)
> wrt 3161
> 
> part 2 is wide open currently, there have been 3 drafts,
> the last one late july;
> after reading your text below, it might well be you are dealing with
> an old one; but i am not sure
> 
> current draft is on the comment stage and will be discussed in november
> meeting
> 
> part 3 (about linked tokens) is not under modification
> 
> so i understand you refer to 18014-2
> 
> >
> > Critical parts or references to the full encoding of timeStampToken,
> especially the CMS parts, seems also be missing.
> >
> > As of the CMS "embeddable" tokens, I find no explanation or use case
> motivating it or any discussion on interoperability issues with CMS
> parsing applications.
> 
> that should be easy to repair,
> tough the phrasing
> 	"interoperability issues with CMS parsing applications"
> is too vague:
>    - asn1 parsing is too trivial for you to mention
>    - signerinfo parsing is as usual, up to signed attributes
>    - then there is a new kind of attribute with its own semantics
> 
> can you be more precise about your concern?
> 
> > The purpose seems to be to allow addition of a timestamp to a
> standard CMS object,
> 
> the purpose is to produce a SignerInfo where the signer is a TSA
> and the signed attribute is the time-value
> (plus plus for non-repudiation issues)
> 
> > however this is not the only result.
>  > This results also in the TSA blindly signing the CMS object, not
> just
> the time stamp.
> somehow
> 
> the tsa is not expected to have access to the actual contents,
> but as far as the message-digest attribute is present: yes,
> the tsa is actually signing it
> 
> current cms (3852) is strict in page 39
> "Within signed-data, the message-digest signed attribute type MUST be
>   present when there are any signed attributes present.  ..."
> 
> i guess you refer to that text
> 
> and the message-digest attribute is expected to be there
> since the tsa is using that piece of knowledge to bind the time to
> 
> > I assume the ISO standard think this is OK since the TSA certificate
> contains the id-kp-timeStamping EKU only.
> right
> 
> > But basically it is a breach of semantics that may lead to unexpected
> behaviors in legacy applications trying to understand the signatures of
> the CMS object.
> Mmmm,
> do you mean in applications that do not care after the policy that
> the signer applies to the signature?
> 
> > Do you have the full story?
> I´m not sure; so I tried to explain my point of view above...
> 
> best
> jam
> 
> >
> >
> > Stefan Santesson
> > Senior Program Manager
> > Windows Security, Standards
> >> From: "José A. Mañas" [mailto:[email-masked]]
> >> Sent: den 21 september 2006 14:21
> >> To: Peter Gutmann
> >> Cc: [email-masked]; [email-masked]; Stefan
> Santesson;
> >> [email-masked]
> >> Subject: Re: New time stamping standard by ISO
> >>
> >> I am working in the iso group updating the time-stamping standard.
> >> It is not so much a brand-new standard.
> >>
> >> I think everyone in the group understands that backwards
> >> compatibility with 3161 is a must;
> >> then we try to improve, and basically to standardize
> >> improvements so there is some agreed way of doing things right.
> >>
> >> The aims are
> >>    - to keep 3161 tokens
> >>    - to allow for cms "embeddable" tokens
> >>    - to align xml and asn1 tokens
> >>
> >> The new standard is still in the working draft stage,
> >> so there is room for listening as wide an audience as possible.
> >>
> >> Best
> >> jam
> >>
> >> Peter Gutmann wrote:
> >>> Russ Housley <[email-masked]> writes:
> >>>
> >>>> Yet, everyone implement it this way, right?
> >>> Well of course they implement it that way, because the spec says
> they
> >> have to.
> >>> If the spec said they had to run naked down the middle of the road
> in
> >> order to
> >>> claim RFC 3161 compliance they'd do that too, even though it's not
> a
> >> sensible
> >>> thing to do.
> >>>
> >>>> If there is a need for change, it should begin with an update to
> RFC
> >> 3161.
> >>> This problem was pointed out years ago, when the RFC was still in
> >> draft stage.
> >>> The authors ignored it, along with other comments people submitted
> >> about other
> >>> issues.  So I think ISO is the only forum for change.
> >>>
> >>> Peter.
> >>>
> >
> >

Date: Thu, 21 Sep 2006 19:21:48 -0700
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: Protecting Against Weak Hash Algorithms
Sender: [email-masked]

At 3:51 AM -0700 9/21/06, Santosh Chokhani wrote:
>Let us say that you as a signer is using SHA-1 and RSA.  I thought I can
>keep your signature, but create a payload using a weak hash scheme (say
>MD-4 or chokhani Hash) that is still lying in the relying party system.

I think that is only true if "weak" means susceptible to a preimage 
attack, not to the collision attacks we have been seeing. To date, 
none of the hash functions in use have been shown to be susceptible 
to exploitable preimage attacks.

Also, it is only true if the output size of the two hashes are the same, yes?

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: Protecting Against Weak Hash Algorithms
Date: Thu, 21 Sep 2006 14:48:21 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I am not a crypto mathematician.

I was doing protocol level analysis and reviewing the following Kaliski
paper 

http://www.rsasecurity.com/rsalabs/staff/bios/bkaliski/publications/hash
-firewalls/kaliski-hash-firewalls-ct-rsa-2002.pdf

Note that the paper was written 2002 (before all the hoopla about hash
functions).

The paper illustrates a theoretical attack against PKCS #1, Version 1.5.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Wan-Teh Chang
Sent: Thursday, September 21, 2006 10:11 AM
To: [email-masked]
Subject: Re: Protecting Against Weak Hash Algorithms

Santosh Chokhani wrote:
> Paul,
> 
> Let us say that you as a signer is using SHA-1 and RSA.  I thought I
can
> keep your signature, but create a payload using a weak hash scheme
(say
> MD-4 or chokhani Hash) that is still lying in the relying party
system.
> Since the identification of the hash algorithm to be used in
> verification lies with the payload, pointing to the weak hash OID will
> be part of creation of the material.

If I understand you correctly, your proposal is useful
for DSA and ECDSA signatures because the (r, s) components
don't tell you what hash algorithm should be used.  On
the other hand, your proposal isn't necessary for PKCS #1
v1.5 RSA signatures because the hash algorithm is also
encrypted along with the hash.

Seems like the attack you want to protect against also
requires that the weaker hash algorithm's output is the
same length as the hash algorithm used in the original
signature.  Right now MD2, MD4, and MD5 are probably
the only such hash algorithms(all 128 bits long).  But
none of these can be used with DSA and ECDSA.

Wan-Teh

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: 3280bis AIA caIssuer - Steep requirements or Non-interability
Date: Thu, 21 Sep 2006 23:25:09 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0119_01C6DDD5.2E4193E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If you follow the spec and want to be sure to be compatible with all =
compliant CAs your crypto software MUST support HTTP, LDAP, FTP(!), =
DAP(!), and SMTP(!) for accessing caIssuers data.
If it does not, it may fail to verify (servers) or may not let the =
client use a certificate in TLS-client-auth. since the path cannot be =
created.

According to off-list messages from the editors, the "community" behind =
a PKI is supposed to specify the rules required by "their" PKI.

Assume that the community is the Internet and there are numerous clients =
created by different vendors (who typically don't declare what they =
support in terms of AIA caIssuers access methods).

The Minimum

IMHO, a CA that creates a scheme that depends on the use of AIA =
caIssuers SHOULD or MUST deploy at least one HTTP URI.

If the idea is that PKI should sometimes down the road be able to =
challenge the zillions of user-id/passwords currently required by banks, =
community sites, governments, and employers, there should be no need to =
read the source code of implementations, hire pricy PKI consultants, or =
perform n*n product matrix testing just to get the path right.

If this change or recommendation is infeasible, the only reasonable =
work-around for an Internet-scale community is to follow the market =
leader who will define the actual standard.

Specifications versus Reality

Talking about market leaders I cannot help mentioning the AIA caIssuers =
extension URI I found in a recently received Microsoft certificate:
 http://www.microsoft.com/pki/mscorp/mswww(2).crt

W.r.t. to 3820bis it uses an incorrect file extension.  To make it even =
more "fun" it returns the non-standard MIME type: =
application/x-x509-ca-cert

Note: I still think this mess is the result of an initially =
underspecified, and delayed RFC, rather than a naughty vendor who don't =
care about standards.

Why not try to make it right when you actually have chance?

Like specifying a miinimalistic interoperable SHOULD/MUST scheme, and =
then describe (to the best of your ability), the "legacy" =
implementations that you MAY encounter.  This should NOT break any code =
but would lower the bar for new users of PKI.

Anders=20

------=_NextPart_000_0119_01C6DDD5.2E4193E0
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>If you follow the spec and want to be =
sure to be=20
compatible with all compliant CAs your crypto software MUST support =
HTTP, LDAP,=20
FTP(!), DAP(!), and SMTP(!) for accessing caIssuers data.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>If it does not, it may fail to verify =
(servers) or=20
may not let the client use a certificate in TLS-client-auth. since the =
path=20
cannot be created.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>According to off-list messages from the =
editors,=20
the "community" behind a PKI is supposed to specify the rules required =
by=20
"their" PKI.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Assume that the community is the =
Internet and there=20
are&nbsp;numerous&nbsp;clients created by different vendors (who =
typically don't=20
declare what they support in terms of AIA caIssuers access=20
methods).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>The =
Minimum</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>IMHO, a CA that creates a scheme that =
depends on=20
the use of AIA caIssuers SHOULD or MUST deploy at least one HTTP=20
URI.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>If the idea is that PKI should =
sometimes down=20
the&nbsp;road&nbsp;be able to challenge the zillions of =
user-id/passwords=20
currently required by banks, community sites, governments, and =
employers, there=20
should be no need to read the source code of implementations, hire pricy =
PKI=20
consultants, or perform n*n&nbsp;product matrix testing just to get the =
path=20
right.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>If this change or recommendation is =
infeasible,=20
<EM>the only reasonable work-around for an Internet-scale=20
community&nbsp;is&nbsp;to follow the market leader who&nbsp;will define =
the=20
actual standard</EM>.</FONT></DIV><FONT face=3DArial size=3D2>
<DIV>&nbsp;</DIV>
<DIV><STRONG>Specifications versus Reality</STRONG></DIV>
<DIV><BR>Talking about market leaders I cannot help mentioning the AIA =
caIssuers=20
extension URI I&nbsp;found in a recently received Microsoft =
certificate:</DIV>
<DIV>&nbsp;<A=20
href=3D"http://www.microsoft.com/pki/mscorp/mswww(2).crt">http://www.micr=
osoft.com/pki/mscorp/mswww(2).crt</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>W.r.t. to 3820bis it uses an <EM>incorrect file =
extension</EM>.&nbsp; To=20
make it even more "fun" it returns the non-standard MIME type: <FONT=20
face=3D"Courier New">application/x-x509-ca-cert</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Note: I still think this mess is the result of an initially =
underspecified,=20
and delayed&nbsp;RFC, rather than a naughty vendor who don't care about=20
standards.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Why not try to make it right when you actually have chance?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Like specifying a miinimalistic interoperable SHOULD/MUST scheme, =
and then=20
describe (to the best of your ability), the "legacy" implementations =
that you=20
MAY encounter.&nbsp; This should NOT break any code but would lower the =
bar for=20
new users of PKI.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders</FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0119_01C6DDD5.2E4193E0--

From: "Michael Myers" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Sharon Boeyen" <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 21 Sep 2006 07:22:29 -0800
Importance: Normal
Sender: [email-masked]

I agree with Stephen.  An individual I-D expressing a crisp problem
statement would be a useful point of focus.

Mike

-----Original Message-----
> From: Stephen Farrell
> Sent: Tuesday, September 19, 2006 10:39 AM
> Subject: Re: Certs in CRLs - New standards task?
>
>
> I'm not sure myself. But I would like to see an
> individual I-D before the WG adopted a work item.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: New time stamping standard by ISO
Cc: [email-masked]
Date: Fri, 22 Sep 2006 03:57:38 +1200
Sender: [email-masked]

"Stefan Santesson" <[email-masked]> writes:

>ISO can't change RFC 3161. 

True, but they can at least create a fixed version.

Peter.

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 21 Sep 2006 15:43:29 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DD8C.4E9187CF
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Sharon,

=20

We are facing real practical problems that benefit from this type of
solution. Have you read the cases described by Ryan Hurst in this
thread?

=20

> and would not cause problems that inclusion of a cert or bag of certs
would

=20

Can you elaborate the problems. How much extra downloading time would we
add on a CRL that has an extra certificate?

If my calculations are accurate, a certificate would add < 0.2 sec
downloading time in a 56k dialup connection and magnitudes less on a DSL
or LAN connection.

This is most likely much less it takes to initiate a new connection to a
new destination to retrieve the same certificate from a secondary
location.

=20

Both alternatives would still be possible, linking through AIA or
inclusion using a new extension. Why do feel that linking through AIA is
always better?

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: Sharon Boeyen [mailto:[email-masked]]=20
Sent: den 21 september 2006 16:20
To: Stefan Santesson; Stephen Farrell; Sharon Boeyen
Cc: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

=20

I still don't see the need to include certificates at all. I don't buy
the network connectivity argument as that would have prevented the path
to the cert from being established too. Also in establishing the
certificate path you may have already downloaded the cert you need
anyway. I think if anything new is added to a CRL, a pointer is a much
better solution and would not cause problems that inclusion of a cert or
bag of certs would.

Cheers,=20
Sharon=20

-----Original Message-----=20
From: Stefan Santesson [mailto:[email-masked]]=20
Sent: Wednesday, September 20, 2006 11:18 PM=20
To: Stephen Farrell; Sharon Boeyen=20
Cc: [email-masked]=20
Subject: RE: Certs in CRLs - New standards task?=20

=20

Sharon,=20

I'm not proposing a best practice document telling CAs to include
certificates in CRLs. So please don't read this as proposing - "All CRLs
MUST include certificates"

But for some PKI implementations, having a standardized way to include
certificates would avoid many problems, especially when indirect CRL's
are used or in some scenarios with re-keyed CAs where revocation of old
certs is performed by the new CA key. No RP need to understand or
process this extension, No CA have to include Certs in CRLs.

Would you still have a problem if a CA have the possibility to add
certificates to CRLs in cases where it make sense to do so?

Stephen,=20

I also think we have reached the point where an I-D is needed. I will
post one ASAP.=20

=20

Stefan Santesson=20
Senior Program Manager=20
Windows Security, Standards=20

> -----Original Message-----=20
> From: [email-masked] [mailto:owner-ietf-=20
> [email-masked]] On Behalf Of Stephen Farrell=20
> Sent: den 19 september 2006 20:39=20
> To: Sharon Boeyen=20
> Cc: [email-masked]=20
> Subject: Re: Certs in CRLs - New standards task?=20
>=20
>=20
>=20
> I'm not sure myself. But I would like to see an individual I-D before=20
> the WG adopted a work item.=20
>=20
> S.=20
>=20
> Sharon Boeyen wrote:=20
> > The more I think about this the more I dislike the approach of=20
> including=20
> > certs in the CRL. There are currently implementations that are able=20
> to=20
> > find all the paths they need with the current information in the CRL

> (by=20
> > using the DN to do a directory lookup). I recognize this isn't=20
always=20
> > the simplest way to find information and I do support pointer=20
schemes=20
> > such as AIA and SIA or another pointer approach. However I really=20
> don't=20
> > want to see the size of CRLs increased in the way they would be even

> if=20
> > a single cert was added, whether that be for indirect CRLs, CA key=20
> > rollovers or any other case.=20
> >=20
> > Stefan, its fine for you to say that implementers wouldn't need to=20
> > support the new extension, however as soon as a CA starts putting it

> in=20
> > there is an impact on all implementations because of the size of the

> CRL=20
> > (regardless of whether an implementation decides to process or=20
ignore=20
> > the non-critical extension).=20
> >=20
> > Cheers,=20
> > Sharon=20
> >=20
> > -----Original Message-----=20
> > From: [email-masked] [mailto:owner-ietf-=20
> [email-masked]]=20
> > On Behalf Of Julien Stern=20
> > Sent: Tuesday, September 19, 2006 5:15 AM=20
> > To: [email-masked]=20
> > Subject: Re: Certs in CRLs - New standards task?=20
> >=20
> >=20
> >=20
> > On Mon, Sep 18, 2006 at 04:41:29PM +0100, Stefan Santesson wrote:  >

> > Denis,  >=20
> >  > When this is not a good solution to your problem, then don't use=20
> it.=20
> >  >=20
> >  > Why MUST is be bad to send the certs with every CRL if the=20
> alternative=20
> >  > is to go out on the network and fetch the certificates using=20
extra=20
> >  > cycles.=20
> >  >=20
> >  > I may use the same CRL 100+ times before it expires for many=20
> different=20
> >  > certificates. We send certificates with every OCSP response and=20
we=20
> >  > don't consider that a problem.=20
> >=20
> > Stefan,=20
> >=20
> > if I may jump in. Sometimes, it IS a problem to send certificates=20
> with=20
> > OCSP responses. We have at least one example where we will have to=20
> use=20
> > OCSP responses without certificates due to size contraints.=20
> >=20
> > Admitelly, this case is rare, but there are scenarios where OCSP or=20
> CRL=20
> > size matters :)=20
> >=20
> > What would you think of having a standard way to request (and send)=20
> the=20
> > certificate(s) associated to a CRL without bundling them.=20
> >=20
> > One example (probably not the best but...) could be=20
> >=20
> > http://www.xxx.com/thecrl.der  --> Gives the bare CRL=20
> > http://www.xxx.com/thecrl.der?addcert  --> Gives the certificate,=20
> > followed by the bare CRL (so that you can stream).=20
> >=20
> > Regards,=20
> >=20
> > --=20
> > Julien=20
> >=20
> >  > Stefan Santesson=20
> >  >=20
> >  > Senior Program Manager=20
> >  >=20
> >  > Windows Security, Standards=20
> >  >=20
> >  > From: [email-masked]=20
> >  > [mailto:[email-masked]]=20
> >  > On Behalf Of Denis Pinkas=20
> >  > Sent: den 18 september 2006 06:10=20
> >  > To: [email-masked]=20
> >  > Subject: Re: Certs in CRLs - New standards task?=20
> >  >=20
> >  >=20
> >  >=20
> >  > ________________________________=20
> >  >=20
> >  > Stefan,=20
> >  >=20
> >  > My replies have [Denis] in front of them.=20
> >  >=20
> >  > Hi Denis,=20
> >  >=20
> >  > Speaking as an implementer and from the experience from how our=20
> own=20
> >  > products work, the issue and the solution is much more simple=20
than=20
> the=20
> >  > solution you propose.=20
> >  >=20
> >  >  The  validation engine does not need to know which certificate=20
> that=20
> >  > represents the old or the new CA key or what the hash of the  >=20
> > certificate is. The task of the validation engine for this issue=20
> is=20
> >  > simply to validate the signature of the CRL using a valid path to

> a=20
> >  > trusted root (being the same used to validate the target=20
> certificate).=20
> >  >=20
> >  > [Denis]  I disagree. Before the "validation engine" there is the=20
> "path=20
> >  > construction engine". Depending upon whether key rollover has=20
been=20
> or=20
> >  > has not been performed by the relying party, one or two=20
> certificates=20
> >  > may be needed. If the CRL issuer is servings multiple CAs, then a

> > > couple of certificates are needed for each CA. If we define a new

> > > extension, it MUST also be usable for a single CRL issued for  >=20
> > different CAs.  >=20
> >  > First of all the validation engine will try to build a path using

> all=20
> >  > certs from the validated path and all cashed and locally stored =20
> > > certificates and root keys. If this fails it could use the certs =20
> > > provided in the CRL using this new extension (just a bag of  >=20
> > certificates with no specific information).  >=20
> >  > [Denis] Ahhhhh! you just crossed the line: a bag of certificates=20
!=20
> >  >=20
> >  >  In the end, if the provided bag of certificates (typically only=20
1=20
> >  > certificate if present) does not help the RP, we did not do any =20
> > > particular damage to the RP (just slightly increased the CRL), we=20
> just=20
> >  > couldn't help him and he will now have to try directory search=20
etc=20
> as=20
> >  > before. But the fact is that by including certificate/s in the=20
CRL=20
> we=20
> >  > may in many PKI configurations considerably help the RP.  >=20
> >  > [Denis] You will need to transfer that bag of certificates every=20
> time.=20
> >  > This is not good. Instead of trying to convince that the=20
initially=20
> >  > proposed solution is the best, please take some time to consider=20
> the=20
> >  > benefits and drawbacks of the other solution I proposed.  >=20
> >  > I fully agree that this information can not be stored in an AIA.=20
A=20
> new=20
> >  > CRL extension is needed.=20
> >  >=20
> >  > Finally I don't agree to the term "overloading" here. We usually=20
> use=20
> >  > that term to describe when we stretch the semantics of existing=20
> fields=20
> >  > and name forms. This is just an new optional non-critical=20
> extension=20
> >  > with useful data, relevant to the processing of the CRL.  >=20
> >  > Denis=20
> >  >=20
> >  >=20
> >  >=20
> >  >=20
> >  >=20
> >  > Stefan Santesson=20
> >  >=20
> >  > Senior Program Manager=20
> >  >=20
> >  > Windows Security, Standards=20
> >  >=20
> >  > From: [email-masked]=20
> >  > [mailto:[email-masked]]=20
> >  > On Behalf Of Denis Pinkas=20
> >  > Sent: den 18 september 2006 00:51=20
> >  > To: [email-masked]=20
> >  > Subject: Re: Certs in CRLs - New standards task?=20
> >  >=20
> >  >=20
> >  >=20
> >  > Stefan,=20
> >  >=20
> >  >=20
> >  >=20
> >  > I am not in favour of the proposed approach.=20
> >  >=20
> >  >=20
> >  >=20
> >  > I have concern by always overloading the CRL, not simply with one

> >  > additional certificate,=20
> >  >=20
> >  > but with two additional certificates, because of CA key rollover.

> >  >=20
> >  >=20
> >  >=20
> >  > The situation will be even worse when a CRL issuer is trusted by=20
> more=20
> >  > than one CA=20
> >  >=20
> >  > to issue CRLs.=20
> >  >=20
> >  >=20
> >  >=20
> >  > Talking to you in your capacity of co-chair, I would like to=20
> recall=20
> >  > that the full story=20
> >  >=20
> >  > of how to check a CRL that is not issued by a CA is still not=20
> crystal=20
> >  > clear in 3280bis,=20
> >  >=20
> >  > and we should clarify that before. :-)=20
> >  >=20
> >  >=20
> >  >=20
> >  > Talking to you as PKIX member, I would favor the use of  one=20
> extension=20
> >  > with two pointers per CA:=20
> >  >=20
> >  >=20
> >  >=20
> >  >  - one pointing to the current or old certificate still valid,=20
and=20
> >  >=20
> >  >  - another one pointing the new or current certificate already=20
> valid.=20
> >  >=20
> >  >=20
> >  >=20
> >  > This will allow to fetch once the certificate(s) that is/are=20
> needed.=20
> >  >=20
> >  >=20
> >  >=20
> >  > The AIA extension is not the right vehicule, since it cannot=20
> include a=20
> >  > hash of the data that is pointed.=20
> >  >=20
> >  > We should add a hash of the certificate, which would allow to=20
make=20
> >  > sure that the right certificate=20
> >  >=20
> >  > was obtained without the need to build and verify the=20
> certification=20
> >  > path.=20
> >  >=20
> >  >=20
> >  >=20
> >  > >From the above observations, the problem is much more complex=20
> than=20
> >  > originally presented.=20
> >  >=20
> >  >=20
> >  >=20
> >  > Denis=20
> >  >=20
> >  >=20
> >  >=20
> >  > ________________________________=20
> >  >=20
> >  > Taking the pkix chair hat off and the vendor hat on=20
> >  >=20
> >  > I'm asking this group to consider a new standards task to solve a

> real=20
> >  > implementation issue with indirect CRLs and CRLs issued by a re-=20
> keyed=20
> >  > CA. I.e. where the target certificate and it's CRL are signed by

> > > different keys and the RP does not have access to the CRL Issuer =20
> > > certificate.  >=20
> >  > It is basically the same situation we solved with allowing the=20
AIA=20
> >  > extension in CRL's namely the problem to obtain the CRL issuer's

> > > certificate, alternatively, certificate path.  >=20
> >  > In our efforts to implement the AIA solution we have encountered=20
> some=20
> >  > real issues.=20
> >  >=20
> >  > 1)       Each time we are forced to go out and retrieve new=20
> information=20
> >  > on the network, we have a source of potential problems such as  >

> > unavailable network resources, timeouts etc. It all adds to the  >=20
> > validation time and harms the user experience.  >=20
> >  > 2)       The AIA in CRL's provide another opening for DoS attacks

> if=20
> >  > rouge CRL's point their AIA to a targeted web server. This is=20
> tough=20
> >  > not as serious as the DoS problems with AIA in certificates, but=20
> this=20
> >  > one we might avoid more easily.=20
> >  >=20
> >  >  The proposed solution is to define a new CRL extension that may

> > > contain the CRL Issuer certificate (not just a URL to its=20
> location).=20
> >  > Preferably this would be a PKCS#7 (or CMS) Certs only message=20
that=20
> may=20
> >  > contain a single certificate or a bag of certificates (a chain).

> > >  >  While it wouldn't be attractive to define such extension for=20
> >  > certificates due to certificate size considerations, CRL's are=20
> often=20
> >  > of such size that including the certs needed to validate it only=20
> leads=20
> >  > to an insignificant increase of size, while it may offer=20
> substantial=20
> >  > processing advantages.=20
> >  >=20
> >  >  I would like to hear the opinion of this group on this.  >=20
> >  >  I volunteer to write a first draft if there is interest from the

> >  > group.=20
> >  >=20
> >  >=20
> >  >=20
> >  > Stefan Santesson=20
> >  >=20
> >  > Senior Program Manager=20
> >  >=20
> >  > Windows Security, Standards=20
> >  >=20
> >  >=20
> >  >=20
> >  > ________________________________=20
> >  >=20
> >  > ________________________________=20
> >  >=20
> >=20

------_=_NextPart_001_01C6DD8C.4E9187CF
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>We are facing real practical problems that benefit from =
this
type of solution. Have you read the cases described by Ryan Hurst in =
this
thread?<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&gt;</span><span lang=3DEN-US style=3D'font-size:10.0pt'> =
and would
not cause problems that inclusion of a cert or bag of certs =
would</span><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Can you elaborate the problems. How much extra =
downloading time
would we add on a CRL that has an extra =
certificate?<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If my calculations are accurate, a certificate would add =
&lt;
0.2 sec downloading time in a 56k dialup connection and magnitudes less =
on a
DSL or LAN connection.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>This is most likely much less it takes to initiate a new
connection to a new destination to retrieve the same certificate from a =
secondary
location.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Both alternatives would still be possible, linking =
through AIA
or inclusion using a new extension. Why do feel that linking through AIA =
is always
better?<o:p></o:p></span></p>

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

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

<div>

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

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

</div>

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

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

<div>

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

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Sharon Boeyen
[mailto:[email-masked]] <br>
<b>Sent:</b> den 21 september 2006 16:20<br>
<b>To:</b> Stefan Santesson; Stephen Farrell; Sharon Boeyen<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> RE: Certs in CRLs - New standards =
task?<o:p></o:p></span></p>

</div>

</div>

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

<p><span style=3D'font-size:10.0pt'>I still don't see the need to =
include
certificates at all. I don't buy the network connectivity argument as =
that
would have prevented the path to the cert from being established too. =
Also in
establishing the certificate path you may have already downloaded the =
cert you
need anyway. I think if anything new is added to a CRL, a pointer is a =
much
better solution and would not cause problems that inclusion of a cert or =
bag of
certs would.</span><o:p></o:p></p>

<p><span style=3D'font-size:10.0pt'>Cheers,</span> <br>
<span style=3D'font-size:10.0pt'>Sharon</span> <o:p></o:p></p>

<p><span style=3D'font-size:10.0pt'>-----Original Message-----</span> =
<br>
<span style=3D'font-size:10.0pt'>From: Stefan Santesson [<a
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>] =
</span><br>
<span style=3D'font-size:10.0pt'>Sent: Wednesday, September 20, 2006 =
11:18 PM</span>
<br>
<span style=3D'font-size:10.0pt'>To: Stephen Farrell; Sharon =
Boeyen</span> <br>
<span style=3D'font-size:10.0pt'>Cc: [email-masked]</span> <br>
<span style=3D'font-size:10.0pt'>Subject: RE: Certs in CRLs - New =
standards task?</span>
<o:p></o:p></p>

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

<p><span style=3D'font-size:10.0pt'>Sharon,</span> <o:p></o:p></p>

<p><span style=3D'font-size:10.0pt'>I'm not proposing a best practice =
document
telling CAs to include certificates in CRLs. So please don't read this =
as
proposing - &quot;All CRLs MUST include =
certificates&quot;</span><o:p></o:p></p>

<p><span style=3D'font-size:10.0pt'>But for some PKI implementations, =
having a
standardized way to include certificates would avoid many problems, =
especially
when indirect CRL's are used or in some scenarios with re-keyed CAs =
where
revocation of old certs is performed by the new CA key. No RP need to
understand or process this extension, No CA have to include Certs in =
CRLs.</span><o:p></o:p></p>

<p><span style=3D'font-size:10.0pt'>Would you still have a problem if a =
CA have
the possibility to add certificates to CRLs in cases where it make sense =
to do
so?</span><o:p></o:p></p>

<p><span style=3D'font-size:10.0pt'>Stephen,</span> <o:p></o:p></p>

<p><span style=3D'font-size:10.0pt'>I also think we have reached the =
point where
an I-D is needed. I will post one ASAP.</span> <o:p></o:p></p>

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

<p><span style=3D'font-size:10.0pt'>Stefan Santesson</span> <br>
<span style=3D'font-size:10.0pt'>Senior Program Manager</span> <br>
<span style=3D'font-size:10.0pt'>Windows Security, Standards</span> =
<o:p></o:p></p>

<p><span style=3D'font-size:10.0pt'>&gt; -----Original =
Message-----</span> <br>
<span style=3D'font-size:10.0pt'>&gt; From: [email-masked] =
[<a
href=3D"mailto:owner-ietf-">mailto:owner-ietf-</a> </span><br>
<span style=3D'font-size:10.0pt'>&gt; [email-masked]] On Behalf Of =
Stephen
Farrell</span> <br>
<span style=3D'font-size:10.0pt'>&gt; Sent: den 19 september 2006 =
20:39</span> <br>
<span style=3D'font-size:10.0pt'>&gt; To: Sharon Boeyen</span> <br>
<span style=3D'font-size:10.0pt'>&gt; Cc: [email-masked]</span> <br>
<span style=3D'font-size:10.0pt'>&gt; Subject: Re: Certs in CRLs - New =
standards
task?</span> <br>
<span style=3D'font-size:10.0pt'>&gt; </span><br>
<span style=3D'font-size:10.0pt'>&gt; </span><br>
<span style=3D'font-size:10.0pt'>&gt; </span><br>
<span style=3D'font-size:10.0pt'>&gt; I'm not sure myself. But I would =
like to
see an individual I-D before </span><br>
<span style=3D'font-size:10.0pt'>&gt; the WG adopted a work item.</span> =
<br>
<span style=3D'font-size:10.0pt'>&gt; </span><br>
<span style=3D'font-size:10.0pt'>&gt; S.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; </span><br>
<span style=3D'font-size:10.0pt'>&gt; Sharon Boeyen wrote:</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; The more I think about this =
the more I
dislike the approach of</span> <br>
<span style=3D'font-size:10.0pt'>&gt; including</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; certs in the CRL. There are =
currently
implementations that are able</span> <br>
<span style=3D'font-size:10.0pt'>&gt; to</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; find all the paths they need =
with the
current information in the CRL</span> <br>
<span style=3D'font-size:10.0pt'>&gt; (by</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; using the DN to do a =
directory
lookup). I recognize this isn't</span> <br>
<span style=3D'font-size:10.0pt'>always</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; the simplest way to find =
information
and I do support pointer</span> <br>
<span style=3D'font-size:10.0pt'>schemes</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; such as AIA and SIA or =
another pointer
approach. However I really</span> <br>
<span style=3D'font-size:10.0pt'>&gt; don't</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; want to see the size of CRLs =
increased
in the way they would be even</span> <br>
<span style=3D'font-size:10.0pt'>&gt; if</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; a single cert was added, =
whether that
be for indirect CRLs, CA key </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; rollovers or any other =
case.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; Stefan, its fine for you to =
say that
implementers wouldn't need to </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; support the new extension, =
however as
soon as a CA starts putting it</span> <br>
<span style=3D'font-size:10.0pt'>&gt; in</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; there is an impact on all
implementations because of the size of the</span> <br>
<span style=3D'font-size:10.0pt'>&gt; CRL</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; (regardless of whether an
implementation decides to process or</span> <br>
<span style=3D'font-size:10.0pt'>ignore</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; the non-critical =
extension).</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; Cheers,</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; Sharon</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; -----Original =
Message-----</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; From: =
[email-masked] [<a
href=3D"mailto:owner-ietf-">mailto:owner-ietf-</a></span> <br>
<span style=3D'font-size:10.0pt'>&gt; [email-masked]]</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; On Behalf Of Julien =
Stern</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; Sent: Tuesday, September 19, =
2006 5:15
AM</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; To: [email-masked]</span> =
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt; Subject: Re: Certs in CRLs - =
New
standards task?</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; On Mon, Sep 18, 2006 at =
04:41:29PM
+0100, Stefan Santesson wrote:&nbsp; &gt; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; Denis,&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; When this is not a =
good
solution to your problem, then don't use</span> <br>
<span style=3D'font-size:10.0pt'>&gt; it.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Why MUST is be bad =
to send
the certs with every CRL if the</span> <br>
<span style=3D'font-size:10.0pt'>&gt; alternative</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; is to go out on =
the network
and fetch the certificates using</span> <br>
<span style=3D'font-size:10.0pt'>extra</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; cycles.</span> =
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; I may use the same =
CRL 100+
times before it expires for many</span> <br>
<span style=3D'font-size:10.0pt'>&gt; different</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; certificates. We =
send
certificates with every OCSP response and</span> <br>
<span style=3D'font-size:10.0pt'>we</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; don't consider =
that a
problem.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; Stefan,</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; if I may jump in. Sometimes, =
it IS a
problem to send certificates</span> <br>
<span style=3D'font-size:10.0pt'>&gt; with</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; OCSP responses. We have at =
least one
example where we will have to</span> <br>
<span style=3D'font-size:10.0pt'>&gt; use</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; OCSP responses without =
certificates
due to size contraints.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; Admitelly, this case is rare, =
but
there are scenarios where OCSP or</span> <br>
<span style=3D'font-size:10.0pt'>&gt; CRL</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; size matters :)</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; What would you think of =
having a
standard way to request (and send)</span> <br>
<span style=3D'font-size:10.0pt'>&gt; the</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; certificate(s) associated to =
a CRL
without bundling them.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; One example (probably not the =
best
but...) could be</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; <a =
href=3D"http://www.xxx.com/thecrl.der"
target=3D"_blank">http://www.xxx.com/thecrl.der</a>&nbsp; --&gt; Gives =
the bare
CRL </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; <a
href=3D"http://www.xxx.com/thecrl.der?addcert" =
target=3D"_blank">http://www.xxx.com/thecrl.der?addcert</a>&nbsp;
--&gt; Gives the certificate, </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; followed by the bare CRL (so =
that you
can stream).</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; Regards,</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; --</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt; Julien</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Stefan =
Santesson</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Senior Program =
Manager</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Windows Security, =
Standards</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; From:
[email-masked]</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; [<a
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; On Behalf Of Denis =
Pinkas</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Sent: den 18 =
september 2006
06:10</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; To: =
[email-masked]</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Subject: Re: Certs =
in CRLs
- New standards task?</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;
________________________________</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Stefan,</span> =
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; My replies have =
[Denis] in
front of them.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Hi Denis,</span> =
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Speaking as an =
implementer
and from the experience from how our</span> <br>
<span style=3D'font-size:10.0pt'>&gt; own</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; products work, the =
issue
and the solution is much more simple</span> <br>
<span style=3D'font-size:10.0pt'>than</span> <br>
<span style=3D'font-size:10.0pt'>&gt; the</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; solution you =
propose.</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;&nbsp; The&nbsp; =
validation
engine does not need to know which certificate</span> <br>
<span style=3D'font-size:10.0pt'>&gt; that</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; represents the old =
or the
new CA key or what the hash of the&nbsp; &gt; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; certificate is. The task of =
the
validation engine for this issue</span> <br>
<span style=3D'font-size:10.0pt'>&gt; is</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; simply to validate =
the
signature of the CRL using a valid path to</span> <br>
<span style=3D'font-size:10.0pt'>&gt; a</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; trusted root =
(being the
same used to validate the target</span> <br>
<span style=3D'font-size:10.0pt'>&gt; certificate).</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; [Denis]&nbsp; I =
disagree.
Before the &quot;validation engine&quot; there is the</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &quot;path</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; construction =
engine&quot;.
Depending upon whether key rollover has</span> <br>
<span style=3D'font-size:10.0pt'>been</span> <br>
<span style=3D'font-size:10.0pt'>&gt; or</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; has not been =
performed by
the relying party, one or two</span> <br>
<span style=3D'font-size:10.0pt'>&gt; certificates</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; may be needed. If =
the CRL
issuer is servings multiple CAs, then a&nbsp; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; &gt; couple of certificates =
are needed
for each CA. If we define a new&nbsp; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; &gt; extension, it MUST also =
be usable
for a single CRL issued for&nbsp; &gt; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; different CAs.&nbsp; =
&gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; First of all the =
validation
engine will try to build a path using</span> <br>
<span style=3D'font-size:10.0pt'>&gt; all</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; certs from the =
validated
path and all cashed and locally stored&nbsp; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; &gt; certificates and root =
keys. If
this fails it could use the certs&nbsp; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; &gt; provided in the CRL =
using this
new extension (just a bag of&nbsp; &gt; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; certificates with no specific
information).&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; [Denis] Ahhhhh! =
you just
crossed the line: a bag of certificates</span> <br>
<span style=3D'font-size:10.0pt'>!</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;&nbsp; In the end, =
if the
provided bag of certificates (typically only</span> <br>
<span style=3D'font-size:10.0pt'>1</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; certificate if =
present)
does not help the RP, we did not do any&nbsp; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; &gt; particular damage to the =
RP (just
slightly increased the CRL), we</span> <br>
<span style=3D'font-size:10.0pt'>&gt; just</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; couldn't help him =
and he
will now have to try directory search</span> <br>
<span style=3D'font-size:10.0pt'>etc</span> <br>
<span style=3D'font-size:10.0pt'>&gt; as</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; before. But the =
fact is
that by including certificate/s in the</span> <br>
<span style=3D'font-size:10.0pt'>CRL</span> <br>
<span style=3D'font-size:10.0pt'>&gt; we</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; may in many PKI
configurations considerably help the RP.&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; [Denis] You will =
need to
transfer that bag of certificates every</span> <br>
<span style=3D'font-size:10.0pt'>&gt; time.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; This is not good. =
Instead
of trying to convince that the</span> <br>
<span style=3D'font-size:10.0pt'>initially</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; proposed solution =
is the
best, please take some time to consider</span> <br>
<span style=3D'font-size:10.0pt'>&gt; the</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; benefits and =
drawbacks of
the other solution I proposed.&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; I fully agree that =
this
information can not be stored in an AIA.</span> <br>
<span style=3D'font-size:10.0pt'>A</span> <br>
<span style=3D'font-size:10.0pt'>&gt; new</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; CRL extension is =
needed.</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Finally I don't =
agree to
the term &quot;overloading&quot; here. We usually</span> <br>
<span style=3D'font-size:10.0pt'>&gt; use</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; that term to =
describe when
we stretch the semantics of existing</span> <br>
<span style=3D'font-size:10.0pt'>&gt; fields</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; and name forms. =
This is
just an new optional non-critical</span> <br>
<span style=3D'font-size:10.0pt'>&gt; extension</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; with useful data, =
relevant
to the processing of the CRL.&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Denis</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Stefan =
Santesson</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Senior Program =
Manager</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Windows Security, =
Standards</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; From:
[email-masked]</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; [<a
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; On Behalf Of Denis =
Pinkas</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Sent: den 18 =
september 2006
00:51</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; To: =
[email-masked]</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Subject: Re: Certs =
in CRLs
- New standards task?</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Stefan,</span> =
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; I am not in favour =
of the
proposed approach.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; I have concern by =
always
overloading the CRL, not simply with one</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; additional =
certificate,</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; but with two =
additional certificates,
because of CA key rollover.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; The situation will =
be even
worse when a CRL issuer is trusted by</span> <br>
<span style=3D'font-size:10.0pt'>&gt; more</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; than one CA</span> =
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; to issue =
CRLs.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Talking to you in =
your capacity
of co-chair, I would like to</span> <br>
<span style=3D'font-size:10.0pt'>&gt; recall</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; that the full =
story</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; of how to check a =
CRL that
is not issued by a CA is still not</span> <br>
<span style=3D'font-size:10.0pt'>&gt; crystal</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; clear in =
3280bis,</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; and we should =
clarify that
before. :-)</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Talking to you as =
PKIX
member, I would favor the use of&nbsp; one</span> <br>
<span style=3D'font-size:10.0pt'>&gt; extension</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; with two pointers =
per CA:</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;&nbsp; - one =
pointing to the
current or old certificate still valid,</span> <br>
<span style=3D'font-size:10.0pt'>and</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;&nbsp; - another =
one
pointing the new or current certificate already</span> <br>
<span style=3D'font-size:10.0pt'>&gt; valid.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; This will allow to =
fetch
once the certificate(s) that is/are</span> <br>
<span style=3D'font-size:10.0pt'>&gt; needed.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; The AIA extension =
is not
the right vehicule, since it cannot</span> <br>
<span style=3D'font-size:10.0pt'>&gt; include a</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; hash of the data =
that is
pointed.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; We should add a =
hash of the
certificate, which would allow to</span> <br>
<span style=3D'font-size:10.0pt'>make</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; sure that the =
right
certificate</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; was obtained =
without the
need to build and verify the</span> <br>
<span style=3D'font-size:10.0pt'>&gt; certification</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; path.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; &gt;From the above
observations, the problem is much more complex</span> <br>
<span style=3D'font-size:10.0pt'>&gt; than</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; originally =
presented.</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Denis</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; =
________________________________</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Taking the pkix =
chair hat
off and the vendor hat on</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; I'm asking this =
group to
consider a new standards task to solve a</span> <br>
<span style=3D'font-size:10.0pt'>&gt; real</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; implementation =
issue with
indirect CRLs and CRLs issued by a re-</span> <br>
<span style=3D'font-size:10.0pt'>&gt; keyed</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; CA. I.e. where the =
target
certificate and it's CRL are signed by&nbsp; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; &gt; different keys and the =
RP does
not have access to the CRL Issuer&nbsp; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; &gt; certificate.&nbsp; =
&gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; It is basically =
the same
situation we solved with allowing the</span> <br>
<span style=3D'font-size:10.0pt'>AIA</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; extension in CRL's =
namely
the problem to obtain the CRL issuer's&nbsp; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; &gt; certificate, =
alternatively,
certificate path.&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; In our efforts to =
implement
the AIA solution we have encountered</span> <br>
<span style=3D'font-size:10.0pt'>&gt; some</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; real =
issues.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;
1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Each time we are forced to go out =
and
retrieve new</span> <br>
<span style=3D'font-size:10.0pt'>&gt; information</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; on the network, we =
have a
source of potential problems such as&nbsp; &gt; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; unavailable network =
resources,
timeouts etc. It all adds to the&nbsp; &gt; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; validation time and harms the =
user
experience.&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;
2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The AIA in CRL's provide another =
opening
for DoS attacks</span> <br>
<span style=3D'font-size:10.0pt'>&gt; if</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; rouge CRL's point =
their AIA
to a targeted web server. This is</span> <br>
<span style=3D'font-size:10.0pt'>&gt; tough</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; not as serious as =
the DoS
problems with AIA in certificates, but</span> <br>
<span style=3D'font-size:10.0pt'>&gt; this</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; one we might avoid =
more
easily.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;&nbsp; The proposed =
solution
is to define a new CRL extension that may&nbsp; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; &gt; contain the CRL Issuer
certificate (not just a URL to its</span> <br>
<span style=3D'font-size:10.0pt'>&gt; location).</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Preferably this =
would be a
PKCS#7 (or CMS) Certs only message</span> <br>
<span style=3D'font-size:10.0pt'>that</span> <br>
<span style=3D'font-size:10.0pt'>&gt; may</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; contain a single
certificate or a bag of certificates (a chain).&nbsp; </span><br>
<span style=3D'font-size:10.0pt'>&gt; &gt; &gt;&nbsp; &gt;&nbsp; While =
it
wouldn't be attractive to define such extension for</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; certificates due =
to
certificate size considerations, CRL's are</span> <br>
<span style=3D'font-size:10.0pt'>&gt; often</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; of such size that =
including
the certs needed to validate it only</span> <br>
<span style=3D'font-size:10.0pt'>&gt; leads</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; to an =
insignificant
increase of size, while it may offer</span> <br>
<span style=3D'font-size:10.0pt'>&gt; substantial</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; processing =
advantages.</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;&nbsp; I would like =
to hear
the opinion of this group on this.&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;&nbsp; I volunteer =
to write
a first draft if there is interest from the</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; group.</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Stefan =
Santesson</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Senior Program =
Manager</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; Windows Security, =
Standards</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt; =
________________________________</span>
<br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;
________________________________</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;&nbsp; &gt;</span> <br>
<span style=3D'font-size:10.0pt'>&gt; &gt;</span> <o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C6DD8C.4E9187CF--

Date: Thu, 21 Sep 2006 16:22:38 +0200
From: =?ISO-8859-1?Q?=22Jos=E9_A=2E_Ma=F1as=22?= <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Peter Gutmann <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

Stefan Santesson wrote:
> Hi José
> 
> Since you participate in this effort in ISO, could you check if they for the interest of more effective liaison could make the draft available to people on this list.
I can check, but the most likely answer is "no way".
The right option is that you get involved as an sc27 expert in your
country: you get drafts and the right to influence with your comments
and your vote

> After personally reviewing this draft I discovered some compliance problems with rfc 3161 and I may no have caught it all.
the iso standard is a 3 part standard

part 1 is rather stable, and just modifies one bit (on the wire)
wrt 3161

part 2 is wide open currently, there have been 3 drafts,
the last one late july;
after reading your text below, it might well be you are dealing with
an old one; but i am not sure

current draft is on the comment stage and will be discussed in november 
meeting

part 3 (about linked tokens) is not under modification

so i understand you refer to 18014-2

> 
> Critical parts or references to the full encoding of timeStampToken, especially the CMS parts, seems also be missing.
> 
> As of the CMS "embeddable" tokens, I find no explanation or use case motivating it or any discussion on interoperability issues with CMS parsing applications.

that should be easy to repair,
tough the phrasing
	"interoperability issues with CMS parsing applications"
is too vague:
   - asn1 parsing is too trivial for you to mention
   - signerinfo parsing is as usual, up to signed attributes
   - then there is a new kind of attribute with its own semantics

can you be more precise about your concern?

> The purpose seems to be to allow addition of a timestamp to a standard CMS object,

the purpose is to produce a SignerInfo where the signer is a TSA
and the signed attribute is the time-value
(plus plus for non-repudiation issues)

> however this is not the only result.
 > This results also in the TSA blindly signing the CMS object, not just 
the time stamp.
somehow

the tsa is not expected to have access to the actual contents,
but as far as the message-digest attribute is present: yes,
the tsa is actually signing it

current cms (3852) is strict in page 39
"Within signed-data, the message-digest signed attribute type MUST be
  present when there are any signed attributes present.  ..."

i guess you refer to that text

and the message-digest attribute is expected to be there
since the tsa is using that piece of knowledge to bind the time to

> I assume the ISO standard think this is OK since the TSA certificate contains the id-kp-timeStamping EKU only.
right

> But basically it is a breach of semantics that may lead to unexpected behaviors in legacy applications trying to understand the signatures of the CMS object.
Mmmm,
do you mean in applications that do not care after the policy that
the signer applies to the signature?

> Do you have the full story?
I´m not sure; so I tried to explain my point of view above...

best
jam

>  
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>> From: "José A. Mañas" [mailto:[email-masked]]
>> Sent: den 21 september 2006 14:21
>> To: Peter Gutmann
>> Cc: [email-masked]; [email-masked]; Stefan Santesson;
>> [email-masked]
>> Subject: Re: New time stamping standard by ISO
>>
>> I am working in the iso group updating the time-stamping standard.
>> It is not so much a brand-new standard.
>>
>> I think everyone in the group understands that backwards
>> compatibility with 3161 is a must;
>> then we try to improve, and basically to standardize
>> improvements so there is some agreed way of doing things right.
>>
>> The aims are
>>    - to keep 3161 tokens
>>    - to allow for cms "embeddable" tokens
>>    - to align xml and asn1 tokens
>>
>> The new standard is still in the working draft stage,
>> so there is room for listening as wide an audience as possible.
>>
>> Best
>> jam
>>
>> Peter Gutmann wrote:
>>> Russ Housley <[email-masked]> writes:
>>>
>>>> Yet, everyone implement it this way, right?
>>> Well of course they implement it that way, because the spec says they
>> have to.
>>> If the spec said they had to run naked down the middle of the road in
>> order to
>>> claim RFC 3161 compliance they'd do that too, even though it's not a
>> sensible
>>> thing to do.
>>>
>>>> If there is a need for change, it should begin with an update to RFC
>> 3161.
>>> This problem was pointed out years ago, when the RFC was still in
>> draft stage.
>>> The authors ignored it, along with other comments people submitted
>> about other
>>> issues.  So I think ISO is the only forum for change.
>>>
>>> Peter.
>>>
> 
> 

From: Sharon Boeyen <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Stephen Farrell <[email-masked]>, Sharon Boeyen <[email-masked]>
Cc: [email-masked]
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 21 Sep 2006 10:19:38 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C6DD88.BEE62B60
Content-Type: text/plain

I still don't see the need to include certificates at all. I don't buy the
network connectivity argument as that would have prevented the path to the
cert from being established too. Also in establishing the certificate path
you may have already downloaded the cert you need anyway. I think if
anything new is added to a CRL, a pointer is a much better solution and
would not cause problems that inclusion of a cert or bag of certs would.

Cheers,
Sharon

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 11:18 PM
To: Stephen Farrell; Sharon Boeyen
Cc: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Sharon,

I'm not proposing a best practice document telling CAs to include
certificates in CRLs. So please don't read this as proposing - "All CRLs
MUST include certificates"

But for some PKI implementations, having a standardized way to include
certificates would avoid many problems, especially when indirect CRL's are
used or in some scenarios with re-keyed CAs where revocation of old certs is
performed by the new CA key. No RP need to understand or process this
extension, No CA have to include Certs in CRLs.

Would you still have a problem if a CA have the possibility to add
certificates to CRLs in cases where it make sense to do so?

Stephen,

I also think we have reached the point where an I-D is needed. I will post
one ASAP.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> [email-masked]] On Behalf Of Stephen Farrell
> Sent: den 19 september 2006 20:39
> To: Sharon Boeyen
> Cc: [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
> 
> 
> I'm not sure myself. But I would like to see an individual I-D before 
> the WG adopted a work item.
> 
> S.
> 
> Sharon Boeyen wrote:
> > The more I think about this the more I dislike the approach of
> including
> > certs in the CRL. There are currently implementations that are able
> to
> > find all the paths they need with the current information in the CRL
> (by
> > using the DN to do a directory lookup). I recognize this isn't
always
> > the simplest way to find information and I do support pointer
schemes
> > such as AIA and SIA or another pointer approach. However I really
> don't
> > want to see the size of CRLs increased in the way they would be even
> if
> > a single cert was added, whether that be for indirect CRLs, CA key 
> > rollovers or any other case.
> >
> > Stefan, its fine for you to say that implementers wouldn't need to 
> > support the new extension, however as soon as a CA starts putting it
> in
> > there is an impact on all implementations because of the size of the
> CRL
> > (regardless of whether an implementation decides to process or
ignore
> > the non-critical extension).
> >
> > Cheers,
> > Sharon
> >
> [email-masked]]
> > On Behalf Of Julien Stern
> > Sent: Tuesday, September 19, 2006 5:15 AM
> > To: [email-masked]
> > Subject: Re: Certs in CRLs - New standards task?
> >
> >
> >
> > On Mon, Sep 18, 2006 at 04:41:29PM +0100, Stefan Santesson wrote:  > 
> > Denis,  >
> >  > When this is not a good solution to your problem, then don't use
> it.
> >  >
> >  > Why MUST is be bad to send the certs with every CRL if the
> alternative
> >  > is to go out on the network and fetch the certificates using
extra
> >  > cycles.
> >  >
> >  > I may use the same CRL 100+ times before it expires for many
> different
> >  > certificates. We send certificates with every OCSP response and
we
> >  > don't consider that a problem.
> >
> > Stefan,
> >
> > if I may jump in. Sometimes, it IS a problem to send certificates
> with
> > OCSP responses. We have at least one example where we will have to
> use
> > OCSP responses without certificates due to size contraints.
> >
> > Admitelly, this case is rare, but there are scenarios where OCSP or
> CRL
> > size matters :)
> >
> > What would you think of having a standard way to request (and send)
> the
> > certificate(s) associated to a CRL without bundling them.
> >
> > One example (probably not the best but...) could be
> >
> > http://www.xxx.com/thecrl.der  --> Gives the bare CRL 
> > http://www.xxx.com/thecrl.der?addcert  --> Gives the certificate, 
> > followed by the bare CRL (so that you can stream).
> >
> > Regards,
> >
> > --
> > Julien
> >
> >  > Stefan Santesson
> >  >
> >  > Senior Program Manager
> >  >
> >  > Windows Security, Standards
> >  >
> >  > From: [email-masked]
> >  > [mailto:[email-masked]]
> >  > On Behalf Of Denis Pinkas
> >  > Sent: den 18 september 2006 06:10
> >  > To: [email-masked]
> >  > Subject: Re: Certs in CRLs - New standards task?
> >  >
> >  >
> >  >
> >  > ________________________________
> >  >
> >  > Stefan,
> >  >
> >  > My replies have [Denis] in front of them.
> >  >
> >  > Hi Denis,
> >  >
> >  > Speaking as an implementer and from the experience from how our
> own
> >  > products work, the issue and the solution is much more simple
than
> the
> >  > solution you propose.
> >  >
> >  >  The  validation engine does not need to know which certificate
> that
> >  > represents the old or the new CA key or what the hash of the  > 
> > certificate is. The task of the validation engine for this issue
> is
> >  > simply to validate the signature of the CRL using a valid path to
> a
> >  > trusted root (being the same used to validate the target
> certificate).
> >  >
> >  > [Denis]  I disagree. Before the "validation engine" there is the
> "path
> >  > construction engine". Depending upon whether key rollover has
been
> or
> >  > has not been performed by the relying party, one or two
> certificates
> >  > may be needed. If the CRL issuer is servings multiple CAs, then a  
> > > couple of certificates are needed for each CA. If we define a new  
> > > extension, it MUST also be usable for a single CRL issued for  > 
> > different CAs.  >
> >  > First of all the validation engine will try to build a path using
> all
> >  > certs from the validated path and all cashed and locally stored  
> > > certificates and root keys. If this fails it could use the certs  
> > > provided in the CRL using this new extension (just a bag of  > 
> > certificates with no specific information).  >
> >  > [Denis] Ahhhhh! you just crossed the line: a bag of certificates
!
> >  >
> >  >  In the end, if the provided bag of certificates (typically only
1
> >  > certificate if present) does not help the RP, we did not do any  
> > > particular damage to the RP (just slightly increased the CRL), we
> just
> >  > couldn't help him and he will now have to try directory search
etc
> as
> >  > before. But the fact is that by including certificate/s in the
CRL
> we
> >  > may in many PKI configurations considerably help the RP.  >
> >  > [Denis] You will need to transfer that bag of certificates every
> time.
> >  > This is not good. Instead of trying to convince that the
initially
> >  > proposed solution is the best, please take some time to consider
> the
> >  > benefits and drawbacks of the other solution I proposed.  >
> >  > I fully agree that this information can not be stored in an AIA.
A
> new
> >  > CRL extension is needed.
> >  >
> >  > Finally I don't agree to the term "overloading" here. We usually
> use
> >  > that term to describe when we stretch the semantics of existing
> fields
> >  > and name forms. This is just an new optional non-critical
> extension
> >  > with useful data, relevant to the processing of the CRL.  >
> >  > Denis
> >  >
> >  >
> >  >
> >  >
> >  >
> >  > Stefan Santesson
> >  >
> >  > Senior Program Manager
> >  >
> >  > Windows Security, Standards
> >  >
> >  > From: [email-masked]
> >  > [mailto:[email-masked]]
> >  > On Behalf Of Denis Pinkas
> >  > Sent: den 18 september 2006 00:51
> >  > To: [email-masked]
> >  > Subject: Re: Certs in CRLs - New standards task?
> >  >
> >  >
> >  >
> >  > Stefan,
> >  >
> >  >
> >  >
> >  > I am not in favour of the proposed approach.
> >  >
> >  >
> >  >
> >  > I have concern by always overloading the CRL, not simply with one
> >  > additional certificate,
> >  >
> >  > but with two additional certificates, because of CA key rollover.
> >  >
> >  >
> >  >
> >  > The situation will be even worse when a CRL issuer is trusted by
> more
> >  > than one CA
> >  >
> >  > to issue CRLs.
> >  >
> >  >
> >  >
> >  > Talking to you in your capacity of co-chair, I would like to
> recall
> >  > that the full story
> >  >
> >  > of how to check a CRL that is not issued by a CA is still not
> crystal
> >  > clear in 3280bis,
> >  >
> >  > and we should clarify that before. :-)
> >  >
> >  >
> >  >
> >  > Talking to you as PKIX member, I would favor the use of  one
> extension
> >  > with two pointers per CA:
> >  >
> >  >
> >  >
> >  >  - one pointing to the current or old certificate still valid,
and
> >  >
> >  >  - another one pointing the new or current certificate already
> valid.
> >  >
> >  >
> >  >
> >  > This will allow to fetch once the certificate(s) that is/are
> needed.
> >  >
> >  >
> >  >
> >  > The AIA extension is not the right vehicule, since it cannot
> include a
> >  > hash of the data that is pointed.
> >  >
> >  > We should add a hash of the certificate, which would allow to
make
> >  > sure that the right certificate
> >  >
> >  > was obtained without the need to build and verify the
> certification
> >  > path.
> >  >
> >  >
> >  >
> >  > >From the above observations, the problem is much more complex
> than
> >  > originally presented.
> >  >
> >  >
> >  >
> >  > Denis
> >  >
> >  >
> >  >
> >  > ________________________________
> >  >
> >  > Taking the pkix chair hat off and the vendor hat on
> >  >
> >  > I'm asking this group to consider a new standards task to solve a
> real
> >  > implementation issue with indirect CRLs and CRLs issued by a re-
> keyed
> >  > CA. I.e. where the target certificate and it's CRL are signed by  
> > > different keys and the RP does not have access to the CRL Issuer  
> > > certificate.  >
> >  > It is basically the same situation we solved with allowing the
AIA
> >  > extension in CRL's namely the problem to obtain the CRL issuer's  
> > > certificate, alternatively, certificate path.  >
> >  > In our efforts to implement the AIA solution we have encountered
> some
> >  > real issues.
> >  >
> >  > 1)       Each time we are forced to go out and retrieve new
> information
> >  > on the network, we have a source of potential problems such as  > 
> > unavailable network resources, timeouts etc. It all adds to the  > 
> > validation time and harms the user experience.  >
> >  > 2)       The AIA in CRL's provide another opening for DoS attacks
> if
> >  > rouge CRL's point their AIA to a targeted web server. This is
> tough
> >  > not as serious as the DoS problems with AIA in certificates, but
> this
> >  > one we might avoid more easily.
> >  >
> >  >  The proposed solution is to define a new CRL extension that may  
> > > contain the CRL Issuer certificate (not just a URL to its
> location).
> >  > Preferably this would be a PKCS#7 (or CMS) Certs only message
that
> may
> >  > contain a single certificate or a bag of certificates (a chain).  
> > >  >  While it wouldn't be attractive to define such extension for
> >  > certificates due to certificate size considerations, CRL's are
> often
> >  > of such size that including the certs needed to validate it only
> leads
> >  > to an insignificant increase of size, while it may offer
> substantial
> >  > processing advantages.
> >  >
> >  >  I would like to hear the opinion of this group on this.  >
> >  >  I volunteer to write a first draft if there is interest from the
> >  > group.
> >  >
> >  >
> >  >
> >  > Stefan Santesson
> >  >
> >  > Senior Program Manager
> >  >
> >  > Windows Security, Standards
> >  >
> >  >
> >  >
> >  > ________________________________
> >  >
> >  > ________________________________
> >  >
> >

------_=_NextPart_001_01C6DD88.BEE62B60
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: Certs in CRLs - New standards task?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I still don't see the need to include certificates at =
all. I don't buy the network connectivity argument as that would have =
prevented the path to the cert from being established too. Also in =
establishing the certificate path you may have already downloaded the =
cert you need anyway. I think if anything new is added to a CRL, a =
pointer is a much better solution and would not cause problems that =
inclusion of a cert or bag of certs would.</FONT></P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Sharon</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stefan Santesson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, September 20, 2006 11:18 PM</FONT>
<BR><FONT SIZE=3D2>To: Stephen Farrell; Sharon Boeyen</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Certs in CRLs - New standards =
task?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Sharon,</FONT>
</P>

<P><FONT SIZE=3D2>I'm not proposing a best practice document telling =
CAs to include certificates in CRLs. So please don't read this as =
proposing - &quot;All CRLs MUST include certificates&quot;</FONT></P>

<P><FONT SIZE=3D2>But for some PKI implementations, having a =
standardized way to include certificates would avoid many problems, =
especially when indirect CRL's are used or in some scenarios with =
re-keyed CAs where revocation of old certs is performed by the new CA =
key. No RP need to understand or process this extension, No CA have to =
include Certs in CRLs.</FONT></P>

<P><FONT SIZE=3D2>Would you still have a problem if a CA have the =
possibility to add certificates to CRLs in cases where it make sense to =
do so?</FONT></P>

<P><FONT SIZE=3D2>Stephen,</FONT>
</P>

<P><FONT SIZE=3D2>I also think we have reached the point where an I-D =
is needed. I will post one ASAP.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>Senior Program Manager</FONT>
<BR><FONT SIZE=3D2>Windows Security, Standards</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
HREF=3D"mailto:owner-ietf-">mailto:owner-ietf-</A> </FONT>
<BR><FONT SIZE=3D2>&gt; [email-masked]] On Behalf Of Stephen =
Farrell</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: den 19 september 2006 20:39</FONT>
<BR><FONT SIZE=3D2>&gt; To: Sharon Boeyen</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Certs in CRLs - New standards =
task?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm not sure myself. But I would like to see an =
individual I-D before </FONT>
<BR><FONT SIZE=3D2>&gt; the WG adopted a work item.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; S.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sharon Boeyen wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The more I think about this the more I =
dislike the approach of</FONT>
<BR><FONT SIZE=3D2>&gt; including</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certs in the CRL. There are currently =
implementations that are able</FONT>
<BR><FONT SIZE=3D2>&gt; to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; find all the paths they need with the =
current information in the CRL</FONT>
<BR><FONT SIZE=3D2>&gt; (by</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; using the DN to do a directory lookup). I =
recognize this isn't</FONT>
<BR><FONT SIZE=3D2>always</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the simplest way to find information and I =
do support pointer</FONT>
<BR><FONT SIZE=3D2>schemes</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; such as AIA and SIA or another pointer =
approach. However I really</FONT>
<BR><FONT SIZE=3D2>&gt; don't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; want to see the size of CRLs increased in =
the way they would be even</FONT>
<BR><FONT SIZE=3D2>&gt; if</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; a single cert was added, whether that be =
for indirect CRLs, CA key </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; rollovers or any other case.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Stefan, its fine for you to say that =
implementers wouldn't need to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; support the new extension, however as soon =
as a CA starts putting it</FONT>
<BR><FONT SIZE=3D2>&gt; in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; there is an impact on all implementations =
because of the size of the</FONT>
<BR><FONT SIZE=3D2>&gt; CRL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (regardless of whether an implementation =
decides to process or</FONT>
<BR><FONT SIZE=3D2>ignore</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the non-critical extension).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cheers,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sharon</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: [email-masked] [<A =
HREF=3D"mailto:owner-ietf-">mailto:owner-ietf-</A></FONT>
<BR><FONT SIZE=3D2>&gt; [email-masked]]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; On Behalf Of Julien Stern</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Tuesday, September 19, 2006 5:15 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: Certs in CRLs - New standards =
task?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; On Mon, Sep 18, 2006 at 04:41:29PM +0100, =
Stefan Santesson wrote:&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Denis,&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; When this is not a good =
solution to your problem, then don't use</FONT>
<BR><FONT SIZE=3D2>&gt; it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Why MUST is be bad to send the =
certs with every CRL if the</FONT>
<BR><FONT SIZE=3D2>&gt; alternative</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; is to go out on the network and =
fetch the certificates using</FONT>
<BR><FONT SIZE=3D2>extra</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; cycles.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; I may use the same CRL 100+ =
times before it expires for many</FONT>
<BR><FONT SIZE=3D2>&gt; different</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; certificates. We send =
certificates with every OCSP response and</FONT>
<BR><FONT SIZE=3D2>we</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; don't consider that a =
problem.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Stefan,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; if I may jump in. Sometimes, it IS a =
problem to send certificates</FONT>
<BR><FONT SIZE=3D2>&gt; with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; OCSP responses. We have at least one =
example where we will have to</FONT>
<BR><FONT SIZE=3D2>&gt; use</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; OCSP responses without certificates due to =
size contraints.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Admitelly, this case is rare, but there =
are scenarios where OCSP or</FONT>
<BR><FONT SIZE=3D2>&gt; CRL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; size matters :)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; What would you think of having a standard =
way to request (and send)</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificate(s) associated to a CRL without =
bundling them.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; One example (probably not the best but...) =
could be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A HREF=3D"http://www.xxx.com/thecrl.der" =
TARGET=3D"_blank">http://www.xxx.com/thecrl.der</A>&nbsp; --&gt; Gives =
the bare CRL </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"http://www.xxx.com/thecrl.der?addcert" =
TARGET=3D"_blank">http://www.xxx.com/thecrl.der?addcert</A>&nbsp; =
--&gt; Gives the certificate, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; followed by the bare CRL (so that you can =
stream).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Julien</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Senior Program Manager</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Windows Security, =
Standards</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; From: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; On Behalf Of Denis =
Pinkas</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Sent: den 18 september 2006 =
06:10</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Subject: Re: Certs in CRLs - =
New standards task?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; =
________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Stefan,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; My replies have [Denis] in =
front of them.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Hi Denis,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Speaking as an implementer and =
from the experience from how our</FONT>
<BR><FONT SIZE=3D2>&gt; own</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; products work, the issue and =
the solution is much more simple</FONT>
<BR><FONT SIZE=3D2>than</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; solution you propose.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;&nbsp; The&nbsp; validation =
engine does not need to know which certificate</FONT>
<BR><FONT SIZE=3D2>&gt; that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; represents the old or the new =
CA key or what the hash of the&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificate is. The task of the validation =
engine for this issue</FONT>
<BR><FONT SIZE=3D2>&gt; is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; simply to validate the =
signature of the CRL using a valid path to</FONT>
<BR><FONT SIZE=3D2>&gt; a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; trusted root (being the same =
used to validate the target</FONT>
<BR><FONT SIZE=3D2>&gt; certificate).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; [Denis]&nbsp; I disagree. =
Before the &quot;validation engine&quot; there is the</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;path</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; construction engine&quot;. =
Depending upon whether key rollover has</FONT>
<BR><FONT SIZE=3D2>been</FONT>
<BR><FONT SIZE=3D2>&gt; or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; has not been performed by the =
relying party, one or two</FONT>
<BR><FONT SIZE=3D2>&gt; certificates</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; may be needed. If the CRL =
issuer is servings multiple CAs, then a&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; couple of certificates are needed for =
each CA. If we define a new&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; extension, it MUST also be usable for =
a single CRL issued for&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; different CAs.&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; First of all the validation =
engine will try to build a path using</FONT>
<BR><FONT SIZE=3D2>&gt; all</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; certs from the validated path =
and all cashed and locally stored&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; certificates and root keys. If this =
fails it could use the certs&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; provided in the CRL using this new =
extension (just a bag of&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificates with no specific =
information).&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; [Denis] Ahhhhh! you just =
crossed the line: a bag of certificates</FONT>
<BR><FONT SIZE=3D2>!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;&nbsp; In the end, if the =
provided bag of certificates (typically only</FONT>
<BR><FONT SIZE=3D2>1</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; certificate if present) does =
not help the RP, we did not do any&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; particular damage to the RP (just =
slightly increased the CRL), we</FONT>
<BR><FONT SIZE=3D2>&gt; just</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; couldn't help him and he will =
now have to try directory search</FONT>
<BR><FONT SIZE=3D2>etc</FONT>
<BR><FONT SIZE=3D2>&gt; as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; before. But the fact is that by =
including certificate/s in the</FONT>
<BR><FONT SIZE=3D2>CRL</FONT>
<BR><FONT SIZE=3D2>&gt; we</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; may in many PKI configurations =
considerably help the RP.&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; [Denis] You will need to =
transfer that bag of certificates every</FONT>
<BR><FONT SIZE=3D2>&gt; time.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; This is not good. Instead of =
trying to convince that the</FONT>
<BR><FONT SIZE=3D2>initially</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; proposed solution is the best, =
please take some time to consider</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; benefits and drawbacks of the =
other solution I proposed.&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; I fully agree that this =
information can not be stored in an AIA.</FONT>
<BR><FONT SIZE=3D2>A</FONT>
<BR><FONT SIZE=3D2>&gt; new</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; CRL extension is needed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Finally I don't agree to the =
term &quot;overloading&quot; here. We usually</FONT>
<BR><FONT SIZE=3D2>&gt; use</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; that term to describe when we =
stretch the semantics of existing</FONT>
<BR><FONT SIZE=3D2>&gt; fields</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; and name forms. This is just an =
new optional non-critical</FONT>
<BR><FONT SIZE=3D2>&gt; extension</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; with useful data, relevant to =
the processing of the CRL.&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Denis</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Senior Program Manager</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Windows Security, =
Standards</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; From: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; On Behalf Of Denis =
Pinkas</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Sent: den 18 september 2006 =
00:51</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Subject: Re: Certs in CRLs - =
New standards task?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Stefan,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; I am not in favour of the =
proposed approach.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; I have concern by always =
overloading the CRL, not simply with one</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; additional certificate,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; but with two additional =
certificates, because of CA key rollover.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; The situation will be even =
worse when a CRL issuer is trusted by</FONT>
<BR><FONT SIZE=3D2>&gt; more</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; than one CA</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; to issue CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Talking to you in your capacity =
of co-chair, I would like to</FONT>
<BR><FONT SIZE=3D2>&gt; recall</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; that the full story</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; of how to check a CRL that is =
not issued by a CA is still not</FONT>
<BR><FONT SIZE=3D2>&gt; crystal</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; clear in 3280bis,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; and we should clarify that =
before. :-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Talking to you as PKIX member, =
I would favor the use of&nbsp; one</FONT>
<BR><FONT SIZE=3D2>&gt; extension</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; with two pointers per =
CA:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;&nbsp; - one pointing to the =
current or old certificate still valid,</FONT>
<BR><FONT SIZE=3D2>and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;&nbsp; - another one pointing =
the new or current certificate already</FONT>
<BR><FONT SIZE=3D2>&gt; valid.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; This will allow to fetch once =
the certificate(s) that is/are</FONT>
<BR><FONT SIZE=3D2>&gt; needed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; The AIA extension is not the =
right vehicule, since it cannot</FONT>
<BR><FONT SIZE=3D2>&gt; include a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; hash of the data that is =
pointed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; We should add a hash of the =
certificate, which would allow to</FONT>
<BR><FONT SIZE=3D2>make</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; sure that the right =
certificate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; was obtained without the need =
to build and verify the</FONT>
<BR><FONT SIZE=3D2>&gt; certification</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; path.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; &gt;From the above =
observations, the problem is much more complex</FONT>
<BR><FONT SIZE=3D2>&gt; than</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; originally presented.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Denis</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; =
________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Taking the pkix chair hat off =
and the vendor hat on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; I'm asking this group to =
consider a new standards task to solve a</FONT>
<BR><FONT SIZE=3D2>&gt; real</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; implementation issue with =
indirect CRLs and CRLs issued by a re-</FONT>
<BR><FONT SIZE=3D2>&gt; keyed</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; CA. I.e. where the target =
certificate and it's CRL are signed by&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; different keys and the RP does not =
have access to the CRL Issuer&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; certificate.&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; It is basically the same =
situation we solved with allowing the</FONT>
<BR><FONT SIZE=3D2>AIA</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; extension in CRL's namely the =
problem to obtain the CRL issuer's&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; certificate, alternatively, =
certificate path.&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; In our efforts to implement the =
AIA solution we have encountered</FONT>
<BR><FONT SIZE=3D2>&gt; some</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; real issues.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; =
1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Each time we are forced to go =
out and retrieve new</FONT>
<BR><FONT SIZE=3D2>&gt; information</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; on the network, we have a =
source of potential problems such as&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; unavailable network resources, timeouts =
etc. It all adds to the&nbsp; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; validation time and harms the user =
experience.&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; =
2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The AIA in CRL's provide another =
opening for DoS attacks</FONT>
<BR><FONT SIZE=3D2>&gt; if</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; rouge CRL's point their AIA to =
a targeted web server. This is</FONT>
<BR><FONT SIZE=3D2>&gt; tough</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; not as serious as the DoS =
problems with AIA in certificates, but</FONT>
<BR><FONT SIZE=3D2>&gt; this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; one we might avoid more =
easily.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;&nbsp; The proposed solution is =
to define a new CRL extension that may&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; contain the CRL Issuer certificate =
(not just a URL to its</FONT>
<BR><FONT SIZE=3D2>&gt; location).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Preferably this would be a =
PKCS#7 (or CMS) Certs only message</FONT>
<BR><FONT SIZE=3D2>that</FONT>
<BR><FONT SIZE=3D2>&gt; may</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; contain a single certificate or =
a bag of certificates (a chain).&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; &gt;&nbsp; While it wouldn't be =
attractive to define such extension for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; certificates due to certificate =
size considerations, CRL's are</FONT>
<BR><FONT SIZE=3D2>&gt; often</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; of such size that including the =
certs needed to validate it only</FONT>
<BR><FONT SIZE=3D2>&gt; leads</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; to an insignificant increase of =
size, while it may offer</FONT>
<BR><FONT SIZE=3D2>&gt; substantial</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; processing advantages.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;&nbsp; I would like to hear the =
opinion of this group on this.&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;&nbsp; I volunteer to write a =
first draft if there is interest from the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; group.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Senior Program Manager</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; Windows Security, =
Standards</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; =
________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt; =
________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6DD88.BEE62B60--

Date: Thu, 21 Sep 2006 07:10:41 -0700
From: Wan-Teh Chang <[email-masked]>
To: [email-masked]
Subject: Re: Protecting Against Weak Hash Algorithms
Sender: [email-masked]

Santosh Chokhani wrote:
> Paul,
> 
> Let us say that you as a signer is using SHA-1 and RSA.  I thought I can
> keep your signature, but create a payload using a weak hash scheme (say
> MD-4 or chokhani Hash) that is still lying in the relying party system.
> Since the identification of the hash algorithm to be used in
> verification lies with the payload, pointing to the weak hash OID will
> be part of creation of the material.

If I understand you correctly, your proposal is useful
for DSA and ECDSA signatures because the (r, s) components
don't tell you what hash algorithm should be used.  On
the other hand, your proposal isn't necessary for PKCS #1
v1.5 RSA signatures because the hash algorithm is also
encrypted along with the hash.

Seems like the attack you want to protect against also
requires that the weaker hash algorithm's output is the
same length as the hash algorithm used in the original
signature.  Right now MD2, MD4, and MD5 are probably
the only such hash algorithms(all 128 bits long).  But
none of these can be used with DSA and ECDSA.

Wan-Teh

Content-class: urn:content-classes:message
Subject: RE: New time stamping standard by ISO
Date: Thu, 21 Sep 2006 14:40:40 +0100
From: "Stefan Santesson" <[email-masked]>
To: =?iso-8859-1?Q?=22Jos=E9_A=2E_Ma=F1as=22?= <[email-masked]>, "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi José

Since you participate in this effort in ISO, could you check if they for the interest of more effective liaison could make the draft available to people on this list.
After personally reviewing this draft I discovered some compliance problems with rfc 3161 and I may no have caught it all.

Critical parts or references to the full encoding of timeStampToken, especially the CMS parts, seems also be missing.

As of the CMS "embeddable" tokens, I find no explanation or use case motivating it or any discussion on interoperability issues with CMS parsing applications.
The purpose seems to be to allow addition of a timestamp to a standard CMS object, however this is not the only result. This results also in the TSA blindly signing the CMS object, not just the time stamp. I assume the ISO standard think this is OK since the TSA certificate contains the id-kp-timeStamping EKU only. But basically it is a breach of semantics that may lead to unexpected behaviors in legacy applications trying to understand the signatures of the CMS object.

Do you have the full story?

Stefan Santesson
Senior Program Manager
Windows Security, Standards
> From: "José A. Mañas" [mailto:[email-masked]]
> Sent: den 21 september 2006 14:21
> To: Peter Gutmann
> Cc: [email-masked]; [email-masked]; Stefan Santesson;
> [email-masked]
> Subject: Re: New time stamping standard by ISO
> 
> I am working in the iso group updating the time-stamping standard.
> It is not so much a brand-new standard.
> 
> I think everyone in the group understands that backwards
> compatibility with 3161 is a must;
> then we try to improve, and basically to standardize
> improvements so there is some agreed way of doing things right.
> 
> The aims are
>    - to keep 3161 tokens
>    - to allow for cms "embeddable" tokens
>    - to align xml and asn1 tokens
> 
> The new standard is still in the working draft stage,
> so there is room for listening as wide an audience as possible.
> 
> Best
> jam
> 
> Peter Gutmann wrote:
> > Russ Housley <[email-masked]> writes:
> >
> >> Yet, everyone implement it this way, right?
> >
> > Well of course they implement it that way, because the spec says they
> have to.
> > If the spec said they had to run naked down the middle of the road in
> order to
> > claim RFC 3161 compliance they'd do that too, even though it's not a
> sensible
> > thing to do.
> >
> >> If there is a need for change, it should begin with an update to RFC
> 3161.
> >
> > This problem was pointed out years ago, when the RFC was still in
> draft stage.
> > The authors ignored it, along with other comments people submitted
> about other
> > issues.  So I think ISO is the only forum for change.
> >
> > Peter.
> >

Date: Thu, 21 Sep 2006 14:21:07 +0200
From: =?ISO-8859-1?Q?=22Jos=E9_A=2E_Ma=F1as=22?= <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

I am working in the iso group updating the time-stamping standard.
It is not so much a brand-new standard.

I think everyone in the group understands that backwards
compatibility with 3161 is a must;
then we try to improve, and basically to standardize
improvements so there is some agreed way of doing things right.

The aims are
   - to keep 3161 tokens
   - to allow for cms "embeddable" tokens
   - to align xml and asn1 tokens

The new standard is still in the working draft stage,
so there is room for listening as wide an audience as possible.

Best
jam

Peter Gutmann wrote:
> Russ Housley <[email-masked]> writes:
> 
>> Yet, everyone implement it this way, right?
> 
> Well of course they implement it that way, because the spec says they have to.
> If the spec said they had to run naked down the middle of the road in order to
> claim RFC 3161 compliance they'd do that too, even though it's not a sensible
> thing to do.
> 
>> If there is a need for change, it should begin with an update to RFC 3161.
> 
> This problem was pointed out years ago, when the RFC was still in draft stage.
> The authors ignored it, along with other comments people submitted about other
> issues.  So I think ISO is the only forum for change.
> 
> Peter.
> 

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 21 Sep 2006 03:58:46 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Ryan,

Items 2 and 3 are not peculiar to CRL signer.  These are generic issues
and one can use these to argue that all the certificates and revocation
information required should be bundled as one.

Item 1, I think that given the CRL issuer certificate appears in the
same directory entry as the CRL and the CRL issuer can ensure the
availability of CRL on HTTP and certificate on HTTP AIA, I do not see it
as a practical issue.

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 4:28 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

I understand the point, and in-fact it is why I originally recommended
the same solution you call out bellow with AIA in certs pointing to a
p7c; however connectivity is not as much an constant as we often like to
think.

With that in-mind there are other related scenarios to keep in mind when
evaluating a solution here:
1) General connectivity problems, you may have access to the url in the
CDP to acquire the CRL but not have access (server down, url is internal
to network but rp is out of network, etc) to the CRLs issuer certificate
referenced in its AIA.
2) Unreliable network connectivity, with the increase in mobile hosts
the chances of the connectivity going down after getting the CRL but
before the intermediate has been retrieved.
3) API performance - When building a generalized certificate handling
API its often necessary to have a "contract" with your callers, e.g. I
will return in n seconds reliably in these cases its desirable to reduce
the number of sockets being created.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, September 20, 2006 11:19 AM
To: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Thanks to Ryan for providing the following definitions of Pre-IP and
Post-IP off list.

"Pre IP = Situations like establishing network connectivity or verifying
signatures in boot before network connectivity.
Post IP = Situations where host or user has full IP connectivity."

Using the above definitions, it does not seem that adding the extension
is a particularly good idea to solve the problem for the connectivity
challenged scenarios.  The following is my thinking:

The question is how did we get the CRL (indirect or for that matter
direct one) in the first place.  The CRL is stored as an attribute of
the CRL issuer and hence when the CRL is obtained, certificate can also
be obtained, obviating the need.

Another alternative is for the CA that issued a certificate and
delegated indirect CRL issuer, can put in its AIA p7c bag the
certification path for the indirect CRL issuer.

Now, whoever is doing pre-IP fetch of certificates and CRL and is
loading the cache can have all these certificates.

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 5:13 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Hi Santosh - I think there are numerous benefits, for example:
1. Pre-IP scenarios that have the CRL but not the intermediates; more
likely in indirect cases.
2. Post-IP scenarios where all the intermediates and trust anchors' are
there except the indirect certificate so chain discovery must go online
to complete discovery; more likely in indirect cases.
3. Post-IP scenarios where no intermediates are present and the
implementing chain validation API must return in a specific time and the
allotted time is already used through other discovery and validation
phases, additional wire retrievals introduce more latency and should be
avoided if possible.

These are just a few off the top of my head, I am sure Stefan has
others.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Tuesday, September 19, 2006 12:28 PM
To: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Ryan,

Can you explain why "without having to go on the wire" makes sense?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan Hurst
Sent: Tuesday, September 19, 2006 2:21 PM
To: Russ Housley; Jean-Marc Desperrier; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

I was not personally suggesting the CRL carry a P7C but instead that a
certificate provide a pointer to a p7c that contains both the CRL and
the certificates that are necessary to validate it this way a
implementation that supported this model could choose this form of CRL
vs the traditional form.

However after speaking with Stefan I think we both better understand
each other's scenarios and I now agree with Stefan, supporting a mode
where a CRL contains sufficient information to kick of validation and
then discovery for indirect CRL cases without having to go on the wire
makes sense.

By scoping the inclusion of this proposed extension to indirect crls
associated with CAs you mitigate the performance and file size problems
that I was concerned with while still enabling solving the problem
Stefan calls out.

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Monday, September 18, 2006 8:46 AM
To: Jean-Marc Desperrier; [email-masked]
Subject: Re: Certs in CRLs - New standards task?

I support the idea of carrying a bag 'o certs.  However, I am not use 
what value is added by carrying a p7c.  It seems to be a heavy weight 
way to say SEQUENCE OF Certificate.

What am I missing?

Russ

At 09:21 AM 9/18/2006, Jean-Marc Desperrier wrote:

>Ryan Hurst wrote:
>>Have you considered the idea of introducing a new access method to the
>>AIA that would point to a P7c that possibly contained the CRL, its
>>issuers and maybe the certificates issuers?
>>
>I vote for p7c. Most CAs already include an option to distribute CRL
this way.
>
>After reading  RFC 2585, I think it misses something  by not saying 
>a word about the popular option of distributing crl and certificates 
>inside pkcs#7/CMS bags.
>
>When RFC 3280bis says that URIs inside a DistributionPointName must 
>point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it just
>making explicit a rule that was already required for proper
interoperability ?

Content-class: urn:content-classes:message
Subject: RE: Protecting Against Weak Hash Algorithms
Date: Thu, 21 Sep 2006 03:52:14 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DD6B.F56CF5A4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Russ,

=20

I will be happy to.  I would like to prepare and run the presentation by
you.

________________________________

From: Russ Housley [mailto:[email-masked]]=20
Sent: Wednesday, September 20, 2006 9:24 PM
To: Santosh Chokhani; [email-masked]
Subject: Re: Protecting Against Weak Hash Algorithms

=20

Can you make a presentation in San Diego?

At 03:09 PM 9/20/2006, Santosh Chokhani wrote:

As you know the hashing algorithms are in state of flux (We know MD5 is
bad, SHA-1 is beginning to smell and so on).
=20
Also, we know that many relying parties implement many of these
algorithms.
=20
Also, Russ has been talking about making PKIX RFCs algorithm independent
so that algorithms can be easily swapped in and out.
=20
I think we should have a debate on security issues surrounding weak
hashes, specifically relying parties snookered into verifying a
signature using a weak hash that can easily create collision with
payload that was actually signed using a strong hash.
=20
While it will be a great deal of pain to the client software, but
subject public key information through OID or parameters could specify
one or more hash algorithms to be used with a signature key.  This will
protect against the spoofing of relying party into using a weak hash
during signature verification.  I thought while we are debating the
syntax for ECC based algorithms, this may be a good time to suffer that
pain.
=20

Santosh Chokhani=20
Orion Security Solutions, Inc.=20
(703) 401-7088=20
[email-masked]=20

=20

------_=_NextPart_001_01C6DD6B.F56CF5A4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:11.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I will be happy to.&nbsp; I would =
like to
prepare and run the presentation by you.<o:p></o:p></span></font></p>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Russ =
Housley
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, =
September 20,
2006 9:24 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Santosh
 Chokhani</st1:PersonName>; [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Protecting =
Against
Weak Hash Algorithms</span></font><o:p></o:p></p>

</div>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Can you make a presentation in <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">San
  Diego</st1:place></st1:City>?<br>
<br>
At 03:09 PM 9/20/2006, <st1:PersonName w:st=3D"on">Santosh =
Chokhani</st1:PersonName>
wrote:<br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>As you know the hashing algorithms are in state of flux (We know =
MD5 is
bad, SHA-1 is beginning to smell and so on).<br>
&nbsp;<br>
Also, we know that many relying parties implement many of these =
algorithms.<br>
&nbsp;<br>
Also, Russ has been talking about making PKIX RFCs algorithm independent =
so
that algorithms can be easily swapped in and out.<br>
&nbsp;<br>
I think we should have a debate on security issues surrounding weak =
hashes,
specifically relying parties snookered into verifying a signature using =
a weak
hash that can easily create collision with payload that was actually =
signed
using a strong hash.<br>
&nbsp;<br>
While it will be a great deal of pain to the client software, but =
subject
public key information through OID or parameters could specify one or =
more hash
algorithms to be used with a signature key.&nbsp; This will protect =
against the
spoofing of relying party into using a weak hash during signature
verification.&nbsp; I thought while we are debating the syntax for ECC =
based
algorithms, this may be a good time to suffer that pain.<br>
&nbsp;<br>
</span></font><br>
<st1:PersonName w:st=3D"on"><font size=3D2><span =
style=3D'font-size:10.0pt'>Santosh
 Chokhani</span></font></st1:PersonName> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Orion Security =
Solutions, Inc.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>(703)</span></font> =
<font size=3D2><span
style=3D'font-size:10.0pt'>401-7088</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>[email-masked]</span></font>
<br>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6DD6B.F56CF5A4--

Content-class: urn:content-classes:message
Subject: RE: Protecting Against Weak Hash Algorithms
Date: Thu, 21 Sep 2006 03:51:47 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Paul,

Let us say that you as a signer is using SHA-1 and RSA.  I thought I can
keep your signature, but create a payload using a weak hash scheme (say
MD-4 or chokhani Hash) that is still lying in the relying party system.
Since the identification of the hash algorithm to be used in
verification lies with the payload, pointing to the weak hash OID will
be part of creation of the material.

Thus, SHA-1 need not be weak.  Only the relying party system needs to
invoke a weak hash algorithm.  

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 11:36 PM
To: Santosh Chokhani; [email-masked]
Subject: Re: Protecting Against Weak Hash Algorithms

At 12:09 PM -0700 9/20/06, Santosh Chokhani wrote:
>I think we should have a debate on security issues surrounding weak 
>hashes, specifically relying parties snookered into verifying a 
>signature using a weak hash that can easily create collision with 
>payload that was actually signed using a strong hash.

I am confused by the terminology used here. How can a message created 
by one hash easily create a collision with a message created with 
another hash? That would indicate an equal weakness in both hashes, 
wouldn't it?

Could you lay out a specific example?

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: New time stamping standard by ISO
Date: Thu, 21 Sep 2006 11:34:07 +0100
From: "Stefan Santesson" <[email-masked]>
To: "pgut001" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

ISO can't change RFC 3161. At most they can create diversion.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: pgut001 [mailto:[email-masked]]
> Sent: den 21 september 2006 10:47
> To: [email-masked]; [email-masked];
> [email-masked]; Stefan Santesson
> Cc: [email-masked]
> Subject: Re: New time stamping standard by ISO
> 
> Russ Housley <[email-masked]> writes:
> 
> >Yet, everyone implement it this way, right?
> 
> Well of course they implement it that way, because the spec says they
> have to.
> If the spec said they had to run naked down the middle of the road in
> order to
> claim RFC 3161 compliance they'd do that too, even though it's not a
> sensible
> thing to do.
> 
> >If there is a need for change, it should begin with an update to RFC
> 3161.
> 
> This problem was pointed out years ago, when the RFC was still in
draft
> stage.
> The authors ignored it, along with other comments people submitted
> about other
> issues.  So I think ISO is the only forum for change.
> 
> Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: New time stamping standard by ISO
Cc: [email-masked]
Date: Thu, 21 Sep 2006 20:46:32 +1200
Sender: [email-masked]

Russ Housley <[email-masked]> writes:

>Yet, everyone implement it this way, right?

Well of course they implement it that way, because the spec says they have to.
If the spec said they had to run naked down the middle of the road in order to
claim RFC 3161 compliance they'd do that too, even though it's not a sensible
thing to do.

>If there is a need for change, it should begin with an update to RFC 3161.

This problem was pointed out years ago, when the RFC was still in draft stage.
The authors ignored it, along with other comments people submitted about other
issues.  So I think ISO is the only forum for change.

Peter.

Date: Wed, 20 Sep 2006 20:35:35 -0700
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Protecting Against Weak Hash Algorithms
Sender: [email-masked]

At 12:09 PM -0700 9/20/06, Santosh Chokhani wrote:
>I think we should have a debate on security issues surrounding weak 
>hashes, specifically relying parties snookered into verifying a 
>signature using a weak hash that can easily create collision with 
>payload that was actually signed using a strong hash.

I am confused by the terminology used here. How can a message created 
by one hash easily create a collision with a message created with 
another hash? That would indicate an equal weakness in both hashes, 
wouldn't it?

Could you lay out a specific example?

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 21 Sep 2006 04:17:34 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Sharon Boeyen" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Sharon,

I'm not proposing a best practice document telling CAs to include
certificates in CRLs.
So please don't read this as proposing - "All CRLs MUST include
certificates"

But for some PKI implementations, having a standardized way to include
certificates would avoid many problems, especially when indirect CRL's
are used or in some scenarios with re-keyed CAs where revocation of old
certs is performed by the new CA key.
No RP need to understand or process this extension, No CA have to
include Certs in CRLs.

Would you still have a problem if a CA have the possibility to add
certificates to CRLs in cases where it make sense to do so?

Stephen,

I also think we have reached the point where an I-D is needed. I will
post one ASAP.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> [email-masked]] On Behalf Of Stephen Farrell
> Sent: den 19 september 2006 20:39
> To: Sharon Boeyen
> Cc: [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
> 
> 
> I'm not sure myself. But I would like to see an individual I-D
> before the WG adopted a work item.
> 
> S.
> 
> Sharon Boeyen wrote:
> > The more I think about this the more I dislike the approach of
> including
> > certs in the CRL. There are currently implementations that are able
> to
> > find all the paths they need with the current information in the CRL
> (by
> > using the DN to do a directory lookup). I recognize this isn't
always
> > the simplest way to find information and I do support pointer
schemes
> > such as AIA and SIA or another pointer approach. However I really
> don't
> > want to see the size of CRLs increased in the way they would be even
> if
> > a single cert was added, whether that be for indirect CRLs, CA key
> > rollovers or any other case.
> >
> > Stefan, its fine for you to say that implementers wouldn't need to
> > support the new extension, however as soon as a CA starts putting it
> in
> > there is an impact on all implementations because of the size of the
> CRL
> > (regardless of whether an implementation decides to process or
ignore
> > the non-critical extension).
> >
> > Cheers,
> > Sharon
> >
> [email-masked]]
> > On Behalf Of Julien Stern
> > Sent: Tuesday, September 19, 2006 5:15 AM
> > To: [email-masked]
> > Subject: Re: Certs in CRLs - New standards task?
> >
> >
> >
> > On Mon, Sep 18, 2006 at 04:41:29PM +0100, Stefan Santesson wrote:
> >  > Denis,
> >  >
> >  > When this is not a good solution to your problem, then don't use
> it.
> >  >
> >  > Why MUST is be bad to send the certs with every CRL if the
> alternative
> >  > is to go out on the network and fetch the certificates using
extra
> >  > cycles.
> >  >
> >  > I may use the same CRL 100+ times before it expires for many
> different
> >  > certificates. We send certificates with every OCSP response and
we
> >  > don't consider that a problem.
> >
> > Stefan,
> >
> > if I may jump in. Sometimes, it IS a problem to send certificates
> with
> > OCSP responses. We have at least one example where we will have to
> use
> > OCSP responses without certificates due to size contraints.
> >
> > Admitelly, this case is rare, but there are scenarios where OCSP or
> CRL
> > size matters :)
> >
> > What would you think of having a standard way to request (and send)
> the
> > certificate(s) associated to a CRL without bundling them.
> >
> > One example (probably not the best but...) could be
> >
> > http://www.xxx.com/thecrl.der  --> Gives the bare CRL
> > http://www.xxx.com/thecrl.der?addcert  --> Gives the certificate,
> > followed by the bare CRL (so that you can stream).
> >
> > Regards,
> >
> > --
> > Julien
> >
> >  > Stefan Santesson
> >  >
> >  > Senior Program Manager
> >  >
> >  > Windows Security, Standards
> >  >
> >  > From: [email-masked]
> >  > [mailto:[email-masked]]
> >  > On Behalf Of Denis Pinkas
> >  > Sent: den 18 september 2006 06:10
> >  > To: [email-masked]
> >  > Subject: Re: Certs in CRLs - New standards task?
> >  >
> >  >
> >  >
> >  > ________________________________
> >  >
> >  > Stefan,
> >  >
> >  > My replies have [Denis] in front of them.
> >  >
> >  > Hi Denis,
> >  >
> >  > Speaking as an implementer and from the experience from how our
> own
> >  > products work, the issue and the solution is much more simple
than
> the
> >  > solution you propose.
> >  >
> >  >  The  validation engine does not need to know which certificate
> that
> >  > represents the old or the new CA key or what the hash of the
> >  > certificate is. The task of the validation engine for this issue
> is
> >  > simply to validate the signature of the CRL using a valid path to
> a
> >  > trusted root (being the same used to validate the target
> certificate).
> >  >
> >  > [Denis]  I disagree. Before the "validation engine" there is the
> "path
> >  > construction engine". Depending upon whether key rollover has
been
> or
> >  > has not been performed by the relying party, one or two
> certificates
> >  > may be needed. If the CRL issuer is servings multiple CAs, then a
> >  > couple of certificates are needed for each CA. If we define a new
> >  > extension, it MUST also be usable for a single CRL issued for
> >  > different CAs.
> >  >
> >  > First of all the validation engine will try to build a path using
> all
> >  > certs from the validated path and all cashed and locally stored
> >  > certificates and root keys. If this fails it could use the certs
> >  > provided in the CRL using this new extension (just a bag of
> >  > certificates with no specific information).
> >  >
> >  > [Denis] Ahhhhh! you just crossed the line: a bag of certificates
!
> >  >
> >  >  In the end, if the provided bag of certificates (typically only
1
> >  > certificate if present) does not help the RP, we did not do any
> >  > particular damage to the RP (just slightly increased the CRL), we
> just
> >  > couldn't help him and he will now have to try directory search
etc
> as
> >  > before. But the fact is that by including certificate/s in the
CRL
> we
> >  > may in many PKI configurations considerably help the RP.
> >  >
> >  > [Denis] You will need to transfer that bag of certificates every
> time.
> >  > This is not good. Instead of trying to convince that the
initially
> >  > proposed solution is the best, please take some time to consider
> the
> >  > benefits and drawbacks of the other solution I proposed.
> >  >
> >  > I fully agree that this information can not be stored in an AIA.
A
> new
> >  > CRL extension is needed.
> >  >
> >  > Finally I don't agree to the term "overloading" here. We usually
> use
> >  > that term to describe when we stretch the semantics of existing
> fields
> >  > and name forms. This is just an new optional non-critical
> extension
> >  > with useful data, relevant to the processing of the CRL.
> >  >
> >  > Denis
> >  >
> >  >
> >  >
> >  >
> >  >
> >  > Stefan Santesson
> >  >
> >  > Senior Program Manager
> >  >
> >  > Windows Security, Standards
> >  >
> >  > From: [email-masked]
> >  > [mailto:[email-masked]]
> >  > On Behalf Of Denis Pinkas
> >  > Sent: den 18 september 2006 00:51
> >  > To: [email-masked]
> >  > Subject: Re: Certs in CRLs - New standards task?
> >  >
> >  >
> >  >
> >  > Stefan,
> >  >
> >  >
> >  >
> >  > I am not in favour of the proposed approach.
> >  >
> >  >
> >  >
> >  > I have concern by always overloading the CRL, not simply with one
> >  > additional certificate,
> >  >
> >  > but with two additional certificates, because of CA key rollover.
> >  >
> >  >
> >  >
> >  > The situation will be even worse when a CRL issuer is trusted by
> more
> >  > than one CA
> >  >
> >  > to issue CRLs.
> >  >
> >  >
> >  >
> >  > Talking to you in your capacity of co-chair, I would like to
> recall
> >  > that the full story
> >  >
> >  > of how to check a CRL that is not issued by a CA is still not
> crystal
> >  > clear in 3280bis,
> >  >
> >  > and we should clarify that before. :-)
> >  >
> >  >
> >  >
> >  > Talking to you as PKIX member, I would favor the use of  one
> extension
> >  > with two pointers per CA:
> >  >
> >  >
> >  >
> >  >  - one pointing to the current or old certificate still valid,
and
> >  >
> >  >  - another one pointing the new or current certificate already
> valid.
> >  >
> >  >
> >  >
> >  > This will allow to fetch once the certificate(s) that is/are
> needed.
> >  >
> >  >
> >  >
> >  > The AIA extension is not the right vehicule, since it cannot
> include a
> >  > hash of the data that is pointed.
> >  >
> >  > We should add a hash of the certificate, which would allow to
make
> >  > sure that the right certificate
> >  >
> >  > was obtained without the need to build and verify the
> certification
> >  > path.
> >  >
> >  >
> >  >
> >  > >From the above observations, the problem is much more complex
> than
> >  > originally presented.
> >  >
> >  >
> >  >
> >  > Denis
> >  >
> >  >
> >  >
> >  > ________________________________
> >  >
> >  > Taking the pkix chair hat off and the vendor hat on
> >  >
> >  > I'm asking this group to consider a new standards task to solve a
> real
> >  > implementation issue with indirect CRLs and CRLs issued by a re-
> keyed
> >  > CA. I.e. where the target certificate and it's CRL are signed by
> >  > different keys and the RP does not have access to the CRL Issuer
> >  > certificate.
> >  >
> >  > It is basically the same situation we solved with allowing the
AIA
> >  > extension in CRL's namely the problem to obtain the CRL issuer's
> >  > certificate, alternatively, certificate path.
> >  >
> >  > In our efforts to implement the AIA solution we have encountered
> some
> >  > real issues.
> >  >
> >  > 1)       Each time we are forced to go out and retrieve new
> information
> >  > on the network, we have a source of potential problems such as
> >  > unavailable network resources, timeouts etc. It all adds to the
> >  > validation time and harms the user experience.
> >  >
> >  > 2)       The AIA in CRL's provide another opening for DoS attacks
> if
> >  > rouge CRL's point their AIA to a targeted web server. This is
> tough
> >  > not as serious as the DoS problems with AIA in certificates, but
> this
> >  > one we might avoid more easily.
> >  >
> >  >  The proposed solution is to define a new CRL extension that may
> >  > contain the CRL Issuer certificate (not just a URL to its
> location).
> >  > Preferably this would be a PKCS#7 (or CMS) Certs only message
that
> may
> >  > contain a single certificate or a bag of certificates (a chain).
> >  >
> >  >  While it wouldn't be attractive to define such extension for
> >  > certificates due to certificate size considerations, CRL's are
> often
> >  > of such size that including the certs needed to validate it only
> leads
> >  > to an insignificant increase of size, while it may offer
> substantial
> >  > processing advantages.
> >  >
> >  >  I would like to hear the opinion of this group on this.
> >  >
> >  >  I volunteer to write a first draft if there is interest from the
> >  > group.
> >  >
> >  >
> >  >
> >  > Stefan Santesson
> >  >
> >  > Senior Program Manager
> >  >
> >  > Windows Security, Standards
> >  >
> >  >
> >  >
> >  > ________________________________
> >  >
> >  > ________________________________
> >  >
> >

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 21 Sep 2006 13:04:10 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

How about allowing a CRL to be delivered as a multipart/related value, but only when this MIME type is explicitly preferred over application/pkix-crl by an HTTP Accept header.

The requested CRL SHALL be the root body part, SHALL be the first body part, and shall use the application/pkix-crl MIME type.  Other body parts MAY hold certificates: one per body part using the application/pkix-cert MIME type.  The receiver SHALL silently ignore any body part with an unexpected MIME type.  For instance, a body part holding, say, an OCSP response will not cause a receiver expecting only a CRL and certificates to fail.

--->
GET /ca/main.crl HTTP/1.1
Host: id.example.org
Accept: multipart/related, application/pkix-crl; q=0.5

<---
HTTP/1.1 200 Ok
Content-type: multipart/related; boundary=123 ; type=" application/pkix-crl"

--123
Content-Type: application/pkix-crl

MIIBYDCBygIBATANBgkqhkiG9w0BAQUFADBDMRMwEQYKCZImiZPyLGQBGRYDY29t
MRcwFQYKCZImiZPyLGQBGRYHZXhhbXBsZTETMBEGA1UEAxMKRXhhbXBsZSBDQRcN
MDUwMjA1MTIwMDAwWhcNMDUwMjA2MTIwMDAwWjAiMCACARIXDTA0MTExOTE1NTcw
M1owDDAKBgNVHRUEAwoBAaAvMC0wHwYDVR0jBBgwFoAUCGivhTPIOUp6+IKTjnBq
SiCELDIwCgYDVR0UBAMCAQwwDQYJKoZIhvcNAQEFBQADgYEAItwYffcIzsx10NBq
m60Q9HYjtIFutW2+DvsVFGzIF20f7pAXom9g5L2qjFXejoRvkvifEBInr0rUL4Xi
NkR9qqNMJTgV/wD9Pn7uPSYS69jnK2LiK8NGgO94gtEVxtCccmrLznrtZ5mLbnCB
fUNCdMGmr8FVF6IzTNYGmCuk/C4=
--123
Content-Type: application/pkix-cert

--123--

References:
* RFC 2387 The MIME Multipart/Related Content-type (Aug 1998)
* RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1 (Jun 1999)
* RFC 2585 PKIX Operational Protocols: FTP and HTTP (May 1999)

Content-class: urn:content-classes:message
Subject: RE: New time stamping standard by ISO
Date: Thu, 21 Sep 2006 03:03:39 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Russ Housley" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I must admit that I have made a similar reflection about if the
complexity is beneficial, but this is the way it is and changing it at
this stage is most certainly more harmful than leaving it as is.

The motivation for ISO to expand on the choices is not well founded. And
there has been objections to it from the US side.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: Russ Housley [mailto:[email-masked]]
> Sent: den 20 september 2006 18:33
> To: [email-masked]; [email-masked]; Stefan
> Santesson
> Cc: [email-masked]
> Subject: Re: New time stamping standard by ISO
> 
> Yet, everyone implement it this way, right?
> 
> If there is a need for change, it should begin with an update to RFC
> 3161.
> 
> Russ
> 
> At 06:00 PM 9/20/2006, Peter Gutmann wrote:
> 
> >Peter Sylvester <[email-masked]> writes:
> >
> > >This format seems to be targetted to transform the rfc 3161
> > example of how to
> > >add a timestamp to a signature into a simple cms countersignature.
> >
> >This not-quite-countersignature issue been a known flaw in TSP for a
> long
> >time.  Amusingly enough, even the RFC admits that the way it does
> things is
> >stupid.  Instead of the usual "MUST xxx" when specifying how to do
> >timestamping with CMS, it uses the rather unusual text "a sensible
> place to
> >...", and then goes on to define something that looks like a CMS
> >countersignature but is gratuitously incompatible with CMS
> countersignatures.
> >Since what it's doing isn't "sensible", by the spec's own admission
> it's
> >stupid.  It's unusual to see such frankness in an RFC.
> >
> >Peter :-).

Date: Wed, 20 Sep 2006 21:32:38 -0400
To: [email-masked], [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: New time stamping standard by ISO
Cc: [email-masked]
Sender: [email-masked]

Yet, everyone implement it this way, right?

If there is a need for change, it should begin with an update to RFC 3161.

Russ

At 06:00 PM 9/20/2006, Peter Gutmann wrote:

>Peter Sylvester <[email-masked]> writes:
>
> >This format seems to be targetted to transform the rfc 3161 
> example of how to
> >add a timestamp to a signature into a simple cms countersignature.
>
>This not-quite-countersignature issue been a known flaw in TSP for a long
>time.  Amusingly enough, even the RFC admits that the way it does things is
>stupid.  Instead of the usual "MUST xxx" when specifying how to do
>timestamping with CMS, it uses the rather unusual text "a sensible place to
>...", and then goes on to define something that looks like a CMS
>countersignature but is gratuitously incompatible with CMS countersignatures.
>Since what it's doing isn't "sensible", by the spec's own admission it's
>stupid.  It's unusual to see such frankness in an RFC.
>
>Peter :-).

Date: Wed, 20 Sep 2006 21:23:53 -0400
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Protecting Against Weak Hash Algorithms
Sender: [email-masked]

<html>
<body>
Can you make a presentation in San Diego?<br><br>
At 03:09 PM 9/20/2006, Santosh Chokhani wrote:<br>
<blockquote type=cite class=cite cite=""><font size=2>As you know the
hashing algorithms are in state of flux (We know MD5 is bad, SHA-1 is
beginning to smell and so on).<br>
&nbsp;<br>
Also, we know that many relying parties implement many of these
algorithms.<br>
&nbsp;<br>
Also, Russ has been talking about making PKIX RFCs algorithm independent
so that algorithms can be easily swapped in and out.<br>
&nbsp;<br>
I think we should have a debate on security issues surrounding weak
hashes, specifically relying parties snookered into verifying a signature
using a weak hash that can easily create collision with payload that was
actually signed using a strong hash.<br>
&nbsp;<br>
While it will be a great deal of pain to the client software, but subject
public key information through OID or parameters could specify one or
more hash algorithms to be used with a signature key.&nbsp; This will
protect against the spoofing of relying party into using a weak hash
during signature verification.&nbsp; I thought while we are debating the
syntax for ECC based algorithms, this may be a good time to suffer that
pain.<br>
&nbsp;<br>
</font><br>
<font size=2>Santosh Chokhani</font> <br>
<font size=2>Orion Security Solutions, Inc.</font> <br>
<font size=2>(703)</font> <font size=2>401-7088</font> <br>
<font size=2>[email-masked]</font> <br><br>
<font size=2>&nbsp;</font></blockquote></body>
</html>

Date: Wed, 20 Sep 2006 18:02:24 -0400
To: Joel Kazin <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: large crl's
Cc: Christine Karman <[email-masked]>, "Kemp David P." <[email-masked]>, [email-masked]
Sender: [email-masked]

At 9:42 AM -0400 9/20/06, Joel Kazin wrote:
>As Steven writes, RFC 3280 clearly places no obligation for CRLs to 
>include information on revoked certificates issued after their 
>respective notAfter dates.  However, there is often a obligation in 
>the CP or a need to prove that a CRL issued in the past indicated 
>that the certificate was revoked..
>

If the CP or CPS imposes such an obligation, then it becomes the 
responsibility of the CA to make older CRLs available. But the 
default, as per X.509 and RFC 3280, is NOT to mandate such archiving. 
This is reasonable under a "receipt model" which calls for the 
parties to a signed transaction to obtain and retain data like the 
certs and CRLs relevant to the transaction.

Steve

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: New time stamping standard by ISO
Cc: [email-masked]
Date: Thu, 21 Sep 2006 10:00:26 +1200
Sender: [email-masked]

Peter Sylvester <[email-masked]> writes:

>This format seems to be targetted to transform the rfc 3161 example of how to
>add a timestamp to a signature into a simple cms countersignature.

This not-quite-countersignature issue been a known flaw in TSP for a long
time.  Amusingly enough, even the RFC admits that the way it does things is
stupid.  Instead of the usual "MUST xxx" when specifying how to do
timestamping with CMS, it uses the rather unusual text "a sensible place to
...", and then goes on to define something that looks like a CMS
countersignature but is gratuitously incompatible with CMS countersignatures.
Since what it's doing isn't "sensible", by the spec's own admission it's
stupid.  It's unusual to see such frankness in an RFC.

Peter :-).

Content-Class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Wed, 20 Sep 2006 13:28:16 -0700
From: Ryan Hurst <[email-masked]>
To: Santosh Chokhani <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I understand the point, and in-fact it is why I originally recommended
the same solution you call out bellow with AIA in certs pointing to a
p7c; however connectivity is not as much an constant as we often like to
think.

With that in-mind there are other related scenarios to keep in mind when
evaluating a solution here:
1) General connectivity problems, you may have access to the url in the
CDP to acquire the CRL but not have access (server down, url is internal
to network but rp is out of network, etc) to the CRLs issuer certificate
referenced in its AIA.
2) Unreliable network connectivity, with the increase in mobile hosts
the chances of the connectivity going down after getting the CRL but
before the intermediate has been retrieved.
3) API performance - When building a generalized certificate handling
API its often necessary to have a "contract" with your callers, e.g. I
will return in n seconds reliably in these cases its desirable to reduce
the number of sockets being created.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, September 20, 2006 11:19 AM
To: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Thanks to Ryan for providing the following definitions of Pre-IP and
Post-IP off list.

"Pre IP = Situations like establishing network connectivity or verifying
signatures in boot before network connectivity.
Post IP = Situations where host or user has full IP connectivity."

Using the above definitions, it does not seem that adding the extension
is a particularly good idea to solve the problem for the connectivity
challenged scenarios.  The following is my thinking:

The question is how did we get the CRL (indirect or for that matter
direct one) in the first place.  The CRL is stored as an attribute of
the CRL issuer and hence when the CRL is obtained, certificate can also
be obtained, obviating the need.

Another alternative is for the CA that issued a certificate and
delegated indirect CRL issuer, can put in its AIA p7c bag the
certification path for the indirect CRL issuer.

Now, whoever is doing pre-IP fetch of certificates and CRL and is
loading the cache can have all these certificates.

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 5:13 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Hi Santosh - I think there are numerous benefits, for example:
1. Pre-IP scenarios that have the CRL but not the intermediates; more
likely in indirect cases.
2. Post-IP scenarios where all the intermediates and trust anchors' are
there except the indirect certificate so chain discovery must go online
to complete discovery; more likely in indirect cases.
3. Post-IP scenarios where no intermediates are present and the
implementing chain validation API must return in a specific time and the
allotted time is already used through other discovery and validation
phases, additional wire retrievals introduce more latency and should be
avoided if possible.

These are just a few off the top of my head, I am sure Stefan has
others.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Tuesday, September 19, 2006 12:28 PM
To: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Ryan,

Can you explain why "without having to go on the wire" makes sense?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan Hurst
Sent: Tuesday, September 19, 2006 2:21 PM
To: Russ Housley; Jean-Marc Desperrier; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

I was not personally suggesting the CRL carry a P7C but instead that a
certificate provide a pointer to a p7c that contains both the CRL and
the certificates that are necessary to validate it this way a
implementation that supported this model could choose this form of CRL
vs the traditional form.

However after speaking with Stefan I think we both better understand
each other's scenarios and I now agree with Stefan, supporting a mode
where a CRL contains sufficient information to kick of validation and
then discovery for indirect CRL cases without having to go on the wire
makes sense.

By scoping the inclusion of this proposed extension to indirect crls
associated with CAs you mitigate the performance and file size problems
that I was concerned with while still enabling solving the problem
Stefan calls out.

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Monday, September 18, 2006 8:46 AM
To: Jean-Marc Desperrier; [email-masked]
Subject: Re: Certs in CRLs - New standards task?

I support the idea of carrying a bag 'o certs.  However, I am not use 
what value is added by carrying a p7c.  It seems to be a heavy weight 
way to say SEQUENCE OF Certificate.

What am I missing?

Russ

At 09:21 AM 9/18/2006, Jean-Marc Desperrier wrote:

>Ryan Hurst wrote:
>>Have you considered the idea of introducing a new access method to the
>>AIA that would point to a P7c that possibly contained the CRL, its
>>issuers and maybe the certificates issuers?
>>
>I vote for p7c. Most CAs already include an option to distribute CRL
this way.
>
>After reading  RFC 2585, I think it misses something  by not saying 
>a word about the popular option of distributing crl and certificates 
>inside pkcs#7/CMS bags.
>
>When RFC 3280bis says that URIs inside a DistributionPointName must 
>point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it just
>making explicit a rule that was already required for proper
interoperability ?

Content-class: urn:content-classes:message
Subject: Protecting Against Weak Hash Algorithms
Date: Wed, 20 Sep 2006 12:09:53 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DCE8.5329AD4D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

As you know the hashing algorithms are in state of flux (We know MD5 is
bad, SHA-1 is beginning to smell and so on).

=20

Also, we know that many relying parties implement many of these
algorithms.

=20

Also, Russ has been talking about making PKIX RFCs algorithm independent
so that algorithms can be easily swapped in and out.

=20

I think we should have a debate on security issues surrounding weak
hashes, specifically relying parties snookered into verifying a
signature using a weak hash that can easily create collision with
payload that was actually signed using a strong hash.

=20

While it will be a great deal of pain to the client software, but
subject public key information through OID or parameters could specify
one or more hash algorithms to be used with a signature key.  This will
protect against the spoofing of relying party into using a weak hash
during signature verification.  I thought while we are debating the
syntax for ECC based algorithms, this may be a good time to suffer that
pain.

=20

Santosh Chokhani=20
Orion Security Solutions, Inc.=20
(703) 401-7088=20
[email-masked]=20

=20

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

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>As
you know the hashing algorithms are in state of flux (We know MD5 is =
bad, SHA-1
is beginning to smell and so on).<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Also,
we know that many relying parties implement many of these =
algorithms.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>Also,
Russ has been talking about making PKIX RFCs algorithm independent so =
that
algorithms can be easily swapped in and =
out.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>I
think we should have a debate on security issues surrounding weak =
hashes, specifically
relying parties snookered into verifying a signature using a weak hash =
that can
easily create collision with payload that was actually signed using a =
strong
hash.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt'>While
it will be a great deal of pain to the client software, but subject =
public key information
through OID or parameters could specify one or more hash algorithms to =
be used
with a signature key.&nbsp; This will protect against the spoofing of =
relying
party into using a weak hash during signature verification.&nbsp; I =
thought
while we are debating the syntax for ECC based algorithms, this may be a =
good
time to suffer that pain.<o:p></o:p></span></font></p>

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

<p><st1:PersonName w:st=3D"on"><font size=3D2 face=3DArial><span =
style=3D'font-size:
 10.0pt;font-family:Arial'>Santosh =
Chokhani</span></font></st1:PersonName> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Orion
Security Solutions, Inc.</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>(703)</span></font>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>401-7088</span></font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>[email-masked]</span>=
</font>
<br>
<br>
<o:p></o:p></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C6DCE8.5329AD4D--

Date: Wed, 20 Sep 2006 16:00:01 -0300
Reply-To: "Lowell Leal" <[email-masked]>
From: "Lowell Leal" <[email-masked]>
To: <[email-masked]>
Subject: PHmjARtMA

This is a multi-part message in MIME format.

------=_NextPart_000_1E09_01C6DCCD.D41CEE30
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi
=20

VALnnIUM

AMBnnIEN

VIAnnGRA

CIAnnLIS

=20
Economize with http://www.kilupomunhetunde.com

------=_NextPart_000_1E09_01C6DCCD.D41CEE30
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<P>VALnnIUM</P>
<P>AMBnnIEN</P>
<P>VIAnnGRA</P>
<P>CIAnnLIS</P>
<DIV>&nbsp;</DIV>
<DIV>Economize with <A =
href=3D"http://www.kilupomunhetunde.com">http://www.kilupomunhetunde.com<=
/A></DIV></BODY></HTML>
------=_NextPart_000_1E09_01C6DCCD.D41CEE30--

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Wed, 20 Sep 2006 11:18:36 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Thanks to Ryan for providing the following definitions of Pre-IP and
Post-IP off list.

"Pre IP = Situations like establishing network connectivity or verifying
signatures in boot before network connectivity.
Post IP = Situations where host or user has full IP connectivity."

Using the above definitions, it does not seem that adding the extension
is a particularly good idea to solve the problem for the connectivity
challenged scenarios.  The following is my thinking:

The question is how did we get the CRL (indirect or for that matter
direct one) in the first place.  The CRL is stored as an attribute of
the CRL issuer and hence when the CRL is obtained, certificate can also
be obtained, obviating the need.

Another alternative is for the CA that issued a certificate and
delegated indirect CRL issuer, can put in its AIA p7c bag the
certification path for the indirect CRL issuer.

Now, whoever is doing pre-IP fetch of certificates and CRL and is
loading the cache can have all these certificates.

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 5:13 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Hi Santosh - I think there are numerous benefits, for example:
1. Pre-IP scenarios that have the CRL but not the intermediates; more
likely in indirect cases.
2. Post-IP scenarios where all the intermediates and trust anchors' are
there except the indirect certificate so chain discovery must go online
to complete discovery; more likely in indirect cases.
3. Post-IP scenarios where no intermediates are present and the
implementing chain validation API must return in a specific time and the
allotted time is already used through other discovery and validation
phases, additional wire retrievals introduce more latency and should be
avoided if possible.

These are just a few off the top of my head, I am sure Stefan has
others.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Tuesday, September 19, 2006 12:28 PM
To: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Ryan,

Can you explain why "without having to go on the wire" makes sense?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan Hurst
Sent: Tuesday, September 19, 2006 2:21 PM
To: Russ Housley; Jean-Marc Desperrier; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

I was not personally suggesting the CRL carry a P7C but instead that a
certificate provide a pointer to a p7c that contains both the CRL and
the certificates that are necessary to validate it this way a
implementation that supported this model could choose this form of CRL
vs the traditional form.

However after speaking with Stefan I think we both better understand
each other's scenarios and I now agree with Stefan, supporting a mode
where a CRL contains sufficient information to kick of validation and
then discovery for indirect CRL cases without having to go on the wire
makes sense.

By scoping the inclusion of this proposed extension to indirect crls
associated with CAs you mitigate the performance and file size problems
that I was concerned with while still enabling solving the problem
Stefan calls out.

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Monday, September 18, 2006 8:46 AM
To: Jean-Marc Desperrier; [email-masked]
Subject: Re: Certs in CRLs - New standards task?

I support the idea of carrying a bag 'o certs.  However, I am not use 
what value is added by carrying a p7c.  It seems to be a heavy weight 
way to say SEQUENCE OF Certificate.

What am I missing?

Russ

At 09:21 AM 9/18/2006, Jean-Marc Desperrier wrote:

>Ryan Hurst wrote:
>>Have you considered the idea of introducing a new access method to the
>>AIA that would point to a P7c that possibly contained the CRL, its
>>issuers and maybe the certificates issuers?
>>
>I vote for p7c. Most CAs already include an option to distribute CRL
this way.
>
>After reading  RFC 2585, I think it misses something  by not saying 
>a word about the popular option of distributing crl and certificates 
>inside pkcs#7/CMS bags.
>
>When RFC 3280bis says that URIs inside a DistributionPointName must 
>point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it just
>making explicit a rule that was already required for proper
interoperability ?

From: "Liaquat Khan" <[email-masked]>
To: "'Hallam-Baker, Phillip'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "'Christine Karman'" <[email-masked]>
Cc: "'Kemp David P.'" <[email-masked]>, <[email-masked]>
Subject: RE: large crl's
Date: Wed, 20 Sep 2006 18:45:47 +0100
Sender: [email-masked]

Yes I agree; our customers definitely see a need for being able to validate
the status of a certificate beyond its expiry date.  As you say this is not
for certificates used for real-time "authentication" purposes but for
digital signatures on long-term documents. We have actually already
implemented this in our validation server (i.e. the archival of each CRL
from a particular CA and then providing facility to check certificate
against historical CRLs).  Of course timestamping also has a big part to
play in this process.  From a business point of view, how long CRLs are
archived should be configurable. 

Regards,
LK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hallam-Baker, Phillip
Sent: 20 September 2006 14:49
To: Stephen Kent; Christine Karman
Cc: Kemp David P.; [email-masked]
Subject: RE: large crl's

If you want to have an archival capability knowing the revocation status of
expired certificates is an essential operational capability.

If the CRL does not have that information it is not an appropriate
technology for that application.

In a messaging environment you are very likely to want archival capabilities
and in particular the ability to query the status of the certificate on a
particular day.

For SSL it does not matter as the only status that matters is current
status.

If Ben Franklin had signed the US constitution with a digital signature
people would probably want to know if it was still valid after his
certificate had expired.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Tuesday, September 19, 2006 8:56 PM
> To: Christine Karman
> Cc: Kemp David P.; [email-masked]
> Subject: RE: large crl's
> 
> 
> At 11:04 AM +0200 9/19/06, Christine Karman wrote:
> >...
> >Another difference between authentication in a browser and 
> email is the 
> >following. A company archives old email. They have to be 
> able to verify 
> >validity of digital signatures on incoming email, even for 
> certificates 
> >that have expired long ago. The DOD will have to have that 20Mb crl 
> >available forever, unless they switch to online verification.
> 
> There is no requirement for a CA to maintain entries on a CRL 
> after the certs in question have expired.  Your model re CRL 
> management is inconsistent with RFC 3280 requirements.
> 
> Steve
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: large crl's
Date: Wed, 20 Sep 2006 10:27:06 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Phillip,

For the scenarios you cite, I encourage you to look at the LTANS working
group work as well as specific I-D related to getting archived PKI
artifacts.

As you know, verifying old signatures entails more than simply having a
cumulative CRL.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, September 20, 2006 9:49 AM
To: Stephen Kent; Christine Karman
Cc: Kemp David P.; [email-masked]
Subject: RE: large crl's

If you want to have an archival capability knowing the revocation status
of expired certificates is an essential operational capability.

If the CRL does not have that information it is not an appropriate
technology for that application.

In a messaging environment you are very likely to want archival
capabilities and in particular the ability to query the status of the
certificate on a particular day.

For SSL it does not matter as the only status that matters is current
status.

If Ben Franklin had signed the US constitution with a digital signature
people would probably want to know if it was still valid after his
certificate had expired.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Tuesday, September 19, 2006 8:56 PM
> To: Christine Karman
> Cc: Kemp David P.; [email-masked]
> Subject: RE: large crl's
> 
> 
> At 11:04 AM +0200 9/19/06, Christine Karman wrote:
> >...
> >Another difference between authentication in a browser and 
> email is the 
> >following. A company archives old email. They have to be 
> able to verify 
> >validity of digital signatures on incoming email, even for 
> certificates 
> >that have expired long ago. The DOD will have to have that 20Mb crl 
> >available forever, unless they switch to online verification.
> 
> There is no requirement for a CA to maintain entries on a CRL 
> after the certs in question have expired.  Your model re CRL 
> management is inconsistent with RFC 3280 requirements.
> 
> Steve
> 
> 
> 

From: "Al Arsenault" <[email-masked]>
To: "'Hallam-Baker, Phillip'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "'Christine Karman'" <[email-masked]>
Cc: "'Kemp David P.'" <[email-masked]>, <[email-masked]>
Subject: RE: large crl's
Date: Wed, 20 Sep 2006 13:22:34 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_005E_01C6DCB7.D566D550
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Phill,

=20

=20

*       If you want to have an archival capability knowing the =
revocation
status of expired certificates is an essential operational capability.

=20

Yes, so?  We worked on archival requirements for the DoD PKI more than =
10
years ago. This is well understood. One other thing to point out is that =
in
order for this archive solution to work, you have to have a secure, =
strong
time-stamping service (which hasn't been mentioned).  Once your =
signature
key is broken, it was "always" broken - I can create a document, sign it
with your broken key, and back-date it to whenever I want.  The only way =
for
you to stop that is to have some secure, strong system for telling (with
high probability of accuracy) whether the document actually existed at =
the
claimed time.=20

=20

*       If the CRL does not have that information it is not an =
appropriate
technology for that application.

=20

If you use CRLs, you have two options.  One is to keep the "current" CRL =
at
the time the message was signed or first verified, and keep it securely
bound to the message.

The other is to have an archive capability that lets you re-generate the =
CRL
as it existed at any given time in the past.

=20

Similarly with OCSP.  You have two options: get an OCSP response when =
the
message was first signed/verified, and securely bind that to the message =
and
store them; or have an ability to determine certificate status at any =
given
point in the past and re-create an appropriate OCSP response.

=20

There's no practical difference. Either solution will work, and either
solution is subject to good or bad engineering solutions.

=20

*       In a messaging environment you are very likely to want archival
capabilities and in particular the ability to query the status of the
certificate on a particular day.

=20

Yep.

=20

*       For SSL it does not matter as the only status that matters is
current status.

=20

*       If Ben Franklin had signed the US constitution with a digital
signature people would probably want to know if it was still valid after =
his
certificate had expired.

=20

I'm not sure why, but okay, no problem - that can be supported.

=20

                  Al Arsenault

=20

=20

------=_NextPart_000_005E_01C6DCB7.D566D550
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html>

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

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

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 77.95pt 1.0in 77.95pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Phill,</span></font></p>

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

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

<p class=3DMsoPlainText =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
face=3DSymbol><span =
style=3D'font-size:10.0pt;font-family:Symbol'>&sup3;<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font>If you want to have an archival capability =
knowing
the revocation status of expired certificates is an essential =
operational
capability.</p>

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

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>Yes, so?&nbsp; We worked on =
archival
requirements for the DoD PKI more than 10 years ago. This is well =
understood.
One other thing to point out is that in order for this archive solution =
to
work, you have to have a secure, strong time-stamping service (which =
hasn&#8217;t
been mentioned).&nbsp; Once your signature key is broken, it was =
&#8220;always&#8221;
broken &#8211; I can create a document, sign it with your broken key, =
and
back-date it to whenever I want. &nbsp;The only way for you to stop that =
is to
have some secure, strong system for telling (with high probability of =
accuracy)
whether the document actually existed at the claimed time. =
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;</span></font></p>

<p class=3DMsoPlainText =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
face=3DSymbol><span =
style=3D'font-size:10.0pt;font-family:Symbol'>&sup3;<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font>If the CRL does not have that information it =
is not
an appropriate technology for that application.</p>

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

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>If you use CRLs, you have two
options.&nbsp; One is to keep the &#8220;current&#8221; CRL at the time =
the
message was signed or first verified, and keep it securely bound to the
message.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><br>
The other is to have an archive capability that lets you re-generate the =
CRL as
it existed at any given time in the past.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>Similarly with OCSP.&nbsp; You =
have two
options: get an OCSP response when the message was first =
signed/verified, and
securely bind that to the message and store them; or have an ability to
determine certificate status at any given point in the past and =
re-create an
appropriate OCSP response.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>There&#8217;s no practical =
difference. Either
solution will work, and either solution is subject to good or bad =
engineering
solutions.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;</span></font></p>

<p class=3DMsoPlainText =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
face=3DSymbol><span =
style=3D'font-size:10.0pt;font-family:Symbol'>&sup3;<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font>In a messaging environment you are very =
likely to
want archival capabilities and in particular the ability to query the =
status of
the certificate on a particular day.</p>

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

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>Yep.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;</span></font></p>

<p class=3DMsoPlainText =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
face=3DSymbol><span =
style=3D'font-size:10.0pt;font-family:Symbol'>&sup3;<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font>For SSL it does not matter as the only =
status that
matters is current status.</p>

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

<p class=3DMsoPlainText =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
face=3DSymbol><span =
style=3D'font-size:10.0pt;font-family:Symbol'>&sup3;<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font>If Ben Franklin had signed the US =
constitution with
a digital signature people would probably want to know if it was still =
valid
after his certificate had expired.</p>

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

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>I&#8217;m not sure why, but okay, =
no
problem &#8211; that can be supported.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Al
Arsenault</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;</span></font></p>

<p class=3DMsoPlainText style=3D'text-indent:6.0pt'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_005E_01C6DCB7.D566D550--

Content-class: urn:content-classes:message
Subject: RE: large crl's
Date: Wed, 20 Sep 2006 09:50:56 -0400
From: "Kemp David P." <[email-masked]>
To: "Dave Engberg" <[email-masked]>, "Christine Karman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Dave,

Good to discuss this with you again.

1) I find it difficult to believe that an ECP to change a CA
product's fixed partition size of 750 to a configurable
partition size would be that expensive.  And even with
the fixed size, 3.7KB is not an unreasonable status
size when compared to 20MB CRLs or the average size of
an email message or web page.

Also, although an individual 750 cert CRL is twice the size of an
individual 20 cert OCSP, the aggregate of OCSP for 10 million
subscribers is nearly 20 times the aggregate of CRLs
(half a million OCSPs vs. 13 thousand CRLs, or 925MB vs. 50MB).

2) I have never understood the point you make about tuning.
With a fixed partition size of 750 certs, even if some event
caused 100% of them to be revoked immediately after issuance,
that would result in a CRL of 22.7KB (modulo assumptions)
being issued for the life of the certs (3 years).  22.7KB isn't
a killer, and one wouldn't expect new usage of a certificate
3 years after it was revoked.  So those 22.7KB CRLs would be
fetched for a few days until the certs were flushed out of
the system, with a small usage tail coming from people
verifying archived signed data.  That just isn't a problem
that needs solving.  Optimization per subscriber community
is nice (device certs might be revoked less frequently than
people certs, so device CRLs would cover more certs per
partition), but additional dynamic optimization over the
lifetime of a cert gets into diminishing returns.

Another advantage of partitioned CRLs over OCSP is that they
can be treated just like any other web document - cached by
proxies that everyone has already deployed to support normal
web traffic.  It's great that the DoD OCSP service uses Akamai
technology, but custom provisioning to support OCSP costs more
than off-the-shelf provisioning already in place for the web.

Dave

-----Original Message-----
From: Dave Engberg [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 5:50 PM
To: Kemp David P.; Christine Karman; [email-masked]
Subject: RE: large crl's

This is comparing a theoretical against an actual.

If the US DoD were using the CA that supports automated CRL
partitioning,
then each CRL would represent the status of 750 certs.  With the DoD's
20%
rate of revocation, the average CRL partition would have 150 entries, or
around 3.7kB.  This is twice as large as the actual OCSP responses
returned
by the DoD today, and the upper bound on a CRL partition size is
significantly larger.

It's important to note that any CRL partitioning is fixed for the entire
lifetime of the certs ... you can't change your tuning later to improve
bandwidth to the client or (inversely) the aggregate size and number of
segments to replicate.  An OCSP deployment can be tuned independently
long
after cert issuance based on the operational usage characteristics.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of Kemp David P.
Sent: Tuesday, September 19, 2006 10:22 AM
To: Christine Karman; [email-masked]
Subject: RE: large crl's

...

One difference is size.  For any given number of certificates, an OCSP
response is significantly *larger* than a CRL!  An OCSP message is about
350
bytes body + 79/unrevoked cert + 101/revoked cert.  A CRL, in contrast,
is
about 200 bytes body + 0/unrevoked cert + 30/revoked cert.
(both modulo assumptions on DN size, serial number size, signature size,
use
of extensions, etc).  

...

If a 1% revocation rate doesn't reflect your subscriber base, then
assume
40% of certificates are revoked, yielding the following CRL and OCSP
sizes:

Certs/   40% revoked
query    CRL    OCSP
   1     212     438
   2     224     526
   5     260     789
  10     320   1,228
  20     440   2,106
  50     800   4,740
 100   1,400   9,130
 200   2,600  17,910
 500   6,200  44,250
1000  12,200  88,150

What does this mean, since nobody does an OCSP query on 1000 certs?  It
means that if you set some threshold on the acceptable size for a
certificate status message, a CRL can represent the status of many more
certificates than an OCSP response.  If 500 bytes is your limit, that
would
be an OCSP response for 2 certs, or a partitioned CRL covering 20 certs.
If
2K bytes is your limit, that would accommodate an OCSP response for 20
certs, or a CRL covering a 150-cert partition.

Another way of looking at it would be to assume that a company needs to
store revocation status for email messages of its 10,000 employees.  If
it
stored 10 partitioned CRLs, that would require 122 KB.  If instead it
stored
10,000 OCSP responses, that would require 4,380 KB for the same set of
employees.

The point of the above is that it is incorrect to assume that "online
verification" means only "OCSP", and even more incorrect to assume that
because one organization has done a horrible job of engineering its
CRLs,
the fault lies with the CRLs themselves.

Content-class: urn:content-classes:message
Subject: RE: large crl's
Date: Wed, 20 Sep 2006 06:48:50 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Christine Karman" <[email-masked]>
Cc: "Kemp David P." <[email-masked]>, <[email-masked]>
Sender: [email-masked]

If you want to have an archival capability knowing the revocation status of expired certificates is an essential operational capability.

If the CRL does not have that information it is not an appropriate technology for that application.

In a messaging environment you are very likely to want archival capabilities and in particular the ability to query the status of the certificate on a particular day.

For SSL it does not matter as the only status that matters is current status.

If Ben Franklin had signed the US constitution with a digital signature people would probably want to know if it was still valid after his certificate had expired.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Tuesday, September 19, 2006 8:56 PM
> To: Christine Karman
> Cc: Kemp David P.; [email-masked]
> Subject: RE: large crl's
> 
> 
> At 11:04 AM +0200 9/19/06, Christine Karman wrote:
> >...
> >Another difference between authentication in a browser and 
> email is the 
> >following. A company archives old email. They have to be 
> able to verify 
> >validity of digital signatures on incoming email, even for 
> certificates 
> >that have expired long ago. The DOD will have to have that 20Mb crl 
> >available forever, unless they switch to online verification.
> 
> There is no requirement for a CA to maintain entries on a CRL 
> after the certs in question have expired.  Your model re CRL 
> management is inconsistent with RFC 3280 requirements.
> 
> Steve
> 
> 
> 

Date: Wed, 20 Sep 2006 09:42:35 -0400
From: Joel Kazin <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Christine Karman <[email-masked]>, "Kemp David P." <[email-masked]>, [email-masked]
Subject: Re: large crl's
Sender: [email-masked]

As Steven writes, RFC 3280 clearly places no obligation for CRLs to 
include information on revoked certificates issued after their 
respective notAfter dates.  However, there is often a obligation in the 
CP or a need to prove that a CRL issued in the past indicated that the 
certificate was revoked..

Stephen Kent wrote:

>
> At 11:04 AM +0200 9/19/06, Christine Karman wrote:
>
>> ...
>> Another difference between authentication in a browser and email is 
>> the following. A company archives old email. They have to be able to 
>> verify validity of digital signatures on incoming email, even for 
>> certificates that have expired long ago. The DOD will have to have 
>> that 20Mb crl available forever, unless they switch to online 
>> verification.
>
>
> There is no requirement for a CA to maintain entries on a CRL after 
> the certs in question have expired.  Your model re CRL management is 
> inconsistent with RFC 3280 requirements.
>
> Steve
>
>
>

Date: Wed, 20 Sep 2006 00:43:23 -0700 (MST)
Reply-To: "Warwick Marlett" <[email-masked]>
From: "Warwick Marlett" <[email-masked]>
To: <[email-masked]>
Subject: PHnARoMA

This is a multi-part message in MIME format.

------=_NextPart_000_04B9_01C6DCA9.FBFE5250
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

Hi
=20

AMBzzIEN

VIAzzGRA

VALzzIUM

CIAzzLIS

=20
Directly from the manufacturer http://www.herinkdewunjation.com

------=_NextPart_000_04B9_01C6DCA9.FBFE5250
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<P>AMBzzIEN</P>
<P>VIAzzGRA</P>
<P>VALzzIUM</P>
<P>CIAzzLIS</P>
<DIV>&nbsp;</DIV>
<DIV>Directly from the manufacturer <A =
href=3D"http://www.herinkdewunjation.com">http://www.herinkdewunjation.co=
m</A></DIV></BODY></HTML>
------=_NextPart_000_04B9_01C6DCA9.FBFE5250--

From: "Anders Rundgren" <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Cc: "Stephen Farrell" <[email-masked]>, <[email-masked]>
Subject: Re: 3280-bis AIA update
Date: Wed, 20 Sep 2006 06:55:16 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Hi Dave,
It was extremely pleasing to note that AIA now is going to be described =
in the way it is actually used :-)

I do though not fully agree with the notion that there should be a MUST =
for .cer and a SHOULD for application/pkix-cert because this is against =
the general web practice where file extensions are largely irrelevant =
since the source of an object often is a web application rather than a =
file.  Maybe this is because you regard "certificate user" as a human =
with browser trying to download a file which he or she is going to click =
on?  I see AIA as a programmatic interface used by cryptographic =
software.  Such "users" do not have much chance doing anything but =
trusting the file extension or mime-type.  Mime-type seems like a better =
choice here.  MUST please.

Regarding current CA practice, the file extension .crt seems pretty =
common and unfortunately there are other MIME-types in use as well.  I =
would investigate this a bit a write a few lines of "legacy =
implementations" that you SHOULD support  This is the price we have to =
pay due to the fact that AIA was originally a bit underspecified.

Anders

----- Original Message -----=20
From: David A. Cooper=20
To: Anders Rundgren=20
Cc: Stephen Farrell ; [email-masked]=20
Sent: Tuesday, September 19, 2006 23:13
Subject: Re: 3280-bis AIA update

Anders,

I agree that the language in RFC 3280 was confusing.  I would suggest =
that you read section 4.2.2.1 of 3280bis, since you may find that the =
changes you seek have already been made.  If you look at =
http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-02_diff.htm=
l you will see a version of draft 2 of 3280bis in which all changes from =
RFC 3280 are highlighted.   The current draft of 3280bis is draft 4 =
(http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-04.txt), =
but section 4.2.2.1 has been practically unchanged since draft 2 (a =
couple of typographical errors were fixed and a few references to =
updated to newer RFCs).

Dave

Anders Rundgren wrote:=20
At this stage I would be happy to know if my interpretation [*]
of the AIA extension is correct or not.   IF my interpretation
is correct, Dave's job ought to be verifying my claim that the
defintion is in conflict with the current practice for FIPS201 CAs.
IF this also is verified, the issue is what to do next.

Anders

*]

RFC3280: the additional information lists CAs that have issued =
certificates
*superior* to the CA that issued the certificate containing this =
extension

                     <>

Practice: the additional information lists CAs that have issued =
certificates
*including* the CA that issued the certificate containing this extension

----- Original Message -----=20
From: "Stephen Farrell" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 19, 2006 18:06
Subject: Re: 3280-bis AIA update

Anders,

If you could propose text for inclusion that'd make the Dave's
editing job much easier, if there is consensus to make whatever
change you propose.

I'm not being picky, its just not clear to me what change you'd
like,

Stephen.

Anders Rundgren wrote:
  A quick survey among existing CAs show that they indeed
do not return the CA cert that is "superior" to the CA that
issued the EE cert containing the AIA extension, but rather
[the only reasonable,] the CA cert that issued the EE cert.

Maybe 3280-bis should be updated to reflect the actual
implementation of the AIA caIssuers extension?

An off-list message verified that several FIPS201 implementations
in the workings rely on a revised AIA caIssuers definition.

I also believe that the following text is not entirely appropriate:

  "The referenced CA issuers description is intended to aid
   certificate users in the selection of  a certification path"

The "description" is a list of certificates isn't it?
What is a "certificate user"?  It includes "applications" like
TLS-client-authentication as well I guess?

BTW, it would not hurt to add a few lines about how a list of CA
certificates should be packaged including references to applicable RFCs.

Anders

----- Original Message -----=20
From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 14, 2006 23:32
Subject: AIA - No Issuing CA support?

RFC 3280  =20
   "The id-ad-caIssuers OID is used when the additional information =
lists
   CAs that have issued certificates *superior* to the CA that issued =
the
   certificate containing this extension.  The referenced CA issuers
   description is intended to aid certificate users in the selection of
   a certification path that terminates at a point trusted by the
   certificate user"

Assume I have a FIPS201 card (that as far as I can tell do not contain
any CA certificates at all), how can I locate the actual issuing CA?

Anders

   =20

 =20

------=_NextPart_000_002D_01C6DC81.BAB05CD0
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><TITLE></TITLE>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>It was =
<EM>extremely</EM> pleasing to=20
note that AIA now is going to be described in the way it is actually =
used=20
:-)</FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#800080>I do though =
not fully=20
agree with the notion that there should be a MUST for .cer and a SHOULD =
for=20
application/pkix-cert because this is against the general web practice =
where=20
file extensions are largely irrelevant since the source of an object =
often is a=20
web application rather than a file.&nbsp; Maybe&nbsp;this is because you =
regard=20
"certificate user" as a human with browser trying to download a file =
which he or=20
she is going to click on?&nbsp; I see AIA as a programmatic interface =
used by=20
cryptographic software.&nbsp; Such "users" do not have much chance doing =

anything but trusting the file extension or mime-type.&nbsp; Mime-type =
seems=20
like a better choice here.&nbsp; MUST please.</FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>Regarding current CA =
practice, the=20
file extension .crt seems pretty common and unfortunately there are =
other=20
MIME-types in use as well.&nbsp; I would investigate this a bit a write =
a few=20
lines of "legacy implementations" that you SHOULD =
support&nbsp;&nbsp;This is the=20
price we have to pay due to the fact that AIA was originally a bit=20
underspecified.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>Anders</FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2></FONT>&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
title=[email-masked] =
href=3D"mailto:[email-masked]">David A.=20
Cooper</A> </DIV>
<DIV><B>To:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">Anders Rundgren</A> </DIV>
<DIV><B>Cc:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">Stephen Farrell</A> ; <A=20
title=[email-masked] =
href=3D"mailto:[email-masked]">[email-masked]</A>=20
</DIV>
<DIV><B>Sent:</B> Tuesday, September 19, 2006 23:13</DIV>
<DIV><B>Subject:</B> Re: 3280-bis AIA update</DIV></DIV>
<DIV><BR></DIV>Anders,<BR><BR>I agree that the language in RFC 3280 was=20
confusing.&nbsp; I would suggest that you read section 4.2.2.1 of =
3280bis, since=20
you may find that the changes you seek have already been made.&nbsp; If =
you look=20
at <A class=3Dmoz-txt-link-freetext=20
href=3D"http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-02_=
diff.html">http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-=
02_diff.html</A>=20
you will see a version of draft 2 of 3280bis in which all changes from =
RFC 3280=20
are highlighted.&nbsp;&nbsp; The current draft of 3280bis is draft 4 (<A =

class=3Dmoz-txt-link-freetext=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-04=
.txt">http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-04.t=
xt</A>),=20
but section 4.2.2.1 has been practically unchanged since draft 2 (a =
couple of=20
typographical errors were fixed and a few references to updated to newer =

RFCs).<BR><BR>Dave<BR><BR>Anders Rundgren wrote:=20
<BLOCKQUOTE cite=3Dmid03c601c6dc14$b4a310c0$82c5a8c0@arport2v =
type=3D"cite"><PRE wrap=3D"">At this stage I would be happy to know if =
my interpretation [*]
of the AIA extension is correct or not.   IF my interpretation
is correct, Dave's job ought to be verifying my claim that the
defintion is in conflict with the current practice for FIPS201 CAs.
IF this also is verified, the issue is what to do next.

Anders

*]

RFC3280: the additional information lists CAs that have issued =
certificates
*superior* to the CA that issued the certificate containing this =
extension

                     &lt;&gt;

Practice: the additional information lists CAs that have issued =
certificates
*including* the CA that issued the certificate containing this extension

----- Original Message -----=20
From: "Stephen Farrell" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:[email-masked]">&lt;[email-masked]&g=
t;</A>
To: "Anders Rundgren" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:[email-masked]">&lt;[email-masked]&g=
t;</A>
Cc: <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:[email-masked]">&lt;[email-masked]&gt;</A>
Sent: Tuesday, September 19, 2006 18:06
Subject: Re: 3280-bis AIA update

Anders,

If you could propose text for inclusion that'd make the Dave's
editing job much easier, if there is consensus to make whatever
change you propose.

I'm not being picky, its just not clear to me what change you'd
like,

Stephen.

Anders Rundgren wrote:
  </PRE>
  <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">A quick survey among existing =
CAs show that they indeed
do not return the CA cert that is "superior" to the CA that
issued the EE cert containing the AIA extension, but rather
[the only reasonable,] the CA cert that issued the EE cert.

Maybe 3280-bis should be updated to reflect the actual
implementation of the AIA caIssuers extension?

An off-list message verified that several FIPS201 implementations
in the workings rely on a revised AIA caIssuers definition.

I also believe that the following text is not entirely appropriate:

  "The referenced CA issuers description is intended to aid
   certificate users in the selection of  a certification path"

The "description" is a list of certificates isn't it?
What is a "certificate user"?  It includes "applications" like
TLS-client-authentication as well I guess?

BTW, it would not hurt to add a few lines about how a list of CA
certificates should be packaged including references to applicable RFCs.

Anders

----- Original Message -----=20
From: "Anders Rundgren" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:[email-masked]">&lt;[email-masked]&g=
t;</A>
To: <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:[email-masked]">&lt;[email-masked]&gt;</A>
Sent: Thursday, September 14, 2006 23:32
Subject: AIA - No Issuing CA support?

RFC 3280  =20
   "The id-ad-caIssuers OID is used when the additional information =
lists
   CAs that have issued certificates *superior* to the CA that issued =
the
   certificate containing this extension.  The referenced CA issuers
   description is intended to aid certificate users in the selection of
   a certification path that terminates at a point trusted by the
   certificate user"

Assume I have a FIPS201 card (that as far as I can tell do not contain
any CA certificates at all), how can I locate the actual issuing CA?

Anders

    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->

  </PRE></BLOCKQUOTE><BR></BODY></HTML>

------=_NextPart_000_002D_01C6DC81.BAB05CD0--

Date: Tue, 19 Sep 2006 20:56:02 -0400
To: Christine Karman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: large crl's
Cc: "Kemp David P." <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11:04 AM +0200 9/19/06, Christine Karman wrote:
>...
>Another difference between authentication in a browser and email is 
>the following. A company archives old email. They have to be able to 
>verify validity of digital signatures on incoming email, even for 
>certificates that have expired long ago. The DOD will have to have 
>that 20Mb crl available forever, unless they switch to online 
>verification.

There is no requirement for a CA to maintain entries on a CRL after 
the certs in question have expired.  Your model re CRL management is 
inconsistent with RFC 3280 requirements.

Steve

Content-class: urn:content-classes:message
Subject: RE: large crl's
Date: Tue, 19 Sep 2006 17:01:36 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Dave Engberg" <[email-masked]>, "Kemp David P." <[email-masked]>, "Christine Karman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Message sizes should be measured in packets, not bytes. The TCP startup
overhead dominates here.

You couldhave partition size=1 cert but the group decided against that
approach. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Engberg
> Sent: Tuesday, September 19, 2006 5:50 PM
> To: Kemp David P.; Christine Karman; [email-masked]
> Subject: RE: large crl's
> 
> 
> This is comparing a theoretical against an actual.
> 
> If the US DoD were using the CA that supports automated CRL 
> partitioning, then each CRL would represent the status of 750 
> certs.  With the DoD's 20% rate of revocation, the average 
> CRL partition would have 150 entries, or around 3.7kB.  This 
> is twice as large as the actual OCSP responses returned by 
> the DoD today, and the upper bound on a CRL partition size is 
> significantly larger.
> 
> It's important to note that any CRL partitioning is fixed for 
> the entire lifetime of the certs ... you can't change your 
> tuning later to improve bandwidth to the client or 
> (inversely) the aggregate size and number of segments to 
> replicate.  An OCSP deployment can be tuned independently 
> long after cert issuance based on the operational usage 
> characteristics.
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kemp David P.
> Sent: Tuesday, September 19, 2006 10:22 AM
> To: Christine Karman; [email-masked]
> Subject: RE: large crl's
> 
> ...
> 
> One difference is size.  For any given number of 
> certificates, an OCSP response is significantly *larger* than 
> a CRL!  An OCSP message is about 350 bytes body + 
> 79/unrevoked cert + 101/revoked cert.  A CRL, in contrast, is 
> about 200 bytes body + 0/unrevoked cert + 30/revoked cert.
> (both modulo assumptions on DN size, serial number size, 
> signature size, use of extensions, etc).  
> 
> ...
> 
> If a 1% revocation rate doesn't reflect your subscriber base, 
> then assume 40% of certificates are revoked, yielding the 
> following CRL and OCSP sizes:
> 
> Certs/   40% revoked
> query    CRL    OCSP
>    1     212     438
>    2     224     526
>    5     260     789
>   10     320   1,228
>   20     440   2,106
>   50     800   4,740
>  100   1,400   9,130
>  200   2,600  17,910
>  500   6,200  44,250
> 1000  12,200  88,150
> 
> What does this mean, since nobody does an OCSP query on 1000 
> certs?  It means that if you set some threshold on the 
> acceptable size for a certificate status message, a CRL can 
> represent the status of many more certificates than an OCSP 
> response.  If 500 bytes is your limit, that would be an OCSP 
> response for 2 certs, or a partitioned CRL covering 20 certs. 
>  If 2K bytes is your limit, that would accommodate an OCSP 
> response for 20 certs, or a CRL covering a 150-cert partition.
> 
> Another way of looking at it would be to assume that a 
> company needs to store revocation status for email messages 
> of its 10,000 employees.  If it stored 10 partitioned CRLs, 
> that would require 122 KB.  If instead it stored 10,000 OCSP 
> responses, that would require 4,380 KB for the same set of employees.
> 
> The point of the above is that it is incorrect to assume that 
> "online verification" means only "OCSP", and even more 
> incorrect to assume that because one organization has done a 
> horrible job of engineering its CRLs, the fault lies with the 
> CRLs themselves.
> 
> 

Content-class: urn:content-classes:message
Subject: RE: large crl's
Date: Tue, 19 Sep 2006 17:50:10 -0400
From: "Dave Engberg" <[email-masked]>
To: "Kemp David P." <[email-masked]>, "Christine Karman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00DE_01C6DC14.0D68B3A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

This is comparing a theoretical against an actual.

If the US DoD were using the CA that supports automated CRL partitioning,
then each CRL would represent the status of 750 certs.  With the DoD's 20%
rate of revocation, the average CRL partition would have 150 entries, or
around 3.7kB.  This is twice as large as the actual OCSP responses returned
by the DoD today, and the upper bound on a CRL partition size is
significantly larger.

It's important to note that any CRL partitioning is fixed for the entire
lifetime of the certs ... you can't change your tuning later to improve
bandwidth to the client or (inversely) the aggregate size and number of
segments to replicate.  An OCSP deployment can be tuned independently long
after cert issuance based on the operational usage characteristics.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kemp David P.
Sent: Tuesday, September 19, 2006 10:22 AM
To: Christine Karman; [email-masked]
Subject: RE: large crl's

...

One difference is size.  For any given number of certificates, an OCSP
response is significantly *larger* than a CRL!  An OCSP message is about 350
bytes body + 79/unrevoked cert + 101/revoked cert.  A CRL, in contrast, is
about 200 bytes body + 0/unrevoked cert + 30/revoked cert.
(both modulo assumptions on DN size, serial number size, signature size, use
of extensions, etc).  

...

If a 1% revocation rate doesn't reflect your subscriber base, then assume
40% of certificates are revoked, yielding the following CRL and OCSP sizes:

Certs/   40% revoked
query    CRL    OCSP
   1     212     438
   2     224     526
   5     260     789
  10     320   1,228
  20     440   2,106
  50     800   4,740
 100   1,400   9,130
 200   2,600  17,910
 500   6,200  44,250
1000  12,200  88,150

What does this mean, since nobody does an OCSP query on 1000 certs?  It
means that if you set some threshold on the acceptable size for a
certificate status message, a CRL can represent the status of many more
certificates than an OCSP response.  If 500 bytes is your limit, that would
be an OCSP response for 2 certs, or a partitioned CRL covering 20 certs.  If
2K bytes is your limit, that would accommodate an OCSP response for 20
certs, or a CRL covering a 150-cert partition.

Another way of looking at it would be to assume that a company needs to
store revocation status for email messages of its 10,000 employees.  If it
stored 10 partitioned CRLs, that would require 122 KB.  If instead it stored
10,000 OCSP responses, that would require 4,380 KB for the same set of
employees.

The point of the above is that it is incorrect to assume that "online
verification" means only "OCSP", and even more incorrect to assume that
because one organization has done a horrible job of engineering its CRLs,
the fault lies with the CRLs themselves.

------=_NextPart_000_00DE_01C6DC14.0D68B3A0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_00DE_01C6DC14.0D68B3A0--

Date: Tue, 19 Sep 2006 17:13:58 -0400
From: "David A. Cooper" <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: Stephen Farrell <[email-masked]>, [email-masked]
Subject: Re: 3280-bis AIA update
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">
Anders,<br>
<br>
I agree that the language in RFC 3280 was confusing.&nbsp; I would suggest
that you read section 4.2.2.1 of 3280bis, since you may find that the
changes you seek have already been made.&nbsp; If you look at
<a class="moz-txt-link-freetext" href="http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-02_diff.html">http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-02_diff.html</a>
you will see a version of draft 2 of 3280bis in which all changes from
RFC 3280 are highlighted.&nbsp;&nbsp; The current draft of 3280bis is draft 4
(<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-04.txt">http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-04.txt</a>),
but section 4.2.2.1 has been practically unchanged since draft 2 (a
couple of typographical errors were fixed and a few references to
updated to newer RFCs).<br>
<br>
Dave<br>
<br>
Anders Rundgren wrote:
<blockquote cite="mid03c601c6dc14$b4a310c0$82c5a8c0@arport2v"
 type="cite">
  <pre wrap="">At this stage I would be happy to know if my interpretation [*]
of the AIA extension is correct or not.   IF my interpretation
is correct, Dave's job ought to be verifying my claim that the
defintion is in conflict with the current practice for FIPS201 CAs.
IF this also is verified, the issue is what to do next.

Anders

*]

RFC3280: the additional information lists CAs that have issued certificates
*superior* to the CA that issued the certificate containing this extension

                     &lt;&gt;

Practice: the additional information lists CAs that have issued certificates
*including* the CA that issued the certificate containing this extension

----- Original Message ----- 
From: "Stephen Farrell" <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
To: "Anders Rundgren" <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Cc: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Sent: Tuesday, September 19, 2006 18:06
Subject: Re: 3280-bis AIA update

Anders,

If you could propose text for inclusion that'd make the Dave's
editing job much easier, if there is consensus to make whatever
change you propose.

I'm not being picky, its just not clear to me what change you'd
like,

Stephen.

Anders Rundgren wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">A quick survey among existing CAs show that they indeed
do not return the CA cert that is "superior" to the CA that
issued the EE cert containing the AIA extension, but rather
[the only reasonable,] the CA cert that issued the EE cert.

Maybe 3280-bis should be updated to reflect the actual
implementation of the AIA caIssuers extension?

An off-list message verified that several FIPS201 implementations
in the workings rely on a revised AIA caIssuers definition.

I also believe that the following text is not entirely appropriate:

  "The referenced CA issuers description is intended to aid
   certificate users in the selection of  a certification path"

The "description" is a list of certificates isn't it?
What is a "certificate user"?  It includes "applications" like
TLS-client-authentication as well I guess?

BTW, it would not hurt to add a few lines about how a list of CA
certificates should be packaged including references to applicable RFCs.

Anders

----- Original Message ----- 
From: "Anders Rundgren" <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
To: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Sent: Thursday, September 14, 2006 23:32
Subject: AIA - No Issuing CA support?

RFC 3280   
   "The id-ad-caIssuers OID is used when the additional information lists
   CAs that have issued certificates *superior* to the CA that issued the
   certificate containing this extension.  The referenced CA issuers
   description is intended to aid certificate users in the selection of
   a certification path that terminates at a point trusted by the
   certificate user"

Assume I have a FIPS201 card (that as far as I can tell do not contain
any CA certificates at all), how can I locate the actual issuing CA?

Anders

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

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

Content-Class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Tue, 19 Sep 2006 14:12:56 -0700
From: Ryan Hurst <[email-masked]>
To: Santosh Chokhani <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Santosh - I think there are numerous benefits, for example:
1. Pre-IP scenarios that have the CRL but not the intermediates; more
likely in indirect cases.
2. Post-IP scenarios where all the intermediates and trust anchors' are
there except the indirect certificate so chain discovery must go online
to complete discovery; more likely in indirect cases.
3. Post-IP scenarios where no intermediates are present and the
implementing chain validation API must return in a specific time and the
allotted time is already used through other discovery and validation
phases, additional wire retrievals introduce more latency and should be
avoided if possible.

These are just a few off the top of my head, I am sure Stefan has
others.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Tuesday, September 19, 2006 12:28 PM
To: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Ryan,

Can you explain why "without having to go on the wire" makes sense?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan Hurst
Sent: Tuesday, September 19, 2006 2:21 PM
To: Russ Housley; Jean-Marc Desperrier; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

I was not personally suggesting the CRL carry a P7C but instead that a
certificate provide a pointer to a p7c that contains both the CRL and
the certificates that are necessary to validate it this way a
implementation that supported this model could choose this form of CRL
vs the traditional form.

However after speaking with Stefan I think we both better understand
each other's scenarios and I now agree with Stefan, supporting a mode
where a CRL contains sufficient information to kick of validation and
then discovery for indirect CRL cases without having to go on the wire
makes sense.

By scoping the inclusion of this proposed extension to indirect crls
associated with CAs you mitigate the performance and file size problems
that I was concerned with while still enabling solving the problem
Stefan calls out.

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Monday, September 18, 2006 8:46 AM
To: Jean-Marc Desperrier; [email-masked]
Subject: Re: Certs in CRLs - New standards task?

I support the idea of carrying a bag 'o certs.  However, I am not use 
what value is added by carrying a p7c.  It seems to be a heavy weight 
way to say SEQUENCE OF Certificate.

What am I missing?

Russ

At 09:21 AM 9/18/2006, Jean-Marc Desperrier wrote:

>Ryan Hurst wrote:
>>Have you considered the idea of introducing a new access method to the
>>AIA that would point to a P7c that possibly contained the CRL, its
>>issuers and maybe the certificates issuers?
>>
>I vote for p7c. Most CAs already include an option to distribute CRL
this way.
>
>After reading  RFC 2585, I think it misses something  by not saying 
>a word about the popular option of distributing crl and certificates 
>inside pkcs#7/CMS bags.
>
>When RFC 3280bis says that URIs inside a DistributionPointName must 
>point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it just
>making explicit a rule that was already required for proper
interoperability ?

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Tue, 19 Sep 2006 12:28:29 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Ryan,

Can you explain why "without having to go on the wire" makes sense?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan Hurst
Sent: Tuesday, September 19, 2006 2:21 PM
To: Russ Housley; Jean-Marc Desperrier; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

I was not personally suggesting the CRL carry a P7C but instead that a
certificate provide a pointer to a p7c that contains both the CRL and
the certificates that are necessary to validate it this way a
implementation that supported this model could choose this form of CRL
vs the traditional form.

However after speaking with Stefan I think we both better understand
each other's scenarios and I now agree with Stefan, supporting a mode
where a CRL contains sufficient information to kick of validation and
then discovery for indirect CRL cases without having to go on the wire
makes sense.

By scoping the inclusion of this proposed extension to indirect crls
associated with CAs you mitigate the performance and file size problems
that I was concerned with while still enabling solving the problem
Stefan calls out.

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Monday, September 18, 2006 8:46 AM
To: Jean-Marc Desperrier; [email-masked]
Subject: Re: Certs in CRLs - New standards task?

I support the idea of carrying a bag 'o certs.  However, I am not use 
what value is added by carrying a p7c.  It seems to be a heavy weight 
way to say SEQUENCE OF Certificate.

What am I missing?

Russ

At 09:21 AM 9/18/2006, Jean-Marc Desperrier wrote:

>Ryan Hurst wrote:
>>Have you considered the idea of introducing a new access method to the
>>AIA that would point to a P7c that possibly contained the CRL, its
>>issuers and maybe the certificates issuers?
>>
>I vote for p7c. Most CAs already include an option to distribute CRL
this way.
>
>After reading  RFC 2585, I think it misses something  by not saying 
>a word about the popular option of distributing crl and certificates 
>inside pkcs#7/CMS bags.
>
>When RFC 3280bis says that URIs inside a DistributionPointName must 
>point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it just
>making explicit a rule that was already required for proper
interoperability ?

Date: Tue, 19 Sep 2006 19:38:47 +0100
From: Stephen Farrell <[email-masked]>
To: Sharon Boeyen <[email-masked]>
CC: [email-masked]
Subject: Re: Certs in CRLs - New standards task?
Sender: [email-masked]

I'm not sure myself. But I would like to see an individual I-D
before the WG adopted a work item.

S.

Sharon Boeyen wrote:
> The more I think about this the more I dislike the approach of including 
> certs in the CRL. There are currently implementations that are able to 
> find all the paths they need with the current information in the CRL (by 
> using the DN to do a directory lookup). I recognize this isn't always 
> the simplest way to find information and I do support pointer schemes 
> such as AIA and SIA or another pointer approach. However I really don't 
> want to see the size of CRLs increased in the way they would be even if 
> a single cert was added, whether that be for indirect CRLs, CA key 
> rollovers or any other case.
> 
> Stefan, its fine for you to say that implementers wouldn't need to 
> support the new extension, however as soon as a CA starts putting it in 
> there is an impact on all implementations because of the size of the CRL 
> (regardless of whether an implementation decides to process or ignore 
> the non-critical extension).
> 
> Cheers,
> Sharon
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Julien Stern
> Sent: Tuesday, September 19, 2006 5:15 AM
> To: [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
> 
> 
> On Mon, Sep 18, 2006 at 04:41:29PM +0100, Stefan Santesson wrote:
>  > Denis,
>  >
>  > When this is not a good solution to your problem, then don't use it.
>  >
>  > Why MUST is be bad to send the certs with every CRL if the alternative
>  > is to go out on the network and fetch the certificates using extra
>  > cycles.
>  >
>  > I may use the same CRL 100+ times before it expires for many different
>  > certificates. We send certificates with every OCSP response and we
>  > don't consider that a problem.
> 
> Stefan,
> 
> if I may jump in. Sometimes, it IS a problem to send certificates with 
> OCSP responses. We have at least one example where we will have to use 
> OCSP responses without certificates due to size contraints.
> 
> Admitelly, this case is rare, but there are scenarios where OCSP or CRL 
> size matters :)
> 
> What would you think of having a standard way to request (and send) the 
> certificate(s) associated to a CRL without bundling them.
> 
> One example (probably not the best but...) could be
> 
> http://www.xxx.com/thecrl.der  --> Gives the bare CRL 
> http://www.xxx.com/thecrl.der?addcert  --> Gives the certificate, 
> followed by the bare CRL (so that you can stream).
> 
> Regards,
> 
> -- 
> Julien
>  
>  > Stefan Santesson
>  >
>  > Senior Program Manager
>  >
>  > Windows Security, Standards
>  >
>  > From: [email-masked]
>  > [mailto:[email-masked]]
>  > On Behalf Of Denis Pinkas
>  > Sent: den 18 september 2006 06:10
>  > To: [email-masked]
>  > Subject: Re: Certs in CRLs - New standards task?
>  >
>  > 
>  >
>  > ________________________________
>  >
>  > Stefan,
>  >
>  > My replies have [Denis] in front of them.
>  >
>  > Hi Denis,
>  >
>  > Speaking as an implementer and from the experience from how our own
>  > products work, the issue and the solution is much more simple than the
>  > solution you propose.
>  >
>  >  The  validation engine does not need to know which certificate that
>  > represents the old or the new CA key or what the hash of the
>  > certificate is. The task of the validation engine for this issue is
>  > simply to validate the signature of the CRL using a valid path to a
>  > trusted root (being the same used to validate the target certificate).
>  >
>  > [Denis]  I disagree. Before the "validation engine" there is the "path
>  > construction engine". Depending upon whether key rollover has been or
>  > has not been performed by the relying party, one or two certificates
>  > may be needed. If the CRL issuer is servings multiple CAs, then a
>  > couple of certificates are needed for each CA. If we define a new
>  > extension, it MUST also be usable for a single CRL issued for
>  > different CAs.
>  >
>  > First of all the validation engine will try to build a path using all
>  > certs from the validated path and all cashed and locally stored
>  > certificates and root keys. If this fails it could use the certs
>  > provided in the CRL using this new extension (just a bag of
>  > certificates with no specific information).
>  >
>  > [Denis] Ahhhhh! you just crossed the line: a bag of certificates !
>  >
>  >  In the end, if the provided bag of certificates (typically only 1
>  > certificate if present) does not help the RP, we did not do any
>  > particular damage to the RP (just slightly increased the CRL), we just
>  > couldn't help him and he will now have to try directory search etc as
>  > before. But the fact is that by including certificate/s in the CRL we
>  > may in many PKI configurations considerably help the RP.
>  >
>  > [Denis] You will need to transfer that bag of certificates every time.
>  > This is not good. Instead of trying to convince that the initially
>  > proposed solution is the best, please take some time to consider the
>  > benefits and drawbacks of the other solution I proposed.
>  >
>  > I fully agree that this information can not be stored in an AIA. A new
>  > CRL extension is needed.
>  >
>  > Finally I don't agree to the term "overloading" here. We usually use
>  > that term to describe when we stretch the semantics of existing fields
>  > and name forms. This is just an new optional non-critical extension
>  > with useful data, relevant to the processing of the CRL.
>  >
>  > Denis
>  >
>  > 
>  >
>  > 
>  >
>  > Stefan Santesson
>  >
>  > Senior Program Manager
>  >
>  > Windows Security, Standards
>  >
>  > From: [email-masked]
>  > [mailto:[email-masked]]
>  > On Behalf Of Denis Pinkas
>  > Sent: den 18 september 2006 00:51
>  > To: [email-masked]
>  > Subject: Re: Certs in CRLs - New standards task?
>  >
>  > 
>  >
>  > Stefan,
>  >
>  > 
>  >
>  > I am not in favour of the proposed approach.
>  >
>  > 
>  >
>  > I have concern by always overloading the CRL, not simply with one
>  > additional certificate,
>  >
>  > but with two additional certificates, because of CA key rollover.
>  >
>  > 
>  >
>  > The situation will be even worse when a CRL issuer is trusted by more
>  > than one CA
>  >
>  > to issue CRLs.
>  >
>  > 
>  >
>  > Talking to you in your capacity of co-chair, I would like to recall
>  > that the full story
>  >
>  > of how to check a CRL that is not issued by a CA is still not crystal
>  > clear in 3280bis,
>  >
>  > and we should clarify that before. :-)
>  >
>  > 
>  >
>  > Talking to you as PKIX member, I would favor the use of  one extension
>  > with two pointers per CA:
>  >
>  > 
>  >
>  >  - one pointing to the current or old certificate still valid, and
>  >
>  >  - another one pointing the new or current certificate already valid.
>  >
>  > 
>  >
>  > This will allow to fetch once the certificate(s) that is/are needed.
>  >
>  > 
>  >
>  > The AIA extension is not the right vehicule, since it cannot include a
>  > hash of the data that is pointed.
>  >
>  > We should add a hash of the certificate, which would allow to make
>  > sure that the right certificate
>  >
>  > was obtained without the need to build and verify the certification
>  > path.
>  >
>  > 
>  >
>  > >From the above observations, the problem is much more complex than
>  > originally presented.
>  >
>  > 
>  >
>  > Denis
>  >
>  > 
>  >
>  > ________________________________
>  >
>  > Taking the pkix chair hat off and the vendor hat on
>  >
>  > I'm asking this group to consider a new standards task to solve a real
>  > implementation issue with indirect CRLs and CRLs issued by a re-keyed
>  > CA. I.e. where the target certificate and it's CRL are signed by
>  > different keys and the RP does not have access to the CRL Issuer
>  > certificate.
>  >
>  > It is basically the same situation we solved with allowing the AIA
>  > extension in CRL's namely the problem to obtain the CRL issuer's
>  > certificate, alternatively, certificate path.
>  >
>  > In our efforts to implement the AIA solution we have encountered some
>  > real issues.
>  >
>  > 1)       Each time we are forced to go out and retrieve new information
>  > on the network, we have a source of potential problems such as
>  > unavailable network resources, timeouts etc. It all adds to the
>  > validation time and harms the user experience.
>  >
>  > 2)       The AIA in CRL's provide another opening for DoS attacks if
>  > rouge CRL's point their AIA to a targeted web server. This is tough
>  > not as serious as the DoS problems with AIA in certificates, but this
>  > one we might avoid more easily.
>  >
>  >  The proposed solution is to define a new CRL extension that may
>  > contain the CRL Issuer certificate (not just a URL to its location).
>  > Preferably this would be a PKCS#7 (or CMS) Certs only message that may
>  > contain a single certificate or a bag of certificates (a chain).
>  >
>  >  While it wouldn't be attractive to define such extension for
>  > certificates due to certificate size considerations, CRL's are often
>  > of such size that including the certs needed to validate it only leads
>  > to an insignificant increase of size, while it may offer substantial
>  > processing advantages.
>  >
>  >  I would like to hear the opinion of this group on this.
>  >
>  >  I volunteer to write a first draft if there is interest from the
>  > group.
>  >
>  > 
>  >
>  > Stefan Santesson
>  >
>  > Senior Program Manager
>  >
>  > Windows Security, Standards
>  >
>  > 
>  >
>  > ________________________________
>  >
>  > ________________________________
>  >
> 

Content-Class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Tue, 19 Sep 2006 11:20:58 -0700
From: Ryan Hurst <[email-masked]>
To: Russ Housley <[email-masked]>, Jean-Marc Desperrier <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I was not personally suggesting the CRL carry a P7C but instead that a
certificate provide a pointer to a p7c that contains both the CRL and
the certificates that are necessary to validate it this way a
implementation that supported this model could choose this form of CRL
vs the traditional form.

However after speaking with Stefan I think we both better understand
each other's scenarios and I now agree with Stefan, supporting a mode
where a CRL contains sufficient information to kick of validation and
then discovery for indirect CRL cases without having to go on the wire
makes sense.

By scoping the inclusion of this proposed extension to indirect crls
associated with CAs you mitigate the performance and file size problems
that I was concerned with while still enabling solving the problem
Stefan calls out.

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Monday, September 18, 2006 8:46 AM
To: Jean-Marc Desperrier; [email-masked]
Subject: Re: Certs in CRLs - New standards task?

I support the idea of carrying a bag 'o certs.  However, I am not use 
what value is added by carrying a p7c.  It seems to be a heavy weight 
way to say SEQUENCE OF Certificate.

What am I missing?

Russ

At 09:21 AM 9/18/2006, Jean-Marc Desperrier wrote:

>Ryan Hurst wrote:
>>Have you considered the idea of introducing a new access method to the
>>AIA that would point to a P7c that possibly contained the CRL, its
>>issuers and maybe the certificates issuers?
>>
>I vote for p7c. Most CAs already include an option to distribute CRL
this way.
>
>After reading  RFC 2585, I think it misses something  by not saying 
>a word about the popular option of distributing crl and certificates 
>inside pkcs#7/CMS bags.
>
>When RFC 3280bis says that URIs inside a DistributionPointName must 
>point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it just
>making explicit a rule that was already required for proper
interoperability ?

From: "Anders Rundgren" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: 3280-bis AIA update
Date: Tue, 19 Sep 2006 19:54:51 +0200
Sender: [email-masked]

At this stage I would be happy to know if my interpretation [*]
of the AIA extension is correct or not.   IF my interpretation
is correct, Dave's job ought to be verifying my claim that the
defintion is in conflict with the current practice for FIPS201 CAs.
IF this also is verified, the issue is what to do next.

Anders

*]

RFC3280: the additional information lists CAs that have issued certificates
*superior* to the CA that issued the certificate containing this extension

                     <>

Practice: the additional information lists CAs that have issued certificates
*including* the CA that issued the certificate containing this extension

----- Original Message ----- 
From: "Stephen Farrell" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 19, 2006 18:06
Subject: Re: 3280-bis AIA update

Anders,

If you could propose text for inclusion that'd make the Dave's
editing job much easier, if there is consensus to make whatever
change you propose.

I'm not being picky, its just not clear to me what change you'd
like,

Stephen.

Anders Rundgren wrote:
> A quick survey among existing CAs show that they indeed
> do not return the CA cert that is "superior" to the CA that
> issued the EE cert containing the AIA extension, but rather
> [the only reasonable,] the CA cert that issued the EE cert.
> 
> Maybe 3280-bis should be updated to reflect the actual
> implementation of the AIA caIssuers extension?
> 
> An off-list message verified that several FIPS201 implementations
> in the workings rely on a revised AIA caIssuers definition.
> 
> I also believe that the following text is not entirely appropriate:
> 
>   "The referenced CA issuers description is intended to aid
>    certificate users in the selection of  a certification path"
> 
> The "description" is a list of certificates isn't it?
> What is a "certificate user"?  It includes "applications" like
> TLS-client-authentication as well I guess?
> 
> BTW, it would not hurt to add a few lines about how a list of CA
> certificates should be packaged including references to applicable RFCs.
> 
> Anders
> 
> From: "Anders Rundgren" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, September 14, 2006 23:32
> Subject: AIA - No Issuing CA support?
> 
> 
> 
> RFC 3280   
>    "The id-ad-caIssuers OID is used when the additional information lists
>    CAs that have issued certificates *superior* to the CA that issued the
>    certificate containing this extension.  The referenced CA issuers
>    description is intended to aid certificate users in the selection of
>    a certification path that terminates at a point trusted by the
>    certificate user"
> 
> Assume I have a FIPS201 card (that as far as I can tell do not contain
> any CA certificates at all), how can I locate the actual issuing CA?
> 
> Anders
> 
> 
> 
> 

Date: Tue, 19 Sep 2006 17:06:46 +0100
From: Stephen Farrell <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: 3280-bis AIA update
Sender: [email-masked]

Anders,

If you could propose text for inclusion that'd make the Dave's
editing job much easier, if there is consensus to make whatever
change you propose.

I'm not being picky, its just not clear to me what change you'd
like,

Stephen.

Anders Rundgren wrote:
> A quick survey among existing CAs show that they indeed
> do not return the CA cert that is "superior" to the CA that
> issued the EE cert containing the AIA extension, but rather
> [the only reasonable,] the CA cert that issued the EE cert.
> 
> Maybe 3280-bis should be updated to reflect the actual
> implementation of the AIA caIssuers extension?
> 
> An off-list message verified that several FIPS201 implementations
> in the workings rely on a revised AIA caIssuers definition.
> 
> I also believe that the following text is not entirely appropriate:
> 
>   "The referenced CA issuers description is intended to aid
>    certificate users in the selection of  a certification path"
> 
> The "description" is a list of certificates isn't it?
> What is a "certificate user"?  It includes "applications" like
> TLS-client-authentication as well I guess?
> 
> BTW, it would not hurt to add a few lines about how a list of CA
> certificates should be packaged including references to applicable RFCs.
> 
> Anders
> 
> From: "Anders Rundgren" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, September 14, 2006 23:32
> Subject: AIA - No Issuing CA support?
> 
> 
> 
> RFC 3280   
>    "The id-ad-caIssuers OID is used when the additional information lists
>    CAs that have issued certificates *superior* to the CA that issued the
>    certificate containing this extension.  The referenced CA issuers
>    description is intended to aid certificate users in the selection of
>    a certification path that terminates at a point trusted by the
>    certificate user"
> 
> Assume I have a FIPS201 card (that as far as I can tell do not contain
> any CA certificates at all), how can I locate the actual issuing CA?
> 
> Anders
> 
> 
> 
> 

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: 3280-bis AIA update
Date: Tue, 19 Sep 2006 16:53:28 +0200
Sender: [email-masked]

A quick survey among existing CAs show that they indeed
do not return the CA cert that is "superior" to the CA that
issued the EE cert containing the AIA extension, but rather
[the only reasonable,] the CA cert that issued the EE cert.

Maybe 3280-bis should be updated to reflect the actual
implementation of the AIA caIssuers extension?

An off-list message verified that several FIPS201 implementations
in the workings rely on a revised AIA caIssuers definition.

I also believe that the following text is not entirely appropriate:

  "The referenced CA issuers description is intended to aid
   certificate users in the selection of  a certification path"

The "description" is a list of certificates isn't it?
What is a "certificate user"?  It includes "applications" like
TLS-client-authentication as well I guess?

BTW, it would not hurt to add a few lines about how a list of CA
certificates should be packaged including references to applicable RFCs.

Anders

----- Original Message ----- 
From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 14, 2006 23:32
Subject: AIA - No Issuing CA support?

RFC 3280   
   "The id-ad-caIssuers OID is used when the additional information lists
   CAs that have issued certificates *superior* to the CA that issued the
   certificate containing this extension.  The referenced CA issuers
   description is intended to aid certificate users in the selection of
   a certification path that terminates at a point trusted by the
   certificate user"

Assume I have a FIPS201 card (that as far as I can tell do not contain
any CA certificates at all), how can I locate the actual issuing CA?

Anders

Content-class: urn:content-classes:message
Subject: RE: large crl's
Date: Tue, 19 Sep 2006 10:21:39 -0400
From: "Kemp David P." <[email-masked]>
To: "Christine Karman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Al Arsenault already discussed good and bad engineering solutions,
but the following suggests some elaboration:

> [ck] Another difference between authentication in a browser
> and email is the following. A company archives old email.
> They have to be able to verify validity of digital signatures
> on incoming email, even for certificates that have expired
> long ago. The DOD will have to have that 20Mb crl available
> forever, unless they switch to online verification.

What does "online verification" mean: a mechanism to
query for certificate status and receive an answer?  If so,
then what is the difference between receiving the answer in
the form of a signed OCSP response or a signed partitioned CRL?

One difference is size.  For any given number of certificates,
an OCSP response is significantly *larger* than a CRL!  An
OCSP message is about 350 bytes body + 79/unrevoked
cert + 101/revoked cert.  A CRL, in contrast, is about
200 bytes body + 0/unrevoked cert + 30/revoked cert.
(both modulo assumptions on DN size, serial number
size, signature size, use of extensions, etc).  

Assuming 1% of certificates are revoked, the size of a
CRL and an OCSP response for a given number of certificates
per CRL partition or OCSP query is:

Certs/   1% revoked
query    CRL    OCSP
   1     200     429
   2     201     508
   5     202     746
  10     203   1,142
  20     206   1,934
  50     215   4,311
 100     230   8,272
 200     260  16,194
 500     350  39,960
1000     500  79,570

If a 1% revocation rate doesn't reflect your subscriber
base, then assume 40% of certificates are revoked, yielding
the following CRL and OCSP sizes:

Certs/   40% revoked
query    CRL    OCSP
   1     212     438
   2     224     526
   5     260     789
  10     320   1,228
  20     440   2,106
  50     800   4,740
 100   1,400   9,130
 200   2,600  17,910
 500   6,200  44,250
1000  12,200  88,150

What does this mean, since nobody does an OCSP query
on 1000 certs?  It means that if you set some threshold
on the acceptable size for a certificate status message,
a CRL can represent the status of many more certificates
than an OCSP response.  If 500 bytes is your limit, that
would be an OCSP response for 2 certs, or a partitioned
CRL covering 20 certs.  If 2K bytes is your limit, that
would accommodate an OCSP response for 20 certs, or a
CRL covering a 150-cert partition.

Another way of looking at it would be to assume that
a company needs to store revocation status for email
messages of its 10,000 employees.  If it stored 10
partitioned CRLs, that would require 122 KB.  If instead
it stored 10,000 OCSP responses, that would require
4,380 KB for the same set of employees.

The point of the above is that it is incorrect to assume
that "online verification" means only "OCSP", and even more
incorrect to assume that because one organization has
done a horrible job of engineering its CRLs, the
fault lies with the CRLs themselves.

Date: Tue, 19 Sep 2006 16:16:39 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Certs in CRLs - New standards task?
Sender: [email-masked]

This is a multi-part message in MIME format.

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

I support Sharon's position.

Denis

The more I think about this the more I dislike the approach of including certs in the CRL. There are currently implementations that are able to find all the paths they need with the current information in the CRL (by using the DN to do a directory lookup). I recognize this isn't always the simplest way to find information and I do support pointer schemes such as AIA and SIA or another pointer approach. However I really don't want to see the size of CRLs increased in the way they would be even if a single cert was added, whether that be for indirect CRLs, CA key rollovers or any other case. 
Stefan, its fine for you to say that implementers wouldn't need to support the new extension, however as soon as a CA starts putting it in there is an impact on all implementations because of the size of the CRL (regardless of whether an implementation decides to process or ignore the non-critical extension). 
Cheers, 
Sharon 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Stern 
Sent: Tuesday, September 19, 2006 5:15 AM 
To: [email-masked] 
Subject: Re: Certs in CRLs - New standards task? 

On Mon, Sep 18, 2006 at 04:41:29PM +0100, Stefan Santesson wrote: 
> Denis, 
> 
> When this is not a good solution to your problem, then don't use it. 
> 
> Why MUST is be bad to send the certs with every CRL if the alternative 
> is to go out on the network and fetch the certificates using extra 
> cycles. 
> 
> I may use the same CRL 100+ times before it expires for many different 
> certificates. We send certificates with every OCSP response and we 
> don't consider that a problem. 
Stefan, 
if I may jump in. Sometimes, it IS a problem to send certificates with OCSP responses. We have at least one example where we will have to use OCSP responses without certificates due to size contraints.
Admitelly, this case is rare, but there are scenarios where OCSP or CRL size matters :) 
What would you think of having a standard way to request (and send) the certificate(s) associated to a CRL without bundling them.
One example (probably not the best but...) could be 
http://www.xxx.com/thecrl.der  --> Gives the bare CRL http://www.xxx.com/thecrl.der?addcert  --> Gives the certificate, followed by the bare CRL (so that you can stream).
Regards, 
-- 
Julien 
  
> Stefan Santesson 
> 
> Senior Program Manager 
> 
> Windows Security, Standards 
> 
> From: [email-masked] 
> [mailto:[email-masked]] 
> On Behalf Of Denis Pinkas 
> Sent: den 18 september 2006 06:10 
> To: [email-masked] 
> Subject: Re: Certs in CRLs - New standards task? 
> 
>  
> 
> ________________________________ 
> 
> Stefan, 
> 
> My replies have [Denis] in front of them. 
> 
> Hi Denis, 
> 
> Speaking as an implementer and from the experience from how our own 
> products work, the issue and the solution is much more simple than the 
> solution you propose. 
> 
>  The  validation engine does not need to know which certificate that 
> represents the old or the new CA key or what the hash of the 
> certificate is. The task of the validation engine for this issue is 
> simply to validate the signature of the CRL using a valid path to a 
> trusted root (being the same used to validate the target certificate). 
> 
> [Denis]  I disagree. Before the "validation engine" there is the "path 
> construction engine". Depending upon whether key rollover has been or 
> has not been performed by the relying party, one or two certificates 
> may be needed. If the CRL issuer is servings multiple CAs, then a 
> couple of certificates are needed for each CA. If we define a new 
> extension, it MUST also be usable for a single CRL issued for 
> different CAs. 
> 
> First of all the validation engine will try to build a path using all 
> certs from the validated path and all cashed and locally stored 
> certificates and root keys. If this fails it could use the certs 
> provided in the CRL using this new extension (just a bag of 
> certificates with no specific information). 
> 
> [Denis] Ahhhhh! you just crossed the line: a bag of certificates ! 
> 
>  In the end, if the provided bag of certificates (typically only 1 
> certificate if present) does not help the RP, we did not do any 
> particular damage to the RP (just slightly increased the CRL), we just 
> couldn't help him and he will now have to try directory search etc as 
> before. But the fact is that by including certificate/s in the CRL we 
> may in many PKI configurations considerably help the RP. 
> 
> [Denis] You will need to transfer that bag of certificates every time. 
> This is not good. Instead of trying to convince that the initially 
> proposed solution is the best, please take some time to consider the 
> benefits and drawbacks of the other solution I proposed. 
> 
> I fully agree that this information can not be stored in an AIA. A new 
> CRL extension is needed. 
> 
> Finally I don't agree to the term "overloading" here. We usually use 
> that term to describe when we stretch the semantics of existing fields 
> and name forms. This is just an new optional non-critical extension 
> with useful data, relevant to the processing of the CRL. 
> 
> Denis 
> 
>  
> 
>  
> 
> Stefan Santesson 
> 
> Senior Program Manager 
> 
> Windows Security, Standards 
> 
> From: [email-masked] 
> [mailto:[email-masked]] 
> On Behalf Of Denis Pinkas 
> Sent: den 18 september 2006 00:51 
> To: [email-masked] 
> Subject: Re: Certs in CRLs - New standards task? 
> 
>  
> 
> Stefan, 
> 
>  
> 
> I am not in favour of the proposed approach. 
> 
>  
> 
> I have concern by always overloading the CRL, not simply with one 
> additional certificate, 
> 
> but with two additional certificates, because of CA key rollover. 
> 
>  
> 
> The situation will be even worse when a CRL issuer is trusted by more 
> than one CA 
> 
> to issue CRLs. 
> 
>  
> 
> Talking to you in your capacity of co-chair, I would like to recall 
> that the full story 
> 
> of how to check a CRL that is not issued by a CA is still not crystal 
> clear in 3280bis, 
> 
> and we should clarify that before. :-) 
> 
>  
> 
> Talking to you as PKIX member, I would favor the use of  one extension 
> with two pointers per CA: 
> 
>  
> 
>  - one pointing to the current or old certificate still valid, and 
> 
>  - another one pointing the new or current certificate already valid. 
> 
>  
> 
> This will allow to fetch once the certificate(s) that is/are needed. 
> 
>  
> 
> The AIA extension is not the right vehicule, since it cannot include a 
> hash of the data that is pointed. 
> 
> We should add a hash of the certificate, which would allow to make 
> sure that the right certificate 
> 
> was obtained without the need to build and verify the certification 
> path. 
> 
>  
> 
> >From the above observations, the problem is much more complex than 
> originally presented. 
> 
>  
> 
> Denis 
> 
>  
> 
> ________________________________ 
> 
> Taking the pkix chair hat off and the vendor hat on 
> 
> I'm asking this group to consider a new standards task to solve a real 
> implementation issue with indirect CRLs and CRLs issued by a re-keyed 
> CA. I.e. where the target certificate and it's CRL are signed by 
> different keys and the RP does not have access to the CRL Issuer 
> certificate. 
> 
> It is basically the same situation we solved with allowing the AIA 
> extension in CRL's namely the problem to obtain the CRL issuer's 
> certificate, alternatively, certificate path. 
> 
> In our efforts to implement the AIA solution we have encountered some 
> real issues. 
> 
> 1)       Each time we are forced to go out and retrieve new information 
> on the network, we have a source of potential problems such as 
> unavailable network resources, timeouts etc. It all adds to the 
> validation time and harms the user experience. 
> 
> 2)       The AIA in CRL's provide another opening for DoS attacks if 
> rouge CRL's point their AIA to a targeted web server. This is tough 
> not as serious as the DoS problems with AIA in certificates, but this 
> one we might avoid more easily. 
> 
>  The proposed solution is to define a new CRL extension that may 
> contain the CRL Issuer certificate (not just a URL to its location). 
> Preferably this would be a PKCS#7 (or CMS) Certs only message that may 
> contain a single certificate or a bag of certificates (a chain). 
> 
>  While it wouldn't be attractive to define such extension for 
> certificates due to certificate size considerations, CRL's are often 
> of such size that including the certs needed to validate it only leads 
> to an insignificant increase of size, while it may offer substantial 
> processing advantages. 
> 
>  I would like to hear the opinion of this group on this. 
> 
>  I volunteer to write a first draft if there is interest from the 
> group. 
> 
>  
> 
> Stefan Santesson 
> 
> Senior Program Manager 
> 
> Windows Security, Standards 
> 
>  
> 
> ________________________________ 
> 
> ________________________________ 
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1528" name=GENERATOR></HEAD>
<BODY>
<DIV>I support Sharon's position.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
</DIV>
<P><FONT size=2>The more I think about this the more I dislike the approach of 
including certs in the CRL. There are currently implementations that are able to 
find all the paths they need with the current information in the CRL (by using 
the DN to do a directory lookup). I recognize this isn't always the simplest way 
to find information and I do support pointer schemes such as AIA and SIA or 
another pointer approach. However I really don't want to see the size of CRLs 
increased in the way they would be even if a single cert was added, whether that 
be for indirect CRLs, CA key rollovers or any other case. </FONT></P>
<P><FONT size=2>Stefan, its fine for you to say that implementers wouldn't need 
to support the new extension, however as soon as a CA starts putting it in there 
is an impact on all implementations because of the size of the CRL (regardless 
of whether an implementation decides to process or ignore the non-critical 
extension). </FONT></P>
<P><FONT size=2>Cheers,</FONT> <BR><FONT size=2>Sharon</FONT> </P>
<P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
[email-masked] [<A 
href="mailto:[email-masked]">mailto:[email-masked]</A>] 
On Behalf Of Julien Stern</FONT> <BR><FONT size=2>Sent: Tuesday, September 19, 
2006 5:15 AM</FONT> <BR><FONT size=2>To: [email-masked]</FONT> <BR><FONT 
size=2>Subject: Re: Certs in CRLs - New standards task?</FONT> </P><BR><BR>
<P><FONT size=2>On Mon, Sep 18, 2006 at 04:41:29PM +0100, Stefan Santesson 
wrote:</FONT> <BR><FONT size=2>&gt; Denis,</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; When this is not a good solution to your problem, 
then don't use it.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Why 
MUST is be bad to send the certs with every CRL if the alternative 
</FONT><BR><FONT size=2>&gt; is to go out on the network and fetch the 
certificates using extra </FONT><BR><FONT size=2>&gt; cycles.</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; I may use the same CRL 100+ times 
before it expires for many different </FONT><BR><FONT size=2>&gt; certificates. 
We send certificates with every OCSP response and we </FONT><BR><FONT 
size=2>&gt; don't consider that a problem.</FONT> </P>
<P><FONT size=2>Stefan,</FONT> </P>
<P><FONT size=2>if I may jump in. Sometimes, it IS a problem to send 
certificates with OCSP responses. We have at least one example where we will 
have to use OCSP responses without certificates due to size 
contraints.</FONT></P>
<P><FONT size=2>Admitelly, this case is rare, but there are scenarios where OCSP 
or CRL size matters :)</FONT> </P>
<P><FONT size=2>What would you think of having a standard way to request (and 
send) the certificate(s) associated to a CRL without bundling them.</FONT></P>
<P><FONT size=2>One example (probably not the best but...) could be</FONT> </P>
<P><FONT size=2><A href="http://www.xxx.com/thecrl.der" 
target=_blank>http://www.xxx.com/thecrl.der</A>&nbsp; --&gt; Gives the bare CRL 
<A href="http://www.xxx.com/thecrl.der?addcert" 
target=_blank>http://www.xxx.com/thecrl.der?addcert</A>&nbsp; --&gt; Gives the 
certificate, followed by the bare CRL (so that you can stream).</FONT></P>
<P><FONT size=2>Regards,</FONT> </P>
<P><FONT size=2>--</FONT> <BR><FONT size=2>Julien</FONT> <BR><FONT 
size=2>&nbsp;</FONT> <BR><FONT size=2>&gt; Stefan Santesson</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; Senior Program Manager</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; Windows Security, Standards</FONT> 
<BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; From: 
[email-masked] </FONT><BR><FONT size=2>&gt; [<A 
href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
<BR><FONT size=2>&gt; On Behalf Of Denis Pinkas</FONT> <BR><FONT size=2>&gt; 
Sent: den 18 september 2006 06:10</FONT> <BR><FONT size=2>&gt; To: 
[email-masked]</FONT> <BR><FONT size=2>&gt; Subject: Re: Certs in CRLs - New 
standards task?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; 
</FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
________________________________</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; Stefan,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; My 
replies have [Denis] in front of them.</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; Hi Denis,</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; Speaking as an implementer and from the experience 
from how our own </FONT><BR><FONT size=2>&gt; products work, the issue and the 
solution is much more simple than the </FONT><BR><FONT size=2>&gt; solution you 
propose.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; 
The&nbsp; validation engine does not need to know which certificate that 
</FONT><BR><FONT size=2>&gt; represents the old or the new CA key or what the 
hash of the </FONT><BR><FONT size=2>&gt; certificate is. The task of the 
validation engine for this issue is </FONT><BR><FONT size=2>&gt; simply to 
validate the signature of the CRL using a valid path to a </FONT><BR><FONT 
size=2>&gt; trusted root (being the same used to validate the target 
certificate).</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
[Denis]&nbsp; I disagree. Before the "validation engine" there is the "path 
</FONT><BR><FONT size=2>&gt; construction engine". Depending upon whether key 
rollover has been or </FONT><BR><FONT size=2>&gt; has not been performed by the 
relying party, one or two certificates </FONT><BR><FONT size=2>&gt; may be 
needed. If the CRL issuer is servings multiple CAs, then a </FONT><BR><FONT 
size=2>&gt; couple of certificates are needed for each CA. If we define a new 
</FONT><BR><FONT size=2>&gt; extension, it MUST also be usable for a single CRL 
issued for </FONT><BR><FONT size=2>&gt; different CAs.</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; First of all the validation engine will 
try to build a path using all </FONT><BR><FONT size=2>&gt; certs from the 
validated path and all cashed and locally stored </FONT><BR><FONT size=2>&gt; 
certificates and root keys. If this fails it could use the certs 
</FONT><BR><FONT size=2>&gt; provided in the CRL using this new extension (just 
a bag of </FONT><BR><FONT size=2>&gt; certificates with no specific 
information).</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; [Denis] 
Ahhhhh! you just crossed the line: a bag of certificates !</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; In the end, if the provided bag 
of certificates (typically only 1 </FONT><BR><FONT size=2>&gt; certificate if 
present) does not help the RP, we did not do any </FONT><BR><FONT size=2>&gt; 
particular damage to the RP (just slightly increased the CRL), we just 
</FONT><BR><FONT size=2>&gt; couldn't help him and he will now have to try 
directory search etc as </FONT><BR><FONT size=2>&gt; before. But the fact is 
that by including certificate/s in the CRL we </FONT><BR><FONT size=2>&gt; may 
in many PKI configurations considerably help the RP.</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; [Denis] You will need to transfer that 
bag of certificates every time. </FONT><BR><FONT size=2>&gt; This is not good. 
Instead of trying to convince that the initially </FONT><BR><FONT size=2>&gt; 
proposed solution is the best, please take some time to consider the 
</FONT><BR><FONT size=2>&gt; benefits and drawbacks of the other solution I 
proposed.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I fully 
agree that this information can not be stored in an AIA. A new </FONT><BR><FONT 
size=2>&gt; CRL extension is needed.</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; Finally I don't agree to the term "overloading" 
here. We usually use </FONT><BR><FONT size=2>&gt; that term to describe when we 
stretch the semantics of existing fields </FONT><BR><FONT size=2>&gt; and name 
forms. This is just an new optional non-critical extension </FONT><BR><FONT 
size=2>&gt; with useful data, relevant to the processing of the CRL.</FONT> 
<BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Denis</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; </FONT><BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt;&nbsp; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; Stefan Santesson</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; Senior Program Manager</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; Windows Security, Standards</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; From: [email-masked] </FONT><BR><FONT 
size=2>&gt; [<A 
href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
<BR><FONT size=2>&gt; On Behalf Of Denis Pinkas</FONT> <BR><FONT size=2>&gt; 
Sent: den 18 september 2006 00:51</FONT> <BR><FONT size=2>&gt; To: 
[email-masked]</FONT> <BR><FONT size=2>&gt; Subject: Re: Certs in CRLs - New 
standards task?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; 
</FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Stefan,</FONT> 
<BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; </FONT><BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; I am not in favour of the proposed 
approach.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; 
</FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I have concern by 
always overloading the CRL, not simply with one </FONT><BR><FONT size=2>&gt; 
additional certificate,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; but with two additional certificates, because of CA key 
rollover.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; 
</FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; The situation will be 
even worse when a CRL issuer is trusted by more </FONT><BR><FONT size=2>&gt; 
than one CA</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; to issue 
CRLs.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; 
</FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Talking to you in your 
capacity of co-chair, I would like to recall </FONT><BR><FONT size=2>&gt; that 
the full story</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; of how 
to check a CRL that is not issued by a CA is still not crystal </FONT><BR><FONT 
size=2>&gt; clear in 3280bis,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; and we should clarify that before. :-)</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt;&nbsp; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; Talking to you as PKIX member, I would favor the use of&nbsp; one 
extension </FONT><BR><FONT size=2>&gt; with two pointers per CA:</FONT> 
<BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; </FONT><BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; - one pointing to the current or 
old certificate still valid, and</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt;&nbsp; - another one pointing the new or current certificate already 
valid.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; 
</FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; This will allow to 
fetch once the certificate(s) that is/are needed.</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt;&nbsp; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; The AIA extension is not the right vehicule, since it cannot include 
a </FONT><BR><FONT size=2>&gt; hash of the data that is pointed.</FONT> 
<BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; We should add a hash of the 
certificate, which would allow to make </FONT><BR><FONT size=2>&gt; sure that 
the right certificate</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
was obtained without the need to build and verify the certification 
</FONT><BR><FONT size=2>&gt; path.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt;&nbsp; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
&gt;From the above observations, the problem is much more complex than</FONT> 
<BR><FONT size=2>&gt; originally presented.</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt;&nbsp; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; Denis</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt;&nbsp; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
________________________________</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; Taking the pkix chair hat off and the vendor hat on</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; I'm asking this group to consider a new 
standards task to solve a real </FONT><BR><FONT size=2>&gt; implementation issue 
with indirect CRLs and CRLs issued by a re-keyed </FONT><BR><FONT size=2>&gt; 
CA. I.e. where the target certificate and it's CRL are signed by 
</FONT><BR><FONT size=2>&gt; different keys and the RP does not have access to 
the CRL Issuer </FONT><BR><FONT size=2>&gt; certificate.</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; It is basically the same situation we 
solved with allowing the AIA </FONT><BR><FONT size=2>&gt; extension in CRL's 
namely the problem to obtain the CRL issuer's </FONT><BR><FONT size=2>&gt; 
certificate, alternatively, certificate path.</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt; In our efforts to implement the AIA solution we 
have encountered some </FONT><BR><FONT size=2>&gt; real issues.</FONT> <BR><FONT 
size=2>&gt; </FONT><BR><FONT size=2>&gt; 1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Each time we are forced to go out and retrieve new information</FONT> <BR><FONT 
size=2>&gt; on the network, we have a source of potential problems such as 
</FONT><BR><FONT size=2>&gt; unavailable network resources, timeouts etc. It all 
adds to the </FONT><BR><FONT size=2>&gt; validation time and harms the user 
experience.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The AIA in CRL's provide another opening 
for DoS attacks if</FONT> <BR><FONT size=2>&gt; rouge CRL's point their AIA to a 
targeted web server. This is tough </FONT><BR><FONT size=2>&gt; not as serious 
as the DoS problems with AIA in certificates, but this </FONT><BR><FONT 
size=2>&gt; one we might avoid more easily.</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt;&nbsp; The proposed solution is to define a new CRL 
extension that may </FONT><BR><FONT size=2>&gt; contain the CRL Issuer 
certificate (not just a URL to its location). </FONT><BR><FONT size=2>&gt; 
Preferably this would be a PKCS#7 (or CMS) Certs only message that may 
</FONT><BR><FONT size=2>&gt; contain a single certificate or a bag of 
certificates (a chain).</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt;&nbsp; While it wouldn't be attractive to define such extension for 
</FONT><BR><FONT size=2>&gt; certificates due to certificate size 
considerations, CRL's are often </FONT><BR><FONT size=2>&gt; of such size that 
including the certs needed to validate it only leads </FONT><BR><FONT 
size=2>&gt; to an insignificant increase of size, while it may offer substantial 
</FONT><BR><FONT size=2>&gt; processing advantages.</FONT> <BR><FONT size=2>&gt; 
</FONT><BR><FONT size=2>&gt;&nbsp; I would like to hear the opinion of this 
group on this.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; I 
volunteer to write a first draft if there is interest from the </FONT><BR><FONT 
size=2>&gt; group.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt;&nbsp; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
Stefan Santesson</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
Senior Program Manager</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
Windows Security, Standards</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt;&nbsp; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
________________________________</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
size=2>&gt; ________________________________</FONT> <BR><FONT size=2>&gt; 
</FONT></P>
<HR>
</BODY></HTML>

--=====003_Dragon622132605503_=====--

From: "Al Arsenault" <[email-masked]>
To: "'Joel Kazin'" <[email-masked]>
Cc: "'Christine Karman'" <[email-masked]>, "'Kemp David P.'" <[email-masked]>, <[email-masked]>
Subject: RE: large crl's
Date: Tue, 19 Sep 2006 10:13:04 -0400
Importance: Normal
Sender: [email-masked]

Joel,

True, but I was responding to Christine's original comment that 

"That does mean that if a certificate gets revoked, a hacker will have 24
hours to use this compromised certificate."

Anticipated revocations, such as an employee leaving an organization, should
not fall into this category. Every time I've left an organization, there's a
standard process for revoking my certificate, invalidating my badge so it
doesn't open the doors any more, returning physical keys, credit cards, etc.
This should not cause a significant burden on the PKI if done properly.

(An example - when I left the US Government, the organization always
processed outgoing employees on Fridays.  You went to a central office at 9
am on Friday, and they invalidated the badge, revoked the cert, etc. etc.
then.  If you didn't want to work up until Friday, you didn't have to - you
could take paid or unpaid vacation for as much of the rest of the week as
you wanted, but you checked out on Friday.  This made it easier for
revocation purposes.  This did not apply to people being fired, obviously.)

With the emergency revocation - I'm assuming you mean "defalcation" in the
sense of "embezzlement" - yes, you want to revoke immediately, but by your
own assumption the employee has already been misusing the certificate for
some period of time, most likely longer than a few hours - so my original
point still holds.

			Al Arsenault

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joel Kazin
Sent: Tuesday, September 19, 2006 8:42 AM
To: Al Arsenault
Cc: 'Christine Karman'; 'Kemp David P.'; [email-masked]
Subject: Re: large crl's

The issue is not limited to revoking compromised certificates. All the 
PKIs that I have designed revoke the respective end entity certificates 
when the employee or contractor leaves the organization. While such 
certificates are normally revoked once a day through an interface to the 
directory of record, the CP states that such revocation may be made more 
frequently and the CRLs can be published several times a day. Also, 
there are situations, for example employee defalcation, where you would 
want to revoke a certificate immediately. In practice, the number of 
routine revocations greatly exceeds the number due to compromise or 
immediate need.

Al Arsenault wrote:

> Christine,
>
> We don't do brosers, we do email. Think of ten messages per second
>
> being encrypted or decrypted, with new certificates and possibly new
>
> crl's coming in all the time. Of course, the number of crl's is
>
> limited, and we probably have to accept that we don't download larget
>
> crl's more often than every couplf of hours, or even a day. That does
>
> mean that if a certificate gets revoked, a hacker will have 24 hours
>
> to use this compromised certificate.
>
> AWA: Experience - at least within some circles - has shown that in the 
> general case the time between when the certificate should be revoked 
> (e.g., when the key is actually compromised) and the incident is 
> reported to the CA is MUCH greater than the time to distribute the 
> revocation information, whether the distribution is by CRL or OCSP. 
> That is, users don't discover that their keys have been compromised 
> until some external event occurs - they realized that their token is 
> missing; or they're notified of some transaction in which they didn't 
> participate; etc. Once a compromise is reported, there is generally 
> some period of investigation to determine if the report is genuine 
> (otherwise you're subject to neat denial of service attacks in which I 
> just report each of your keys as compromised), and this adds to the 
> total time it takes to push the revocation out. This tends in many 
> cases to be much greater than the 24 hours (or less) it takes to push 
> the revocation information out to all users in the system. (Yes, there 
> are exceptions and that's why some organizations really want OCSP, but 
> of course it then has its own issues.)
>
> Another difference between authentication in a browser and email is
>
> the following. A company archives old email. They have to be able to
>
> verify validity of digital signatures on incoming email, even for
>
> certificates that have expired long ago. The DOD will have to have
>
> that 20Mb crl available forever, unless they switch to online 
> verification.
>
> AWA: First, the browser transactions are often archived, just like 
> e-mail. Second, even with on-line verification, some part of the 
> system has to store forever the certificate validity information if 
> you want to do retroactive validation. You can store it centrally, or 
> with the messages, or whatever. There are "good engineering solutions" 
> to the problem and "bad engineering solutions" to the problem, but it 
> tends not to matter over time which you do, you still have to store 
> all the information for later retrieval.
>
> Al Arsenault
>

Date: Tue, 19 Sep 2006 15:55:01 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Certs in CRLs - New standards task?
Sender: [email-masked]

Julien Stern wrote:
> One example (probably not the best but...) could be
>
> http://www.xxx.com/thecrl.der  --> Gives the bare CRL
> http://www.xxx.com/thecrl.der?addcert  --> Gives the certificate,
> followed by the bare CRL (so that you can stream).
>   
Or if I dare come back with my p7c solution which I do not actually have 
time (nor really intend as is) to argument for :
http://www.xxx.com/thecrl.der?x-pkcs7-crl --> Gives the crl  in pkcs#7, 
including optional certificates if you want

Ugly as it is, it has one big point going for it, it's already 
implemented. One fast  test gives me 51 bytes overhead, it's not that 
terrible wrt all those not really useful extensions some certificates have.
*
*

From: Sharon Boeyen <[email-masked]>
To: "'Julien Stern'" <[email-masked]>, [email-masked]
Subject: RE: Certs in CRLs - New standards task?
Date: Tue, 19 Sep 2006 09:16:30 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C6DBED.4128B320
Content-Type: text/plain

The more I think about this the more I dislike the approach of including
certs in the CRL. There are currently implementations that are able to find
all the paths they need with the current information in the CRL (by using
the DN to do a directory lookup). I recognize this isn't always the simplest
way to find information and I do support pointer schemes such as AIA and SIA
or another pointer approach. However I really don't want to see the size of
CRLs increased in the way they would be even if a single cert was added,
whether that be for indirect CRLs, CA key rollovers or any other case. 

Stefan, its fine for you to say that implementers wouldn't need to support
the new extension, however as soon as a CA starts putting it in there is an
impact on all implementations because of the size of the CRL (regardless of
whether an implementation decides to process or ignore the non-critical
extension). 

Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Tuesday, September 19, 2006 5:15 AM
To: [email-masked]
Subject: Re: Certs in CRLs - New standards task?

On Mon, Sep 18, 2006 at 04:41:29PM +0100, Stefan Santesson wrote:
> Denis,
> 
> When this is not a good solution to your problem, then don't use it.
> 
> Why MUST is be bad to send the certs with every CRL if the alternative 
> is to go out on the network and fetch the certificates using extra 
> cycles.
> 
> I may use the same CRL 100+ times before it expires for many different 
> certificates. We send certificates with every OCSP response and we 
> don't consider that a problem.

Stefan,

if I may jump in. Sometimes, it IS a problem to send certificates with OCSP
responses. We have at least one example where we will have to use OCSP
responses without certificates due to size contraints.

Admitelly, this case is rare, but there are scenarios where OCSP or CRL size
matters :)

What would you think of having a standard way to request (and send) the
certificate(s) associated to a CRL without bundling them.

One example (probably not the best but...) could be

http://www.xxx.com/thecrl.der  --> Gives the bare CRL
http://www.xxx.com/thecrl.der?addcert  --> Gives the certificate, followed
by the bare CRL (so that you can stream).

Regards,

--
Julien
 
> Stefan Santesson
> 
> Senior Program Manager
> 
> Windows Security, Standards
> 
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 18 september 2006 06:10
> To: [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
>  
> 
> ________________________________
> 
> Stefan,
> 
> My replies have [Denis] in front of them.
> 
> Hi Denis,
> 
> Speaking as an implementer and from the experience from how our own 
> products work, the issue and the solution is much more simple than the 
> solution you propose.
> 
>  The  validation engine does not need to know which certificate that 
> represents the old or the new CA key or what the hash of the 
> certificate is. The task of the validation engine for this issue is 
> simply to validate the signature of the CRL using a valid path to a 
> trusted root (being the same used to validate the target certificate).
> 
> [Denis]  I disagree. Before the "validation engine" there is the "path 
> construction engine". Depending upon whether key rollover has been or 
> has not been performed by the relying party, one or two certificates 
> may be needed. If the CRL issuer is servings multiple CAs, then a 
> couple of certificates are needed for each CA. If we define a new 
> extension, it MUST also be usable for a single CRL issued for 
> different CAs.
> 
> First of all the validation engine will try to build a path using all 
> certs from the validated path and all cashed and locally stored 
> certificates and root keys. If this fails it could use the certs 
> provided in the CRL using this new extension (just a bag of 
> certificates with no specific information).
> 
> [Denis] Ahhhhh! you just crossed the line: a bag of certificates !
> 
>  In the end, if the provided bag of certificates (typically only 1 
> certificate if present) does not help the RP, we did not do any 
> particular damage to the RP (just slightly increased the CRL), we just 
> couldn't help him and he will now have to try directory search etc as 
> before. But the fact is that by including certificate/s in the CRL we 
> may in many PKI configurations considerably help the RP.
> 
> [Denis] You will need to transfer that bag of certificates every time. 
> This is not good. Instead of trying to convince that the initially 
> proposed solution is the best, please take some time to consider the 
> benefits and drawbacks of the other solution I proposed.
> 
> I fully agree that this information can not be stored in an AIA. A new 
> CRL extension is needed.
> 
> Finally I don't agree to the term "overloading" here. We usually use 
> that term to describe when we stretch the semantics of existing fields 
> and name forms. This is just an new optional non-critical extension 
> with useful data, relevant to the processing of the CRL.
> 
> Denis
> 
>  
> 
>  
> 
> Stefan Santesson
> 
> Senior Program Manager
> 
> Windows Security, Standards
> 
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 18 september 2006 00:51
> To: [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
>  
> 
> Stefan,
> 
>  
> 
> I am not in favour of the proposed approach.
> 
>  
> 
> I have concern by always overloading the CRL, not simply with one 
> additional certificate,
> 
> but with two additional certificates, because of CA key rollover.
> 
>  
> 
> The situation will be even worse when a CRL issuer is trusted by more 
> than one CA
> 
> to issue CRLs.
> 
>  
> 
> Talking to you in your capacity of co-chair, I would like to recall 
> that the full story
> 
> of how to check a CRL that is not issued by a CA is still not crystal 
> clear in 3280bis,
> 
> and we should clarify that before. :-)
> 
>  
> 
> Talking to you as PKIX member, I would favor the use of  one extension 
> with two pointers per CA:
> 
>  
> 
>  - one pointing to the current or old certificate still valid, and
> 
>  - another one pointing the new or current certificate already valid.
> 
>  
> 
> This will allow to fetch once the certificate(s) that is/are needed.
> 
>  
> 
> The AIA extension is not the right vehicule, since it cannot include a 
> hash of the data that is pointed.
> 
> We should add a hash of the certificate, which would allow to make 
> sure that the right certificate
> 
> was obtained without the need to build and verify the certification 
> path.
> 
>  
> 
> >From the above observations, the problem is much more complex than
> originally presented.
> 
>  
> 
> Denis
> 
>  
> 
> ________________________________
> 
> Taking the pkix chair hat off and the vendor hat on
> 
> I'm asking this group to consider a new standards task to solve a real 
> implementation issue with indirect CRLs and CRLs issued by a re-keyed 
> CA. I.e. where the target certificate and it's CRL are signed by 
> different keys and the RP does not have access to the CRL Issuer 
> certificate.
> 
> It is basically the same situation we solved with allowing the AIA 
> extension in CRL's namely the problem to obtain the CRL issuer's 
> certificate, alternatively, certificate path.
> 
> In our efforts to implement the AIA solution we have encountered some 
> real issues.
> 
> 1)       Each time we are forced to go out and retrieve new information
> on the network, we have a source of potential problems such as 
> unavailable network resources, timeouts etc. It all adds to the 
> validation time and harms the user experience.
> 
> 2)       The AIA in CRL's provide another opening for DoS attacks if
> rouge CRL's point their AIA to a targeted web server. This is tough 
> not as serious as the DoS problems with AIA in certificates, but this 
> one we might avoid more easily.
> 
>  The proposed solution is to define a new CRL extension that may 
> contain the CRL Issuer certificate (not just a URL to its location). 
> Preferably this would be a PKCS#7 (or CMS) Certs only message that may 
> contain a single certificate or a bag of certificates (a chain).
> 
>  While it wouldn't be attractive to define such extension for 
> certificates due to certificate size considerations, CRL's are often 
> of such size that including the certs needed to validate it only leads 
> to an insignificant increase of size, while it may offer substantial 
> processing advantages.
> 
>  I would like to hear the opinion of this group on this.
> 
>  I volunteer to write a first draft if there is interest from the 
> group.
> 
>  
> 
> Stefan Santesson
> 
> Senior Program Manager
> 
> Windows Security, Standards
> 
>  
> 
> ________________________________
> 
> ________________________________
> 

------_=_NextPart_001_01C6DBED.4128B320
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: Certs in CRLs - New standards task?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>The more I think about this the more I dislike the =
approach of including certs in the CRL. There are currently =
implementations that are able to find all the paths they need with the =
current information in the CRL (by using the DN to do a directory =
lookup). I recognize this isn't always the simplest way to find =
information and I do support pointer schemes such as AIA and SIA or =
another pointer approach. However I really don't want to see the size =
of CRLs increased in the way they would be even if a single cert was =
added, whether that be for indirect CRLs, CA key rollovers or any other =
case. </FONT></P>

<P><FONT SIZE=3D2>Stefan, its fine for you to say that implementers =
wouldn't need to support the new extension, however as soon as a CA =
starts putting it in there is an impact on all implementations because =
of the size of the CRL (regardless of whether an implementation decides =
to process or ignore the non-critical extension). </FONT></P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Sharon</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</A>] On Behalf Of Julien Stern</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, September 19, 2006 5:15 AM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Certs in CRLs - New standards =
task?</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>On Mon, Sep 18, 2006 at 04:41:29PM +0100, Stefan =
Santesson wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; Denis,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; When this is not a good solution to your =
problem, then don't use it.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Why MUST is be bad to send the certs with every =
CRL if the alternative </FONT>
<BR><FONT SIZE=3D2>&gt; is to go out on the network and fetch the =
certificates using extra </FONT>
<BR><FONT SIZE=3D2>&gt; cycles.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I may use the same CRL 100+ times before it =
expires for many different </FONT>
<BR><FONT SIZE=3D2>&gt; certificates. We send certificates with every =
OCSP response and we </FONT>
<BR><FONT SIZE=3D2>&gt; don't consider that a problem.</FONT>
</P>

<P><FONT SIZE=3D2>Stefan,</FONT>
</P>

<P><FONT SIZE=3D2>if I may jump in. Sometimes, it IS a problem to send =
certificates with OCSP responses. We have at least one example where we =
will have to use OCSP responses without certificates due to size =
contraints.</FONT></P>

<P><FONT SIZE=3D2>Admitelly, this case is rare, but there are scenarios =
where OCSP or CRL size matters :)</FONT>
</P>

<P><FONT SIZE=3D2>What would you think of having a standard way to =
request (and send) the certificate(s) associated to a CRL without =
bundling them.</FONT></P>

<P><FONT SIZE=3D2>One example (probably not the best but...) could =
be</FONT>
</P>

<P><FONT SIZE=3D2><A HREF=3D"http://www.xxx.com/thecrl.der" =
TARGET=3D"_blank">http://www.xxx.com/thecrl.der</A>&nbsp; --&gt; Gives =
the bare CRL <A HREF=3D"http://www.xxx.com/thecrl.der?addcert" =
TARGET=3D"_blank">http://www.xxx.com/thecrl.der?addcert</A>&nbsp; =
--&gt; Gives the certificate, followed by the bare CRL (so that you can =
stream).</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Julien</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Senior Program Manager</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Windows Security, Standards</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; From: [email-masked] </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; On Behalf Of Denis Pinkas</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: den 18 september 2006 06:10</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Certs in CRLs - New standards =
task?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Stefan,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; My replies have [Denis] in front of =
them.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi Denis,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Speaking as an implementer and from the =
experience from how our own </FONT>
<BR><FONT SIZE=3D2>&gt; products work, the issue and the solution is =
much more simple than the </FONT>
<BR><FONT SIZE=3D2>&gt; solution you propose.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; The&nbsp; validation engine does not need =
to know which certificate that </FONT>
<BR><FONT SIZE=3D2>&gt; represents the old or the new CA key or what =
the hash of the </FONT>
<BR><FONT SIZE=3D2>&gt; certificate is. The task of the validation =
engine for this issue is </FONT>
<BR><FONT SIZE=3D2>&gt; simply to validate the signature of the CRL =
using a valid path to a </FONT>
<BR><FONT SIZE=3D2>&gt; trusted root (being the same used to validate =
the target certificate).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [Denis]&nbsp; I disagree. Before the =
&quot;validation engine&quot; there is the &quot;path </FONT>
<BR><FONT SIZE=3D2>&gt; construction engine&quot;. Depending upon =
whether key rollover has been or </FONT>
<BR><FONT SIZE=3D2>&gt; has not been performed by the relying party, =
one or two certificates </FONT>
<BR><FONT SIZE=3D2>&gt; may be needed. If the CRL issuer is servings =
multiple CAs, then a </FONT>
<BR><FONT SIZE=3D2>&gt; couple of certificates are needed for each CA. =
If we define a new </FONT>
<BR><FONT SIZE=3D2>&gt; extension, it MUST also be usable for a single =
CRL issued for </FONT>
<BR><FONT SIZE=3D2>&gt; different CAs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; First of all the validation engine will try to =
build a path using all </FONT>
<BR><FONT SIZE=3D2>&gt; certs from the validated path and all cashed =
and locally stored </FONT>
<BR><FONT SIZE=3D2>&gt; certificates and root keys. If this fails it =
could use the certs </FONT>
<BR><FONT SIZE=3D2>&gt; provided in the CRL using this new extension =
(just a bag of </FONT>
<BR><FONT SIZE=3D2>&gt; certificates with no specific =
information).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [Denis] Ahhhhh! you just crossed the line: a =
bag of certificates !</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; In the end, if the provided bag of =
certificates (typically only 1 </FONT>
<BR><FONT SIZE=3D2>&gt; certificate if present) does not help the RP, =
we did not do any </FONT>
<BR><FONT SIZE=3D2>&gt; particular damage to the RP (just slightly =
increased the CRL), we just </FONT>
<BR><FONT SIZE=3D2>&gt; couldn't help him and he will now have to try =
directory search etc as </FONT>
<BR><FONT SIZE=3D2>&gt; before. But the fact is that by including =
certificate/s in the CRL we </FONT>
<BR><FONT SIZE=3D2>&gt; may in many PKI configurations considerably =
help the RP.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [Denis] You will need to transfer that bag of =
certificates every time. </FONT>
<BR><FONT SIZE=3D2>&gt; This is not good. Instead of trying to convince =
that the initially </FONT>
<BR><FONT SIZE=3D2>&gt; proposed solution is the best, please take some =
time to consider the </FONT>
<BR><FONT SIZE=3D2>&gt; benefits and drawbacks of the other solution I =
proposed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I fully agree that this information can not be =
stored in an AIA. A new </FONT>
<BR><FONT SIZE=3D2>&gt; CRL extension is needed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Finally I don't agree to the term =
&quot;overloading&quot; here. We usually use </FONT>
<BR><FONT SIZE=3D2>&gt; that term to describe when we stretch the =
semantics of existing fields </FONT>
<BR><FONT SIZE=3D2>&gt; and name forms. This is just an new optional =
non-critical extension </FONT>
<BR><FONT SIZE=3D2>&gt; with useful data, relevant to the processing of =
the CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Senior Program Manager</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Windows Security, Standards</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; From: [email-masked] </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; On Behalf Of Denis Pinkas</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: den 18 september 2006 00:51</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Certs in CRLs - New standards =
task?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Stefan,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I am not in favour of the proposed =
approach.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I have concern by always overloading the CRL, =
not simply with one </FONT>
<BR><FONT SIZE=3D2>&gt; additional certificate,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; but with two additional certificates, because =
of CA key rollover.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The situation will be even worse when a CRL =
issuer is trusted by more </FONT>
<BR><FONT SIZE=3D2>&gt; than one CA</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; to issue CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Talking to you in your capacity of co-chair, I =
would like to recall </FONT>
<BR><FONT SIZE=3D2>&gt; that the full story</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; of how to check a CRL that is not issued by a =
CA is still not crystal </FONT>
<BR><FONT SIZE=3D2>&gt; clear in 3280bis,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; and we should clarify that before. :-)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Talking to you as PKIX member, I would favor =
the use of&nbsp; one extension </FONT>
<BR><FONT SIZE=3D2>&gt; with two pointers per CA:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; - one pointing to the current or old =
certificate still valid, and</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; - another one pointing the new or current =
certificate already valid.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This will allow to fetch once the =
certificate(s) that is/are needed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The AIA extension is not the right vehicule, =
since it cannot include a </FONT>
<BR><FONT SIZE=3D2>&gt; hash of the data that is pointed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We should add a hash of the certificate, which =
would allow to make </FONT>
<BR><FONT SIZE=3D2>&gt; sure that the right certificate</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; was obtained without the need to build and =
verify the certification </FONT>
<BR><FONT SIZE=3D2>&gt; path.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;From the above observations, the problem is =
much more complex than</FONT>
<BR><FONT SIZE=3D2>&gt; originally presented.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Taking the pkix chair hat off and the vendor =
hat on</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm asking this group to consider a new =
standards task to solve a real </FONT>
<BR><FONT SIZE=3D2>&gt; implementation issue with indirect CRLs and =
CRLs issued by a re-keyed </FONT>
<BR><FONT SIZE=3D2>&gt; CA. I.e. where the target certificate and it's =
CRL are signed by </FONT>
<BR><FONT SIZE=3D2>&gt; different keys and the RP does not have access =
to the CRL Issuer </FONT>
<BR><FONT SIZE=3D2>&gt; certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It is basically the same situation we solved =
with allowing the AIA </FONT>
<BR><FONT SIZE=3D2>&gt; extension in CRL's namely the problem to obtain =
the CRL issuer's </FONT>
<BR><FONT SIZE=3D2>&gt; certificate, alternatively, certificate =
path.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In our efforts to implement the AIA solution we =
have encountered some </FONT>
<BR><FONT SIZE=3D2>&gt; real issues.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Each =
time we are forced to go out and retrieve new information</FONT>
<BR><FONT SIZE=3D2>&gt; on the network, we have a source of potential =
problems such as </FONT>
<BR><FONT SIZE=3D2>&gt; unavailable network resources, timeouts etc. It =
all adds to the </FONT>
<BR><FONT SIZE=3D2>&gt; validation time and harms the user =
experience.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The AIA =
in CRL's provide another opening for DoS attacks if</FONT>
<BR><FONT SIZE=3D2>&gt; rouge CRL's point their AIA to a targeted web =
server. This is tough </FONT>
<BR><FONT SIZE=3D2>&gt; not as serious as the DoS problems with AIA in =
certificates, but this </FONT>
<BR><FONT SIZE=3D2>&gt; one we might avoid more easily.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; The proposed solution is to define a new =
CRL extension that may </FONT>
<BR><FONT SIZE=3D2>&gt; contain the CRL Issuer certificate (not just a =
URL to its location). </FONT>
<BR><FONT SIZE=3D2>&gt; Preferably this would be a PKCS#7 (or CMS) =
Certs only message that may </FONT>
<BR><FONT SIZE=3D2>&gt; contain a single certificate or a bag of =
certificates (a chain).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; While it wouldn't be attractive to define =
such extension for </FONT>
<BR><FONT SIZE=3D2>&gt; certificates due to certificate size =
considerations, CRL's are often </FONT>
<BR><FONT SIZE=3D2>&gt; of such size that including the certs needed to =
validate it only leads </FONT>
<BR><FONT SIZE=3D2>&gt; to an insignificant increase of size, while it =
may offer substantial </FONT>
<BR><FONT SIZE=3D2>&gt; processing advantages.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; I would like to hear the opinion of this =
group on this.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; I volunteer to write a first draft if =
there is interest from the </FONT>
<BR><FONT SIZE=3D2>&gt; group.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Senior Program Manager</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Windows Security, Standards</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6DBED.4128B320--

Date: Tue, 19 Sep 2006 08:42:22 -0400
From: Joel Kazin <[email-masked]>
To: Al Arsenault <[email-masked]>
CC: "'Christine Karman'" <[email-masked]>, "'Kemp David P.'" <[email-masked]>, [email-masked]
Subject: Re: large crl's
Sender: [email-masked]

The issue is not limited to revoking compromised certificates. All the 
PKIs that I have designed revoke the respective end entity certificates 
when the employee or contractor leaves the organization. While such 
certificates are normally revoked once a day through an interface to the 
directory of record, the CP states that such revocation may be made more 
frequently and the CRLs can be published several times a day. Also, 
there are situations, for example employee defalcation, where you would 
want to revoke a certificate immediately. In practice, the number of 
routine revocations greatly exceeds the number due to compromise or 
immediate need.

Al Arsenault wrote:

> Christine,
>
> We don't do brosers, we do email. Think of ten messages per second
>
> being encrypted or decrypted, with new certificates and possibly new
>
> crl's coming in all the time. Of course, the number of crl's is
>
> limited, and we probably have to accept that we don't download larget
>
> crl's more often than every couplf of hours, or even a day. That does
>
> mean that if a certificate gets revoked, a hacker will have 24 hours
>
> to use this compromised certificate.
>
> AWA: Experience – at least within some circles - has shown that in the 
> general case the time between when the certificate should be revoked 
> (e.g., when the key is actually compromised) and the incident is 
> reported to the CA is MUCH greater than the time to distribute the 
> revocation information, whether the distribution is by CRL or OCSP. 
> That is, users don’t discover that their keys have been compromised 
> until some external event occurs – they realized that their token is 
> missing; or they’re notified of some transaction in which they didn’t 
> participate; etc. Once a compromise is reported, there is generally 
> some period of investigation to determine if the report is genuine 
> (otherwise you’re subject to neat denial of service attacks in which I 
> just report each of your keys as compromised), and this adds to the 
> total time it takes to push the revocation out. This tends in many 
> cases to be much greater than the 24 hours (or less) it takes to push 
> the revocation information out to all users in the system. (Yes, there 
> are exceptions and that’s why some organizations really want OCSP, but 
> of course it then has its own issues.)
>
> Another difference between authentication in a browser and email is
>
> the following. A company archives old email. They have to be able to
>
> verify validity of digital signatures on incoming email, even for
>
> certificates that have expired long ago. The DOD will have to have
>
> that 20Mb crl available forever, unless they switch to online 
> verification.
>
> AWA: First, the browser transactions are often archived, just like 
> e-mail. Second, even with on-line verification, some part of the 
> system has to store forever the certificate validity information if 
> you want to do retroactive validation. You can store it centrally, or 
> with the messages, or whatever. There are “good engineering solutions” 
> to the problem and “bad engineering solutions” to the problem, but it 
> tends not to matter over time which you do, you still have to store 
> all the information for later retrieval.
>
> Al Arsenault
>

From: "Al Arsenault" <[email-masked]>
To: "'Christine Karman'" <[email-masked]>, "'Kemp David P.'" <[email-masked]>, <[email-masked]>
Subject: RE: large crl's
Date: Tue, 19 Sep 2006 07:33:13 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Christine,

=20

=20

We don't do brosers, we do email. Think of ten messages per second=20

being encrypted or decrypted, with new certificates and possibly new=20

crl's coming in all the time. Of course, the number of crl's is=20

limited, and we probably have to accept that we don't download larget=20

crl's more often than every couplf of hours, or even a day. That does=20

mean that if a certificate gets revoked, a hacker will have 24 hours=20

to use this compromised certificate.

=20

AWA:  Experience - at least within some circles - has shown that in the
general case the time between when the certificate should be revoked =
(e.g.,
when the key is actually compromised) and the incident is reported to =
the CA
is MUCH greater than the time to distribute the revocation information,
whether the distribution is by CRL or OCSP. That is, users don't =
discover
that their keys have been compromised until some external event occurs -
they realized that their token is missing; or they're notified of some
transaction in which they didn't participate; etc.  Once a compromise is
reported, there is generally some period of investigation to determine =
if
the report is genuine (otherwise you're subject to neat denial of =
service
attacks in which I just report each of your keys as compromised), and =
this
adds to the total time it takes to push the revocation out.  This tends =
in
many cases to be much greater than the 24 hours (or less) it takes to =
push
the revocation information out to all users in the system. (Yes, there =
are
exceptions and that's why some organizations really want OCSP, but of =
course
it then has its own issues.)

=20

=20

Another difference between authentication in a browser and email is=20

the following. A company archives old email. They have to be able to=20

verify validity of digital signatures on incoming email, even for=20

certificates that have expired long ago. The DOD will have to have=20

that 20Mb crl available forever, unless they switch to online =
verification.

=20

AWA:  First, the browser transactions are often archived, just like =
e-mail.
Second, even with on-line verification, some part of the system has to =
store
forever the certificate validity information if you want to do =
retroactive
validation. You can store it centrally, or with the messages, or =
whatever.
There are "good engineering solutions" to the problem and "bad =
engineering
solutions" to the problem, but it tends not to matter over time which =
you
do, you still have to store all the information for later retrieval.

=20

            Al Arsenault

=20

=20

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

<html>

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

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

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 77.95pt 1.0in 77.95pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Christine,</span></font></p>

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

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>We don't do brosers, we do email. Think of ten messages per =
second </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>being encrypted or decrypted, with new certificates and possibly =
new </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>crl's coming in all the time. Of course, the number of crl's is =
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>limited, and we probably have to accept that we don't download =
larget </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>crl's more often than every couplf of hours, or even a day. That =
does </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>mean that if a certificate gets revoked, a hacker will have 24 =
hours </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>to use this compromised certificate.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>AWA:&nbsp; Experience &#8211; at =
least
within some circles - has shown that in the general case the time =
between when
the certificate should be revoked (e.g., when the key is actually =
compromised)
and the incident is reported to the CA is MUCH greater than the time to
distribute the revocation information, whether the distribution is by =
CRL or
OCSP. That is, users don&#8217;t discover that their keys have been =
compromised
until some external event occurs &#8211; they realized that their token =
is
missing; or they&#8217;re notified of some transaction in which they =
didn&#8217;t
participate; etc.&nbsp; Once a compromise is reported, there is =
generally some
period of investigation to determine if the report is genuine (otherwise =
you&#8217;re
subject to neat denial of service attacks in which I just report each of =
your
keys as compromised), and this adds to the total time it takes to push =
the
revocation out. &nbsp;This tends in many cases to be much greater than =
the 24
hours (or less) it takes to push the revocation information out to all =
users in
the system. (Yes, there are exceptions and that&#8217;s why some =
organizations
really want OCSP, but of course it then has its own =
issues.)</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;</span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Another difference between authentication in a browser and email =
is </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>the following. A company archives old email. They have to be =
able to </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>verify validity of digital signatures on incoming email, even =
for </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>certificates that have expired long ago. The DOD will have to =
have </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>that 20Mb crl available forever, unless they switch to online
verification.</span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>AWA:&nbsp; First, the browser transactions are often archived, =
just
like e-mail.&nbsp; Second, even with on-line verification, some part of =
the
system has to store forever the certificate validity information if you =
want to
do retroactive validation. You can store it centrally, or with the =
messages, or
whatever. There are &#8220;good engineering solutions&#8221; to the =
problem and
&#8220;bad engineering solutions&#8221; to the problem, but it tends not =
to
matter over time which you do, you still have to store all the =
information for
later retrieval.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Al
Arsenault</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0021_01C6DBBD.DDE25F60--

From: "Julien Stern" <[email-masked]>
Date: Tue, 19 Sep 2006 11:15:10 +0200
To: [email-masked]
Subject: Re: Certs in CRLs - New standards task?
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Sep 18, 2006 at 04:41:29PM +0100, Stefan Santesson wrote:
> Denis,
> 
> When this is not a good solution to your problem, then don't use it.
> 
> Why MUST is be bad to send the certs with every CRL if the alternative
> is to go out on the network and fetch the certificates using extra
> cycles.
> 
> I may use the same CRL 100+ times before it expires for many different
> certificates. We send certificates with every OCSP response and we don't
> consider that a problem. 

Stefan,

if I may jump in. Sometimes, it IS a problem to send certificates with
OCSP responses. We have at least one example where we will have to use
OCSP responses without certificates due to size contraints.

Admitelly, this case is rare, but there are scenarios where OCSP or
CRL size matters :)

What would you think of having a standard way to request (and send)
the certificate(s) associated to a CRL without bundling them.

One example (probably not the best but...) could be

http://www.xxx.com/thecrl.der  --> Gives the bare CRL
http://www.xxx.com/thecrl.der?addcert  --> Gives the certificate,
followed by the bare CRL (so that you can stream).

Regards,

--
Julien
 
> Stefan Santesson
> 
> Senior Program Manager
> 
> Windows Security, Standards
> 
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 18 september 2006 06:10
> To: [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
>  
> 
> ________________________________
> 
> Stefan, 
> 
> My replies have [Denis] in front of them.
> 
> Hi Denis,
> 
> Speaking as an implementer and from the experience from how our own
> products work, the issue and the solution is much more simple than the
> solution you propose.
> 
>  The  validation engine does not need to know which certificate that
> represents the old or the new CA key or what the hash of the certificate
> is. The task of the validation engine for this issue is simply to
> validate the signature of the CRL using a valid path to a trusted root
> (being the same used to validate the target certificate).
> 
> [Denis]  I disagree. Before the "validation engine" there is the "path
> construction engine". Depending upon whether key rollover has been or
> has not been performed by the relying party, one or two certificates may
> be needed. If the CRL issuer is servings multiple CAs, then a couple of
> certificates are needed for each CA. If we define a new extension, it
> MUST also be usable for a single CRL issued for different CAs.
> 
> First of all the validation engine will try to build a path using all
> certs from the validated path and all cashed and locally stored
> certificates and root keys. If this fails it could use the certs
> provided in the CRL using this new extension (just a bag of certificates
> with no specific information).
> 
> [Denis] Ahhhhh! you just crossed the line: a bag of certificates !
> 
>  In the end, if the provided bag of certificates (typically only 1
> certificate if present) does not help the RP, we did not do any
> particular damage to the RP (just slightly increased the CRL), we just
> couldn't help him and he will now have to try directory search etc as
> before. But the fact is that by including certificate/s in the CRL we
> may in many PKI configurations considerably help the RP.
> 
> [Denis] You will need to transfer that bag of certificates every time.
> This is not good. Instead of trying to convince that the initially
> proposed solution is the best, please take some time to consider the
> benefits and drawbacks of the other solution I proposed.
> 
> I fully agree that this information can not be stored in an AIA. A new
> CRL extension is needed.
> 
> Finally I don't agree to the term "overloading" here. We usually use
> that term to describe when we stretch the semantics of existing fields
> and name forms. This is just an new optional non-critical extension with
> useful data, relevant to the processing of the CRL.
> 
> Denis 
> 
>  
> 
>  
> 
> Stefan Santesson
> 
> Senior Program Manager
> 
> Windows Security, Standards
> 
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 18 september 2006 00:51
> To: [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
>  
> 
> Stefan,
> 
>  
> 
> I am not in favour of the proposed approach.
> 
>  
> 
> I have concern by always overloading the CRL, not simply with one
> additional certificate, 
> 
> but with two additional certificates, because of CA key rollover.
> 
>  
> 
> The situation will be even worse when a CRL issuer is trusted by more
> than one CA 
> 
> to issue CRLs.
> 
>  
> 
> Talking to you in your capacity of co-chair, I would like to recall that
> the full story 
> 
> of how to check a CRL that is not issued by a CA is still not crystal
> clear in 3280bis, 
> 
> and we should clarify that before. :-)
> 
>  
> 
> Talking to you as PKIX member, I would favor the use of  one extension
> with two pointers per CA:
> 
>  
> 
>  - one pointing to the current or old certificate still valid, and 
> 
>  - another one pointing the new or current certificate already valid. 
> 
>  
> 
> This will allow to fetch once the certificate(s) that is/are needed.
> 
>  
> 
> The AIA extension is not the right vehicule, since it cannot include a
> hash of the data that is pointed.
> 
> We should add a hash of the certificate, which would allow to make sure
> that the right certificate 
> 
> was obtained without the need to build and verify the certification
> path.
> 
>  
> 
> >From the above observations, the problem is much more complex than
> originally presented.
> 
>  
> 
> Denis
> 
>  
> 
> ________________________________
> 
> Taking the pkix chair hat off and the vendor hat on
> 
> I'm asking this group to consider a new standards task to solve a real
> implementation issue with indirect CRLs and CRLs issued by a re-keyed
> CA. I.e. where the target certificate and it's CRL are signed by
> different keys and the RP does not have access to the CRL Issuer
> certificate.
> 
> It is basically the same situation we solved with allowing the AIA
> extension in CRL's namely the problem to obtain the CRL issuer's
> certificate, alternatively, certificate path.
> 
> In our efforts to implement the AIA solution we have encountered some
> real issues.
> 
> 1)       Each time we are forced to go out and retrieve new information
> on the network, we have a source of potential problems such as
> unavailable network resources, timeouts etc. It all adds to the
> validation time and harms the user experience.
> 
> 2)       The AIA in CRL's provide another opening for DoS attacks if
> rouge CRL's point their AIA to a targeted web server. This is tough not
> as serious as the DoS problems with AIA in certificates, but this one we
> might avoid more easily.
> 
>  The proposed solution is to define a new CRL extension that may contain
> the CRL Issuer certificate (not just a URL to its location). Preferably
> this would be a PKCS#7 (or CMS) Certs only message that may contain a
> single certificate or a bag of certificates (a chain).
> 
>  While it wouldn't be attractive to define such extension for
> certificates due to certificate size considerations, CRL's are often of
> such size that including the certs needed to validate it only leads to
> an insignificant increase of size, while it may offer substantial
> processing advantages.
> 
>  I would like to hear the opinion of this group on this.
> 
>  I volunteer to write a first draft if there is interest from the group.
> 
>  
> 
> Stefan Santesson
> 
> Senior Program Manager
> 
> Windows Security, Standards
> 
>  
> 
> ________________________________
> 
> ________________________________
> 

Date: Tue, 19 Sep 2006 11:04:30 +0200
To: "Kemp David P." <[email-masked]>, [email-masked]
From: Christine Karman <[email-masked]>
Subject: RE: large crl's
Sender: [email-masked]

This is a multi-part message in MIME format.

--{C585954F-6927-4963-97F0-BCE5D7259CD6}
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 07:13 PM 9/18/2006, Kemp David P. wrote:

>Yes, the DoD CRLs are the ridiculous result of designing a
>system based on the limitations of then-current products

It would be nice if CA's would use OCSP rather than crl's.

>Several years later,
>browsers have gone through multiple generations of
>improvement,

We don't do brosers, we do email. Think of ten messages per second 
being encrypted or decrypted, with new certificates and possibly new 
crl's coming in all the time. Of course, the number of crl's is 
limited, and we probably have to accept that we don't download larget 
crl's more often than every couplf of hours, or even a day. That does 
mean that if a certificate gets revoked, a hacker will have 24 hours 
to use this compromised certificate.

Another difference between authentication in a browser and email is 
the following. A company archives old email. They have to be able to 
verify validity of digital signatures on incoming email, even for 
certificates that have expired long ago. The DOD will have to have 
that 20Mb crl available forever, unless they switch to online verification.

dagdag
Christine
-- 
Izecom BV
Secure e-mail and digital signatures
www.izecom.com

--{C585954F-6927-4963-97F0-BCE5D7259CD6}
Content-Type: application/x-pkcs7-signature; 
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

--{C585954F-6927-4963-97F0-BCE5D7259CD6}--

Reply-To: "Glynis Coltrane" <[email-masked]>
From: "Glynis Coltrane" <[email-masked]>
To: [email-masked]
Subject: go PHAcfRMA
Date: Mon, 18 Sep 2006 17:15:00 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0047_01C6DB91.9ED4B9C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi
=20

AMBxxIEN

VALxxIUM

VIAxxGRA

CIAxxLIS

=20
Directly from the manufacturer http://www.fendunjinkonmdas.com

------=_NextPart_000_0047_01C6DB91.9ED4B9C0
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<P>AMBxxIEN</P>
<P>VALxxIUM</P>
<P>VIAxxGRA</P>
<P>CIAxxLIS</P>
<DIV>&nbsp;</DIV>
<DIV>Directly from the manufacturer <A =
href=3D"http://www.fendunjinkonmdas.com">http://www.fendunjinkonmdas.com<=
/A></DIV></BODY></HTML>
------=_NextPart_000_0047_01C6DB91.9ED4B9C0--

Date: Mon, 18 Sep 2006 16:18:08 -0700
To: "Kemp David P." <[email-masked]>, <[email-masked]>
From: Hoyt L Kesterson II <[email-masked]>
Subject: RE: large crl's
Sender: [email-masked]

<!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: large crl's</title></head><body>
<div>This was one of two CRL enhancements that were originally
submitted by Japan. They found that company reorganizations&nbsp;
often required a reissuing of certificates - the higher the level of
reorg, the more certificates that had to be revoked and
reissued.</div>
<div><br></div>
<div>This led them to two conclusions.</div>
<div><br></div>
<blockquote>1) bulk creations were sometimes followed by bulk
revocations; these typically were within a range of serial numbers or
within a subtree.</blockquote>
<blockquote><br></blockquote>
<blockquote>2) the revocations were something that could be planned
ahead of time</blockquote>
<blockquote><br></blockquote>
<div>Even though it didn't happen that often, when it did happen, a
range or subtree descriptor could replace a long list of serial
numbers. Thus the revokedGroups extension (8.5.2.11) was
created.</div>
<div><br></div>
<div>Revocations because of reorganizations would normally be planned
well in advance of the date of the revocations. The group thought it
would be useful to have a trusted way to signal that one or more
individually listed certificates, a range of certificates, or those
certificates whose subject/holder name was in a specified subtree
would be revoked at future date and time. Thus came the obscurely
named toBeRevoked extension (8.5.2.10)</div>
<div><br></div>
<div>Granted, an organizationally independent naming scheme would
avoid such problems but sometimes reorgs happen and names are
affected. These extensions could help.</div>
<div><br></div>
<div>&nbsp;&nbsp;&nbsp;&nbsp; hoyt</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div>At 17:39 -0400 9/18/06, Kemp David P. wrote:</div>
<blockquote type="cite" cite>Of course, if your subscribers aren't so
courteous as to<br>
lose their keys, change jobs, or otherwise request revocation<br>
in the order they received their certificates, ranges might<br>
not be that useful anyway :-).<br>
<br>
(I realize that there are circumstances where issuing<br>
and revoking a block of certificates is useful.&nbsp; But those<br>
circumstances are limited.)<br>
<br>
Dave<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: [email-masked]
[mailto:[email-masked]]<br>
On Behalf Of Paul Hoffman<br>
Sent: Monday, September 18, 2006 3:31 PM<br>
To: Hoyt L Kesterson II; [email-masked]<br>
Subject: Re: large crl's<br>
<br>
<br>
At 9:42 AM -0700 9/18/06, Hoyt L Kesterson II wrote:<br>
&gt;The 5th edition of X.509 has added the ability to specify ranges
of<br>
&gt;certificate serial numbers.<br>
&gt;<br>
&gt;Of course, if the SHA-1 problem is handled by appending random<br>
&gt;values onto the serial number, this won't be a useful
extension.<br>
<br>
Is that true? If your starting serial numbers are a fixed number
of<br>
octets (such as four), and you append a fixed number of octets of<br>
randomness, you can still specify ranges, can't you?<br>
<br>
--Paul Hoffman, Director<br>
--VPN Consortium</blockquote>
<div><br></div>
</body>
</html>

Content-class: urn:content-classes:message
Subject: RE: large crl's
Date: Mon, 18 Sep 2006 17:39:05 -0400
From: "Kemp David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Of course, if your subscribers aren't so courteous as to
lose their keys, change jobs, or otherwise request revocation
in the order they received their certificates, ranges might
not be that useful anyway :-).

(I realize that there are circumstances where issuing
and revoking a block of certificates is useful.  But those
circumstances are limited.)

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Paul Hoffman
Sent: Monday, September 18, 2006 3:31 PM
To: Hoyt L Kesterson II; [email-masked]
Subject: Re: large crl's

At 9:42 AM -0700 9/18/06, Hoyt L Kesterson II wrote:
>The 5th edition of X.509 has added the ability to specify ranges of 
>certificate serial numbers.
>
>Of course, if the SHA-1 problem is handled by appending random 
>values onto the serial number, this won't be a useful extension.

Is that true? If your starting serial numbers are a fixed number of 
octets (such as four), and you append a fixed number of octets of 
randomness, you can still specify ranges, can't you?

--Paul Hoffman, Director
--VPN Consortium

Date: Mon, 18 Sep 2006 13:25:05 -0700
To: Paul Hoffman <[email-masked]>, [email-masked]
From: Hoyt L Kesterson II <[email-masked]>
Subject: Re: large crl's
Sender: [email-masked]

You're correct. If the serial number is fixed size and the fixed length most significant part is composed of an increasing value (or decreasing if you decide to be somewhat outré), then the fixed length least significant part can be as random as you please.

   hoyt

At 12:30 -0700 9/18/06, Paul Hoffman wrote:
>At 9:42 AM -0700 9/18/06, Hoyt L Kesterson II wrote:
>>The 5th edition of X.509 has added the ability to specify ranges of certificate serial numbers.
>>
>>Of course, if the SHA-1 problem is handled by appending random values onto the serial number, this won't be a useful extension.
>
>Is that true? If your starting serial numbers are a fixed number of octets (such as four), and you append a fixed number of octets of randomness, you can still specify ranges, can't you?
>
>--Paul Hoffman, Director
>--VPN Consortium

Date: Mon, 18 Sep 2006 12:30:37 -0700
To: Hoyt L Kesterson II <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: large crl's
Sender: [email-masked]

At 9:42 AM -0700 9/18/06, Hoyt L Kesterson II wrote:
>The 5th edition of X.509 has added the ability to specify ranges of 
>certificate serial numbers.
>
>Of course, if the SHA-1 problem is handled by appending random 
>values onto the serial number, this won't be a useful extension.

Is that true? If your starting serial numbers are a fixed number of 
octets (such as four), and you append a fixed number of octets of 
randomness, you can still specify ranges, can't you?

--Paul Hoffman, Director
--VPN Consortium

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Mon, 18 Sep 2006 18:26:41 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I think you are right.

We initially thought of a p7c since it is how we normally store bag of
certs, but in this case that overhead is probably not doing us any good.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> [email-masked]] On Behalf Of Russ Housley
> Sent: den 18 september 2006 08:46
> To: Jean-Marc Desperrier; [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
> 
> I support the idea of carrying a bag 'o certs.  However, I am not use
> what value is added by carrying a p7c.  It seems to be a heavy weight
> way to say SEQUENCE OF Certificate.
> 
> What am I missing?
> 
> Russ
> 
> 
> At 09:21 AM 9/18/2006, Jean-Marc Desperrier wrote:
> 
> >Ryan Hurst wrote:
> >>Have you considered the idea of introducing a new access method to
> the
> >>AIA that would point to a P7c that possibly contained the CRL, its
> >>issuers and maybe the certificates issuers?
> >>
> >I vote for p7c. Most CAs already include an option to distribute CRL
> this way.
> >
> >After reading  RFC 2585, I think it misses something  by not saying
> >a word about the popular option of distributing crl and certificates
> >inside pkcs#7/CMS bags.
> >
> >When RFC 3280bis says that URIs inside a DistributionPointName must
> >point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it
> just
> >making explicit a rule that was already required for proper
> interoperability ?
> >

Date: Mon, 18 Sep 2006 12:37:02 -0400
To: Christine Karman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: large crl's
Cc: [email-masked]
Sender: [email-masked]

At 4:26 PM +0200 9/18/06, Christine Karman wrote:
>Hi,
>I'm more of a lurker here, and I don't know if my question is 
>appropriate in this forum.
>
>We see crl's that are huge, like a DOD crl of 20MB. Assuming that 
>you want to refresh the crl every couple of hours, this can put a 
>strain on an application or a machine. Imagine using wifi at 
>Starbucks, and your mail comes with 40MB of crls. Or an appliance 
>that decrypts 15 msgs/sec and then has to stop for downloading 20MB.
>We're optimizing our code, but wouldn't it be better to limit the 
>size of a crl and rather use multiple crl distribution points?
>
>dagdag
>Christine
>--
Christine,

One cannot limit the size of a CRL, as that implies either not 
putting on new entries, or dropping old entries for certs that have 
not yet expired.  Using multiple CRLDPs is a way of reducing CRL 
size, but if one needs to check for all issued, not expired certs, 
this still does not solve the problem of download a lot of data.

There are other options:

	- use OCSP queries to get revocation status data for certs of 
interest, vs. all certs

	- don't publish a CRL every two hours! or don't fetch one 
every two hours (the gating item in revocation status notification is 
usually the time it takes o decide to revoke a cert, not the time it 
takes to propagate a CRL. I don't think it makes sense for most 
applications to publish a CRL more often that daily.)

Steve

Content-class: urn:content-classes:message
Subject: RE: large crl's
Date: Mon, 18 Sep 2006 13:13:20 -0400
From: "Kemp David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Christine,

Yes, the DoD CRLs are the ridiculous result of designing a
system based on the limitations of then-current products
(the inability of some applications to understand CRLDP)
rather than designing a correct system and expecting
commercial products to evolve.  Several years later,
browsers have gone through multiple generations of
improvement, while DoD PKI is still stuck with dinosaur
CRLs (in both senses: obsolete and huge).

The DoD PKI's (admittedly clever) workaround was to create
OCSP responses that resemble partitioned CRLs - pre-generated
rather than signed on demand, and partitioned into blocks
of 20 or so certificates to avoid generating individual
OCSP responses for every certificate.  Clever though
that solution might be, it would still be more efficient
to just generate small-partitioned CRLs (20-100 certs)
in the first place, because OCSP message overhead is
higher than that of a bare CRL.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Christine Karman
Sent: Monday, September 18, 2006 10:27 AM
To: [email-masked]
Subject: large crl's

Hi,
I'm more of a lurker here, and I don't know if my question is 
appropriate in this forum.

We see crl's that are huge, like a DOD crl of 20MB. Assuming that you 
want to refresh the crl every couple of hours, this can put a strain 
on an application or a machine. Imagine using wifi at Starbucks, and 
your mail comes with 40MB of crls. Or an appliance that decrypts 15 
msgs/sec and then has to stop for downloading 20MB.
We're optimizing our code, but wouldn't it be better to limit the 
size of a crl and rather use multiple crl distribution points?

dagdag
Christine
-- 
Izecom BV
Secure e-mail and digital signatures
www.izecom.com

Date: Mon, 18 Sep 2006 09:42:33 -0700
To: Christine Karman <[email-masked]>, [email-masked]
From: Hoyt L Kesterson II <[email-masked]>
Subject: Re: large crl's
Sender: [email-masked]

The 5th edition of X.509 has added the ability to specify ranges of certificate serial numbers.

Of course, if the SHA-1 problem is handled by appending random values onto the serial number, this won't be a useful extension.

   hoyt

At 16:26 +0200 9/18/06, Christine Karman wrote:
>Hi,
>I'm more of a lurker here, and I don't know if my question is appropriate in this forum.
>
>We see crl's that are huge, like a DOD crl of 20MB. Assuming that you want to refresh the crl every couple of hours, this can put a strain on an application or a machine. Imagine using wifi at Starbucks, and your mail comes with 40MB of crls. Or an appliance that decrypts 15 msgs/sec and then has to stop for downloading 20MB.
>We're optimizing our code, but wouldn't it be better to limit the size of a crl and rather use multiple crl distribution points?
>
>dagdag
>Christine
>--
>Izecom BV
>Secure e-mail and digital signatures
>www.izecom.com
>
>
>Attachment converted: Macintosh HD:smime 122.p7s (    /    ) (001E7ABB)

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Mon, 18 Sep 2006 09:19:55 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>, "Stefan Santesson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DB3E.4085B923
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Before we get too far in this, can we all agree on what concern we are
addressing using this mechanism:

=20

1.	Denial of Service
2.	Network Availability
3.	Security
4.	Response Time
5.	Something else
6.	Combination of the above

=20

I find this mechanism of not great use for 1 and 3.  For 2, most
implementations get CRL from the Network.  It is quite disingenuous to
say that the network will be down after getting a CRL to follow the AIA.

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sharon Boeyen
Sent: Monday, September 18, 2006 9:25 AM
To: 'Stefan Santesson'; Denis Pinkas; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

=20

With respect to indirect CRLs I can see some utility to this feature,
for hopefully just a single certificate (and then use pointers in that
certificate to build the path if there are more differences between that
path and the one used for the certificate being validated). I don't
fully understand the other situation you are proposing this for though
and think I would be uncomfortable if this extension became widely used
for environments other than indirect CRLs. If this is a wider problem
that indirect CRLs, I think I'm leaning to the approach of bundling the
CRL with the bag of certs in a separate structure, enabling environments
that have no problems building paths today without this new feature to
continue doing what they do today and not be forced with having a bag of
certs added to common CRLs. However I do admit to not fully
understanding the problem you are stating so these are just my current
thoughts.

=20

Cheers,

Sharon=20

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
	Sent: Monday, September 18, 2006 8:48 AM
	To: Denis Pinkas; [email-masked]
	Subject: RE: Certs in CRLs - New standards task?

	Hi Denis,

	=20

	Speaking as an implementer and from the experience from how our
own products work, the issue and the solution is much more simple than
the solution you propose.

	=20

	The  validation engine does not need to know which certificate
that represents the old or the new CA key or what the hash of the
certificate is. The task of the validation engine for this issue is
simply to validate the signature of the CRL using a valid path to a
trusted root (being the same used to validate the target certificate).

	=20

	First of all the validation engine will try to build a path
using all certs from the validated path and all cashed and locally
stored certificates and root keys. If this fails it could use the certs
provided in the CRL using this new extension (just a bag of certificates
with no specific information).

	=20

	In the end, if the provided bag of certificates (typically only
1 certificate if present) does not help the RP, we did not do any
particular damage to the RP (just slightly increased the CRL), we just
couldn't help him and he will now have to try directory search etc as
before. But the fact is that by including certificate/s in the CRL we
may in many PKI configurations considerably help the RP.

	=20

	I fully agree that this information can not be stored in an AIA.
A new CRL extension is needed.

	=20

	Finally I don't agree to the term "overloading" here. We usually
use that term to describe when we stretch the semantics of existing
fields and name forms. This is just an new optional non-critical
extension with useful data, relevant to the processing of the CRL.

	=20

	=20

	=20

	Stefan Santesson

	Senior Program Manager

	Windows Security, Standards

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Denis Pinkas
	Sent: den 18 september 2006 00:51
	To: [email-masked]
	Subject: Re: Certs in CRLs - New standards task?

	=20

	Stefan,

	=20

	I am not in favour of the proposed approach.

	=20

	I have concern by always overloading the CRL, not simply with
one additional certificate,=20

	but with two additional certificates, because of CA key
rollover.

	=20

	The situation will be even worse when a CRL issuer is trusted by
more than one CA=20

	to issue CRLs.

	=20

	Talking to you in your capacity of co-chair, I would like to
recall that the full story=20

	of how to check a CRL that is not issued by a CA is still not
crystal clear in 3280bis,=20

	and we should clarify that before. :-)

	=20

	Talking to you as PKIX member, I would favor the use of  one
extension with two pointers per CA:

	=20

	 - one pointing to the current or old certificate still valid,
and=20

	 - another one pointing the new or current certificate already
valid.=20

	=20

	This will allow to fetch once the certificate(s) that is/are
needed.

	=20

	The AIA extension is not the right vehicule, since it cannot
include a hash of the data that is pointed.

	We should add a hash of the certificate, which would allow to
make sure that the right certificate=20

	was obtained without the need to build and verify the
certification path.

	=20

	From the above observations, the problem is much more complex
than originally presented.

	=20

	Denis

	=20

=09
________________________________

	Taking the pkix chair hat off and the vendor hat on

	I'm asking this group to consider a new standards task to solve
a real implementation issue with indirect CRLs and CRLs issued by a
re-keyed CA. I.e. where the target certificate and it's CRL are signed
by different keys and the RP does not have access to the CRL Issuer
certificate.

	It is basically the same situation we solved with allowing the
AIA extension in CRL's namely the problem to obtain the CRL issuer's
certificate, alternatively, certificate path.

	In our efforts to implement the AIA solution we have encountered
some real issues.

	1)       Each time we are forced to go out and retrieve new
information on the network, we have a source of potential problems such
as unavailable network resources, timeouts etc. It all adds to the
validation time and harms the user experience.

	2)       The AIA in CRL's provide another opening for DoS
attacks if rouge CRL's point their AIA to a targeted web server. This is
tough not as serious as the DoS problems with AIA in certificates, but
this one we might avoid more easily.

	 The proposed solution is to define a new CRL extension that may
contain the CRL Issuer certificate (not just a URL to its location).
Preferably this would be a PKCS#7 (or CMS) Certs only message that may
contain a single certificate or a bag of certificates (a chain).

	 While it wouldn't be attractive to define such extension for
certificates due to certificate size considerations, CRL's are often of
such size that including the certs needed to validate it only leads to
an insignificant increase of size, while it may offer substantial
processing advantages.

	 I would like to hear the opinion of this group on this.

	 I volunteer to write a first draft if there is interest from
the group.

	=20

	Stefan Santesson

	Senior Program Manager

	Windows Security, Standards

	=20

=09
________________________________

------_=_NextPart_001_01C6DB3E.4085B923
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Message</title>
<style>
<!--a:link
	{mso-style-priority: 99
;}
span.MSOHYPERLINK
	{mso-style-priority: 99
;}
a:visited
	{mso-style-priority: 99
;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority: 99
;}
p.MSOLISTPARAGRAPH
	{mso-style-priority: 34
;}
li.MSOLISTPARAGRAPH
	{mso-style-priority: 34
;}
div.MSOLISTPARAGRAPH
	{mso-style-priority: 34
;}

 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.msolistparagraph, li.msolistparagraph, div.msolistparagraph
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l2
	{mso-list-id:1376930552;
	mso-list-type:hybrid;
	mso-list-template-ids:875599386 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Before we get too far in this, can =
we all
agree on what concern we are addressing using this =
mechanism:<o:p></o:p></span></font></p>

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

<ol style=3D'margin-top:0in' start=3D1 type=3D1>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l2 level1 =
lfo3'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Denial
     of Service<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l2 level1 =
lfo3'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Network
     Availability<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l2 level1 =
lfo3'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Security<o:p></o:p></span></=
font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l2 level1 =
lfo3'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Response
     Time<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l2 level1 =
lfo3'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Something
     else<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'color:navy;mso-list:l2 level1 =
lfo3'><font size=3D2
     color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Combination
     of the above<o:p></o:p></span></font></li>
</ol>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I find this mechanism of not great =
use for
1 and 3.&nbsp; For 2, most implementations get CRL from the =
Network.&nbsp; It is quite
disingenuous to say that the network will be down after getting a CRL to =
follow
the AIA.<o:p></o:p></span></font></p>

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Sharon Boeyen<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, September =
18, 2006
9:25 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Stefan Santesson'; =
Denis
Pinkas; [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Certs in =
CRLs - New
standards task?</span></font><o:p></o:p></p>

</div>

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

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DSV
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>With respect to =
indirect
CRLs I can see some utility to this feature, for hopefully just a single
certificate (and then use pointers in that certificate to build the path =
if
there are more differences between that path and the one used for the
certificate being validated). I don't fully understand the other =
situation you
are proposing this for though and think I would be uncomfortable if this
extension became widely used for environments other than indirect =
CRLs.&nbsp;If
this is&nbsp;a wider problem that indirect CRLs, I think I'm leaning to =
the
approach of bundling the CRL with the bag&nbsp;of certs in a separate
structure, enabling environments that have no problems building paths =
today
without this new feature to continue doing what they do today and not be
forced&nbsp;with having a bag of certs added to&nbsp;common CRLs. =
However I do
admit to&nbsp;not fully understanding the problem you are stating so =
these are
just my current thoughts.</span></font><span =
lang=3DSV><o:p></o:p></span></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DSV
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Cheers,</span></f=
ont><span
lang=3DSV><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DSV
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Sharon</span></fo=
nt><span
lang=3DSV>&nbsp;<o:p></o:p></span></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, September =
18, 2006
8:48 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Denis Pinkas;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Certs in =
CRLs - New
standards task?</span></font><o:p></o:p></p>

<p class=3DMsoNormal><a name=3D"_MailEndCompose"><font size=3D2 =
color=3D"#1f497d"
face=3DCalibri><span lang=3DSV =
style=3D'font-size:11.0pt;font-family:Calibri;
color:#1F497D'>Hi Denis,</span></font></a><font size=3D2 =
color=3D"#1f497d"
face=3DCalibri><span lang=3DSV =
style=3D'font-size:11.0pt;font-family:Calibri;
color:#1F497D'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span lang=3DSV
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Speaking as =
an
implementer and from the experience from how our own products work, the =
issue
and the solution is much more simple than the solution you =
propose.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>The =
&nbsp;validation
engine does not need to know which certificate that represents the old =
or the
new CA key or what the hash of the certificate is. The task of the =
validation
engine for this issue is simply to validate the signature of the CRL =
using a
valid path to a trusted root (being the same used to validate the target
certificate).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>First of =
all the
validation engine will try to build a path using all certs from the =
validated
path and all cashed and locally stored certificates and root keys. If =
this
fails it could use the certs provided in the CRL using this new =
extension (just
a bag of certificates with no specific =
information).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>In the end, =
if the
provided bag of certificates (typically only 1 certificate if present) =
does not
help the RP, we did not do any particular damage to the RP (just =
slightly
increased the CRL), we just couldn't help him and he will now have to =
try
directory search etc as before. But the fact is that by including =
certificate/s
in the CRL we may in many PKI configurations considerably help the =
RP.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>I fully =
agree that
this information can not be stored in an AIA. A new CRL extension is =
needed.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Finally I =
don't
agree to the term &quot;overloading&quot; here. We usually use that term =
to
describe when we stretch the semantics of existing fields and name =
forms. This
is just an new optional non-critical extension with useful data, =
relevant to
the processing of the CRL.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dmaroon face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:maroon;font-weight:bold=
'>Stefan
Santesson</span></font></b><font color=3D"#1f497d"><span lang=3DEN-GB
style=3D'color:#1F497D'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span lang=3DEN-GB =
style=3D'color:navy'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><b><font size=3D2 color=3D"#400040" =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:#400040;font-weight:bol=
d'>Windows
Security, Standards</span></font></b><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p></o:p><=
/span></font></p>

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

<div>

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
[email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Denis Pinkas<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 18 september =
2006 00:51<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Certs in =
CRLs - New
standards task?<o:p></o:p></span></font></p>

</div>

</div>

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

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>Stefan,<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>I am not in favour of the proposed =
approach.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>I have concern by always overloading the CRL, =
not
simply with one additional certificate, <o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>but with two additional certificates, because =
of CA
key rollover.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>The situation will&nbsp;be even worse when a =
CRL
issuer is trusted by more than one CA <o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>to issue CRLs.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>Talking to you in your capacity =
of&nbsp;co-chair, I
would like to recall that the full story <o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>of how to check a CRL that is not issued by a =
CA is
still not crystal clear in 3280bis, <o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>and we should clarify that before. =
:-)<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>Talking to you as PKIX member, I would favor =
the use
of&nbsp;&nbsp;one extension with two pointers&nbsp;per =
CA:<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>&nbsp;- one&nbsp;pointing to the current or =
old
certificate still valid, and <o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>&nbsp;- another one pointing the new or =
current
certificate already valid. <o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>This will allow to fetch once the =
certificate(s) that
is/are&nbsp;needed.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>The AIA extension is not the right vehicule, =
since it
cannot include a hash of the data that is =
pointed.<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>We should add a hash of the certificate, =
which would
allow to make sure that the right certificate =
<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>was obtained without the need to build and =
verify the
certification path.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DSV
style=3D'font-size:12.0pt'>From the above observations, the problem is =
much more
complex than originally presented.<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

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

</div>

<div>

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

</div>

<div>

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

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

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

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>Taking
the pkix chair hat off and the vendor hat on</span></font><span =
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>I'm
asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed =
CA. I.e.
where the target certificate and it's CRL are signed by different keys =
and the
RP does not have access to the CRL Issuer =
certificate.</span></font><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>It
is basically the same situation we solved with allowing the AIA =
extension in
CRL's namely the problem to obtain the CRL issuer's certificate, =
alternatively,
certificate path.</span></font><span lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>In
our efforts to implement the AIA solution we have encountered some real =
issues.</span></font><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:.5in;text-indent:-.25in'><font size=3D2 face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial'>1)</span></font><font =
size=3D1><span
lang=3DEN-GB =
style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>Each
time we are forced to go out and retrieve new information on the =
network, we
have a source of potential problems such as unavailable network =
resources,
timeouts etc. It all adds to the validation time and harms the user =
experience.</span></font><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:.5in;text-indent:-.25in'><font size=3D2 face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial'>2)</span></font><font =
size=3D1><span
lang=3DEN-GB =
style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>The
AIA in CRL's provide another opening for DoS attacks if rouge CRL's =
point their
AIA to a targeted web server. This is tough not as serious as the DoS =
problems
with AIA in certificates, but this one we might avoid more =
easily.</span></font><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;The
proposed solution is to define a new CRL extension that may contain the =
CRL
Issuer certificate (not just a URL to its location). Preferably this =
would be a
PKCS#7 (or CMS) Certs only message that may contain a single certificate =
or a
bag of certificates (a chain).</span></font><span =
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;While
it wouldn't be attractive to define such extension for certificates due =
to
certificate size considerations, CRL's are often of such size that =
including
the certs needed to validate it only leads to an insignificant increase =
of
size, while it may offer substantial processing =
advantages.</span></font><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;I
would like to hear the opinion of this group on this.</span></font><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;I
volunteer to write a first draft if there is interest from the =
group.</span></font><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;</span></font><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><strong><b><=
font
size=3D2 color=3Dmaroon face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D2 color=3D"#400040" face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:Arial;color:#400040'>Senior Program =
Manager</span></font><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><strong><b><=
font
size=3D2 color=3D"#400040" face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:Arial;color:#400040'>Windows Security, =
Standards</span></font></b></strong><span
lang=3DSV><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D3 face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:12.0pt'>&nbsp;</span></font><span
lang=3DSV><o:p></o:p></span></p>

</div>

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

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

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

</div>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C6DB3E.4085B923--

Date: Mon, 18 Sep 2006 11:45:48 -0400
To: Jean-Marc Desperrier <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Certs in CRLs - New standards task?
Sender: [email-masked]

I support the idea of carrying a bag 'o certs.  However, I am not use 
what value is added by carrying a p7c.  It seems to be a heavy weight 
way to say SEQUENCE OF Certificate.

What am I missing?

Russ

At 09:21 AM 9/18/2006, Jean-Marc Desperrier wrote:

>Ryan Hurst wrote:
>>Have you considered the idea of introducing a new access method to the
>>AIA that would point to a P7c that possibly contained the CRL, its
>>issuers and maybe the certificates issuers?
>>
>I vote for p7c. Most CAs already include an option to distribute CRL this way.
>
>After reading  RFC 2585, I think it misses something  by not saying 
>a word about the popular option of distributing crl and certificates 
>inside pkcs#7/CMS bags.
>
>When RFC 3280bis says that URIs inside a DistributionPointName must 
>point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it just
>making explicit a rule that was already required for proper interoperability ?
>

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Mon, 18 Sep 2006 16:46:16 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

The problems with introducing a CRL bundled with certificates in a p7c
file linked through AIA is: 

1) It violates the defined usage of AIA.
2) It confuses the picture for implementers whether they should use CDP
or use AIA for CRL retrieval.
3) It confuses the CDP distribution point matching between IDP and CDP.

Therefore, I don't like it.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> [email-masked]] On Behalf Of Jean-Marc Desperrier
> Sent: den 18 september 2006 06:22
> To: [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
> 
> Ryan Hurst wrote:
> > Have you considered the idea of introducing a new access method to
> the
> > AIA that would point to a P7c that possibly contained the CRL, its
> > issuers and maybe the certificates issuers?
> >
> I vote for p7c. Most CAs already include an option to distribute CRL
> this way.
> 
> After reading  RFC 2585, I think it misses something  by not saying a
> word about the popular option of distributing crl and certificates
> inside pkcs#7/CMS bags.
> 
> When RFC 3280bis says that URIs inside a DistributionPointName must
> point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it
just
> making explicit a rule that was already required for proper
> interoperability ?

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Mon, 18 Sep 2006 16:41:29 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DB38.E97E4E85
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Denis,

=20

When this is not a good solution to your problem, then don't use it.

=20

Why MUST is be bad to send the certs with every CRL if the alternative
is to go out on the network and fetch the certificates using extra
cycles.

I may use the same CRL 100+ times before it expires for many different
certificates. We send certificates with every OCSP response and we don't
consider that a problem.=20

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: den 18 september 2006 06:10
To: [email-masked]
Subject: Re: Certs in CRLs - New standards task?

=20

________________________________

Stefan,=20

My replies have [Denis] in front of them.

Hi Denis,

Speaking as an implementer and from the experience from how our own
products work, the issue and the solution is much more simple than the
solution you propose.

 The  validation engine does not need to know which certificate that
represents the old or the new CA key or what the hash of the certificate
is. The task of the validation engine for this issue is simply to
validate the signature of the CRL using a valid path to a trusted root
(being the same used to validate the target certificate).

[Denis]  I disagree. Before the "validation engine" there is the "path
construction engine". Depending upon whether key rollover has been or
has not been performed by the relying party, one or two certificates may
be needed. If the CRL issuer is servings multiple CAs, then a couple of
certificates are needed for each CA. If we define a new extension, it
MUST also be usable for a single CRL issued for different CAs.

First of all the validation engine will try to build a path using all
certs from the validated path and all cashed and locally stored
certificates and root keys. If this fails it could use the certs
provided in the CRL using this new extension (just a bag of certificates
with no specific information).

[Denis] Ahhhhh! you just crossed the line: a bag of certificates !

 In the end, if the provided bag of certificates (typically only 1
certificate if present) does not help the RP, we did not do any
particular damage to the RP (just slightly increased the CRL), we just
couldn't help him and he will now have to try directory search etc as
before. But the fact is that by including certificate/s in the CRL we
may in many PKI configurations considerably help the RP.

[Denis] You will need to transfer that bag of certificates every time.
This is not good. Instead of trying to convince that the initially
proposed solution is the best, please take some time to consider the
benefits and drawbacks of the other solution I proposed.

I fully agree that this information can not be stored in an AIA. A new
CRL extension is needed.

Finally I don't agree to the term "overloading" here. We usually use
that term to describe when we stretch the semantics of existing fields
and name forms. This is just an new optional non-critical extension with
useful data, relevant to the processing of the CRL.

Denis=20

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: den 18 september 2006 00:51
To: [email-masked]
Subject: Re: Certs in CRLs - New standards task?

=20

Stefan,

=20

I am not in favour of the proposed approach.

=20

I have concern by always overloading the CRL, not simply with one
additional certificate,=20

but with two additional certificates, because of CA key rollover.

=20

The situation will be even worse when a CRL issuer is trusted by more
than one CA=20

to issue CRLs.

=20

Talking to you in your capacity of co-chair, I would like to recall that
the full story=20

of how to check a CRL that is not issued by a CA is still not crystal
clear in 3280bis,=20

and we should clarify that before. :-)

=20

Talking to you as PKIX member, I would favor the use of  one extension
with two pointers per CA:

=20

 - one pointing to the current or old certificate still valid, and=20

 - another one pointing the new or current certificate already valid.=20

=20

This will allow to fetch once the certificate(s) that is/are needed.

=20

The AIA extension is not the right vehicule, since it cannot include a
hash of the data that is pointed.

We should add a hash of the certificate, which would allow to make sure
that the right certificate=20

was obtained without the need to build and verify the certification
path.

=20

>From the above observations, the problem is much more complex than
originally presented.

=20

Denis

=20

________________________________

Taking the pkix chair hat off and the vendor hat on

I'm asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed
CA. I.e. where the target certificate and it's CRL are signed by
different keys and the RP does not have access to the CRL Issuer
certificate.

It is basically the same situation we solved with allowing the AIA
extension in CRL's namely the problem to obtain the CRL issuer's
certificate, alternatively, certificate path.

In our efforts to implement the AIA solution we have encountered some
real issues.

1)       Each time we are forced to go out and retrieve new information
on the network, we have a source of potential problems such as
unavailable network resources, timeouts etc. It all adds to the
validation time and harms the user experience.

2)       The AIA in CRL's provide another opening for DoS attacks if
rouge CRL's point their AIA to a targeted web server. This is tough not
as serious as the DoS problems with AIA in certificates, but this one we
might avoid more easily.

 The proposed solution is to define a new CRL extension that may contain
the CRL Issuer certificate (not just a URL to its location). Preferably
this would be a PKCS#7 (or CMS) Certs only message that may contain a
single certificate or a bag of certificates (a chain).

 While it wouldn't be attractive to define such extension for
certificates due to certificate size considerations, CRL's are often of
such size that including the certs needed to validate it only leads to
an insignificant increase of size, while it may offer substantial
processing advantages.

 I would like to hear the opinion of this group on this.

 I volunteer to write a first draft if there is interest from the group.

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

________________________________

________________________________

------_=_NextPart_001_01C6DB38.E97E4E85
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>When this is not a good solution to your problem, then =
don&#8217;t
use it.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Why MUST is be bad to send the certs with every CRL if =
the
alternative is to go out on the network and fetch the certificates using =
extra
cycles.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I may use the same CRL 100+ times before it expires for =
many
different certificates. We send certificates with every OCSP response =
and we
don&#8217;t consider that a problem. <o:p></o:p></span></p>

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

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

<div>

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

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

</div>

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

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

<div>

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

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked] =
[mailto:[email-masked]]
<b>On Behalf Of </b>Denis Pinkas<br>
<b>Sent:</b> den 18 september 2006 06:10<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Re: Certs in CRLs - New standards =
task?<o:p></o:p></span></p>

</div>

</div>

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

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

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

</div>

<p class=3DMsoNormal>Stefan, <o:p></o:p></p>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>My
replies have [Denis] in front of them.<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>Hi
Denis,</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Speaking as an implementer and from the experience from =
how our
own products work, the issue and the solution is much more simple than =
the
solution you propose.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;The &nbsp;validation engine does not need to know =
which
certificate that represents the old or the new CA key or what the hash =
of the
certificate is. The task of the validation engine for this issue is =
simply to
validate the signature of the CRL using a valid path to a trusted root =
(being
the same used to validate the target certificate).</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>[Denis]&nbsp; I disagree. Before the &quot;validation
engine&quot; there is the &quot;path construction engine&quot;. =
Depending upon
whether key rollover has been or has not been performed by the relying =
party,
one or two certificates may be needed. If the CRL issuer is servings =
multiple
CAs, then a couple of certificates are needed for each CA. If we define =
a new
extension, it MUST&nbsp;also be usable&nbsp;for a single CRL issued for
different CAs.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>First of all the validation engine will try to build a =
path
using all certs from the validated path and all cashed and locally =
stored
certificates and root keys. If this fails it could use the certs =
provided in
the CRL using this new extension (just a bag of certificates with no =
specific
information).</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>[Denis] Ahhhhh! you just crossed the line: a bag of =
certificates
!</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;In the end, if the provided bag of certificates =
(typically
only 1 certificate if present) does not help the RP, we did not do any
particular damage to the RP (just slightly increased the CRL), we just
couldn&#8217;t help him and he will now have to try directory search etc =
as
before. But the fact is that by including certificate/s in the CRL we =
may in
many PKI configurations considerably help the RP.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>[Denis] You will need to transfer that bag of =
certificates every
time. This is not good. Instead of trying to convince that the initially
proposed solution is the best, please take some time to consider the =
benefits
and drawbacks of the other solution I proposed.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I fully agree that this information can not be stored in =
an AIA.
A new CRL extension is needed.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Finally I don&#8217;t agree to the term
&#8220;overloading&#8221; here. We usually use that term to describe =
when we
stretch the semantics of existing fields and name forms. This is just an =
new
optional non-critical extension with useful data, relevant to the =
processing of
the CRL.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Denis&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:maroon'>=
Stefan
Santesson</span></b><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#400040'=
>Senior
Program Manager</span><o:p></o:p></p>

</div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#400040'=
>Windows
Security, Standards</span></b><o:p></o:p></p>

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

<div>

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

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On =
Behalf
Of </b>Denis Pinkas<br>
<b>Sent:</b> den 18 september 2006 00:51<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Re: Certs in CRLs - New standards =
task?</span><o:p></o:p></p>

</div>

</div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Stefan,<o:p>=
</o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I
am not in favour of the proposed approach.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I
have concern by always overloading the CRL, not simply with one =
additional
certificate, <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>but
with two additional certificates, because of CA key =
rollover.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The
situation will&nbsp;be even worse when a CRL issuer is trusted by more =
than one
CA <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>to
issue CRLs.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Talking
to you in your capacity of&nbsp;co-chair, I would like to recall that =
the full
story <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>of
how to check a CRL that is not issued by a CA is still not crystal clear =
in
3280bis, <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>and
we should clarify that before. :-)<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Talking
to you as PKIX member, I would favor the use of&nbsp;&nbsp;one extension =
with
two pointers&nbsp;per CA:<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;-
one&nbsp;pointing to the current or old certificate still valid, and =
<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;-
another one pointing the new or current certificate already valid. =
<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>This
will allow to fetch once the certificate(s) that =
is/are&nbsp;needed.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The
AIA extension is not the right vehicule, since it cannot include a hash =
of the
data that is pointed.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>We
should add a hash of the certificate, which would allow to make sure =
that the
right certificate <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>was
obtained without the need to build and verify the certification =
path.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>From
the above observations, the problem is much more complex than originally =
presented.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Denis<o:p></=
o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p><=
/o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

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

</div>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Taking the
pkix chair hat off and the vendor hat on</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I&#8217;m
asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed =
CA. I.e.
where the target certificate and it&#8217;s CRL are signed by different =
keys
and the RP does not have access to the CRL Issuer =
certificate.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>It is
basically the same situation we solved with allowing the AIA extension =
in
CRL&#8217;s namely the problem to obtain the CRL issuer&#8217;s =
certificate,
alternatively, certificate path.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>In our
efforts to implement the AIA solution we have encountered some real =
issues.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif"'>1)</span><span lang=3DEN-GB =
style=3D'font-size:
7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Each time we =
are
forced to go out and retrieve new information on the network, we have a =
source
of potential problems such as unavailable network resources, timeouts =
etc. It
all adds to the validation time and harms the user =
experience.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif"'>2)</span><span lang=3DEN-GB =
style=3D'font-size:
7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>The AIA in
CRL&#8217;s provide another opening for DoS attacks if rouge CRL&#8217;s =
point
their AIA to a targeted web server. This is tough not as serious as the =
DoS
problems with AIA in certificates, but this one we might avoid more =
easily.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;The
proposed solution is to define a new CRL extension that may contain the =
CRL
Issuer certificate (not just a URL to its location). Preferably this =
would be a
PKCS#7 (or CMS) Certs only message that may contain a single certificate =
or a
bag of certificates (a chain).</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;While
it wouldn&#8217;t be attractive to define such extension for =
certificates due
to certificate size considerations, CRL&#8217;s are often of such size =
that
including the certs needed to validate it only leads to an insignificant
increase of size, while it may offer substantial processing =
advantages.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;I
would like to hear the opinion of this group on =
this.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;I
volunteer to write a first draft if there is interest from the =
group.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;</span>=
<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><strong><spa=
n
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:maroon'>=
Stefan
Santesson</span></strong><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#400040'=
>Senior
Program Manager</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><strong><spa=
n
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#400040'=
>Windows
Security, Standards</span></strong><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB>&nbsp;</span><o:p></o:p></p>

</div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

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

</div>

</div>

</div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

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

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C6DB38.E97E4E85--

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Mon, 18 Sep 2006 16:32:29 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Sharon Boeyen" <[email-masked]>, "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DB37.A9458305
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Sharon,

=20

Yes, this applies only to CRLs issued by a different key than the target
certificate. The case it may be used is for indirect CRLs and for CRLs
issued by a re-keyed CA.

In both cases there might be situations where you need more than 1
certificate to link back to the path of the target certificate. For
indirect CRLs if the trust in the CRL issuer is provided not by the
target CA but a parent to the target CA. For the re-keyed CA case of you
have don more than 1 CA re-key during the lifetime of the certificate.

=20

Non of these cases are recommended practice, but we want to be able to
process them if customers choose this practice anyway for some reason.

=20

We already have a structure for a bag of certificates (PKCS#7/CMS certs
only message) which already is used in cert storage so I would propose
using that format.

=20

Finally regarding size. In most scenarios where this is a candidate
solution, the network load is simply not an issue. In cases where
network load is an issue you may not want to use this solution. This is
definitely not a mandatory feature. In scenarios where you use
pre-fetched CRLs and http proxy techniques for CRL distribution, the CRL
size increase will also be a negligible factor. In high latency (but
often high speed) networks this will be a great win due to fewer network
cycles (No need to go look for certificates).

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: Sharon Boeyen [mailto:[email-masked]]=20
Sent: den 18 september 2006 07:08
To: Sharon Boeyen; Stefan Santesson; Denis Pinkas; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

=20

A further concern with putting certificate(s) in CRLs really is the
impact of the size of the CRL on network load. Although this might be ok
on a LAN - what about a wireless segment or the connection between a CA
and its ISP? In practice, we find that often partitioned CRLs are no
larger, or only slightly larger than an OCSP response. Even adding one
certificate could make that CRL at least 3 times larger.=20

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sharon Boeyen
	Sent: Monday, September 18, 2006 9:25 AM
	To: 'Stefan Santesson'; Denis Pinkas; [email-masked]
	Subject: RE: Certs in CRLs - New standards task?

	With respect to indirect CRLs I can see some utility to this
feature, for hopefully just a single certificate (and then use pointers
in that certificate to build the path if there are more differences
between that path and the one used for the certificate being validated).
I don't fully understand the other situation you are proposing this for
though and think I would be uncomfortable if this extension became
widely used for environments other than indirect CRLs. If this is a
wider problem that indirect CRLs, I think I'm leaning to the approach of
bundling the CRL with the bag of certs in a separate structure, enabling
environments that have no problems building paths today without this new
feature to continue doing what they do today and not be forced with
having a bag of certs added to common CRLs. However I do admit to not
fully understanding the problem you are stating so these are just my
current thoughts.

	=20

	Cheers,

	Sharon=20

		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
		Sent: Monday, September 18, 2006 8:48 AM
		To: Denis Pinkas; [email-masked]
		Subject: RE: Certs in CRLs - New standards task?

		Hi Denis,

		=20

		Speaking as an implementer and from the experience from
how our own products work, the issue and the solution is much more
simple than the solution you propose.

		=20

		The  validation engine does not need to know which
certificate that represents the old or the new CA key or what the hash
of the certificate is. The task of the validation engine for this issue
is simply to validate the signature of the CRL using a valid path to a
trusted root (being the same used to validate the target certificate).

		=20

		First of all the validation engine will try to build a
path using all certs from the validated path and all cashed and locally
stored certificates and root keys. If this fails it could use the certs
provided in the CRL using this new extension (just a bag of certificates
with no specific information).

		=20

		In the end, if the provided bag of certificates
(typically only 1 certificate if present) does not help the RP, we did
not do any particular damage to the RP (just slightly increased the
CRL), we just couldn't help him and he will now have to try directory
search etc as before. But the fact is that by including certificate/s in
the CRL we may in many PKI configurations considerably help the RP.

		=20

		I fully agree that this information can not be stored in
an AIA. A new CRL extension is needed.

		=20

		Finally I don't agree to the term "overloading" here. We
usually use that term to describe when we stretch the semantics of
existing fields and name forms. This is just an new optional
non-critical extension with useful data, relevant to the processing of
the CRL.

		=20

		=20

		=20

		Stefan Santesson

		Senior Program Manager

		Windows Security, Standards

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Denis Pinkas
		Sent: den 18 september 2006 00:51
		To: [email-masked]
		Subject: Re: Certs in CRLs - New standards task?

		=20

		Stefan,

		=20

		I am not in favour of the proposed approach.

		=20

		I have concern by always overloading the CRL, not simply
with one additional certificate,=20

		but with two additional certificates, because of CA key
rollover.

		=20

		The situation will be even worse when a CRL issuer is
trusted by more than one CA=20

		to issue CRLs.

		=20

		Talking to you in your capacity of co-chair, I would
like to recall that the full story=20

		of how to check a CRL that is not issued by a CA is
still not crystal clear in 3280bis,=20

		and we should clarify that before. :-)

		=20

		Talking to you as PKIX member, I would favor the use of
one extension with two pointers per CA:

		=20

		 - one pointing to the current or old certificate still
valid, and=20

		 - another one pointing the new or current certificate
already valid.=20

		=20

		This will allow to fetch once the certificate(s) that
is/are needed.

		=20

		The AIA extension is not the right vehicule, since it
cannot include a hash of the data that is pointed.

		We should add a hash of the certificate, which would
allow to make sure that the right certificate=20

		was obtained without the need to build and verify the
certification path.

		=20

		From the above observations, the problem is much more
complex than originally presented.

		=20

		Denis

		=20

________________________________

		Taking the pkix chair hat off and the vendor hat on

		I'm asking this group to consider a new standards task
to solve a real implementation issue with indirect CRLs and CRLs issued
by a re-keyed CA. I.e. where the target certificate and it's CRL are
signed by different keys and the RP does not have access to the CRL
Issuer certificate.

		It is basically the same situation we solved with
allowing the AIA extension in CRL's namely the problem to obtain the CRL
issuer's certificate, alternatively, certificate path.

		In our efforts to implement the AIA solution we have
encountered some real issues.

		1)       Each time we are forced to go out and retrieve
new information on the network, we have a source of potential problems
such as unavailable network resources, timeouts etc. It all adds to the
validation time and harms the user experience.

		2)       The AIA in CRL's provide another opening for
DoS attacks if rouge CRL's point their AIA to a targeted web server.
This is tough not as serious as the DoS problems with AIA in
certificates, but this one we might avoid more easily.

		 The proposed solution is to define a new CRL extension
that may contain the CRL Issuer certificate (not just a URL to its
location). Preferably this would be a PKCS#7 (or CMS) Certs only message
that may contain a single certificate or a bag of certificates (a
chain).

		 While it wouldn't be attractive to define such
extension for certificates due to certificate size considerations, CRL's
are often of such size that including the certs needed to validate it
only leads to an insignificant increase of size, while it may offer
substantial processing advantages.

		 I would like to hear the opinion of this group on this.

		 I volunteer to write a first draft if there is interest
from the group.

		=20

		Stefan Santesson

		Senior Program Manager

		Windows Security, Standards

		=20

________________________________

------_=_NextPart_001_01C6DB37.A9458305
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Yes, this applies only to CRLs issued by a different key =
than
the target certificate. The case it may be used is for indirect CRLs and =
for
CRLs issued by a re-keyed CA.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In both cases there might be situations where you need =
more than
1 certificate to link back to the path of the target certificate. For =
indirect
CRLs if the trust in the CRL issuer is provided not by the target CA but =
a
parent to the target CA. For the re-keyed CA case of you have don more =
than 1
CA re-key during the lifetime of the certificate.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Non of these cases are recommended practice, but we want =
to be
able to process them if customers choose this practice anyway for some =
reason.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>We already have a structure for a bag of certificates =
(PKCS#7/CMS
certs only message) which already is used in cert storage so I would =
propose
using that format.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Finally regarding size. In most scenarios where this is a
candidate solution, the network load is simply not an issue. In cases =
where
network load is an issue you may not want to use this solution. This is
definitely not a mandatory feature. In scenarios where you use =
pre-fetched CRLs
and http proxy techniques for CRL distribution, the CRL size increase =
will also
be a negligible factor. In high latency (but often high speed) networks =
this
will be a great win due to fewer network cycles (No need to go look for
certificates).<o:p></o:p></span></p>

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

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

<div>

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

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

</div>

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

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

<div>

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

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Sharon Boeyen
[mailto:[email-masked]] <br>
<b>Sent:</b> den 18 september 2006 07:08<br>
<b>To:</b> Sharon Boeyen; Stefan Santesson; Denis Pinkas; =
[email-masked]<br>
<b>Subject:</b> RE: Certs in CRLs - New standards =
task?<o:p></o:p></span></p>

</div>

</div>

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

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>A further concern with putting certificate(s) in CRLs really =
is the
impact of the size of the CRL on network load. Although this might be ok =
on a
LAN - what about a wireless segment or the connection between a CA and =
its ISP?
In practice, we find that often partitioned CRLs are no larger, or only
slightly larger than an OCSP response. Even adding one certificate could =
make
that CRL at least 3 times larger. </span><o:p></o:p></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>-----Origina=
l
Message-----<br>
<b>From:</b> [email-masked] =
[mailto:[email-masked]]
<b>On Behalf Of </b>Sharon Boeyen<br>
<b>Sent:</b> Monday, September 18, 2006 9:25 AM<br>
<b>To:</b> 'Stefan Santesson'; Denis Pinkas; [email-masked]<br>
<b>Subject:</b> RE: Certs in CRLs - New standards task?</span><span =
lang=3DEN-US><o:p></o:p></span></p>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>With respect to indirect CRLs I can see some utility to this
feature, for hopefully just a single certificate (and then use pointers =
in that
certificate to build the path if there are more differences between that =
path
and the one used for the certificate being validated). I don't fully =
understand
the other situation you are proposing this for though and think I would =
be
uncomfortable if this extension became widely used for environments =
other than
indirect CRLs.&nbsp;If this is&nbsp;a wider problem that indirect CRLs, =
I think
I'm leaning to the approach of bundling the CRL with the bag&nbsp;of =
certs in a
separate structure, enabling environments that have no problems building =
paths
today without this new feature to continue doing what they do today and =
not be
forced&nbsp;with having a bag of certs added to&nbsp;common CRLs. =
However I do
admit to&nbsp;not fully understanding the problem you are stating so =
these are
just my current thoughts.</span><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Cheers,</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Sharon</span>&nbsp;<o:p></o:p></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>-----Origina=
l
Message-----<br>
<b>From:</b> [email-masked] =
[mailto:[email-masked]]
<b>On Behalf Of </b>Stefan Santesson<br>
<b>Sent:</b> Monday, September 18, 2006 8:48 AM<br>
<b>To:</b> Denis Pinkas; [email-masked]<br>
<b>Subject:</b> RE: Certs in CRLs - New standards task?</span><span =
lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi Denis,<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Speaking as an implementer and from the experience from =
how our
own products work, the issue and the solution is much more simple than =
the
solution you propose.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The &nbsp;validation engine does not need to know which
certificate that represents the old or the new CA key or what the hash =
of the
certificate is. The task of the validation engine for this issue is =
simply to
validate the signature of the CRL using a valid path to a trusted root =
(being
the same used to validate the target certificate).<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>First of all the validation engine will try to build a =
path
using all certs from the validated path and all cashed and locally =
stored
certificates and root keys. If this fails it could use the certs =
provided in
the CRL using this new extension (just a bag of certificates with no =
specific
information).<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In the end, if the provided bag of certificates =
(typically only
1 certificate if present) does not help the RP, we did not do any =
particular
damage to the RP (just slightly increased the CRL), we just couldn't =
help him
and he will now have to try directory search etc as before. But the fact =
is
that by including certificate/s in the CRL we may in many PKI =
configurations
considerably help the RP.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I fully agree that this information can not be stored in =
an AIA.
A new CRL extension is needed.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Finally I don't agree to the term &quot;overloading&quot; =
here.
We usually use that term to describe when we stretch the semantics of =
existing
fields and name forms. This is just an new optional non-critical =
extension with
useful data, relevant to the processing of the =
CRL.<o:p></o:p></span></p>

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

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

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

<div>

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

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

</div>

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

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

<div>

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

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Denis =
Pinkas<br>
<b>Sent:</b> den 18 september 2006 00:51<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Re: Certs in CRLs - New standards =
task?<o:p></o:p></span></p>

</div>

</div>

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

<div>

<p class=3DMsoNormal>Stefan,<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>I am not in favour of the proposed =
approach.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>I have concern by always overloading the CRL, not =
simply
with one additional certificate, <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>but with two additional certificates, because of CA =
key
rollover.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>The situation will&nbsp;be even worse when a CRL =
issuer is
trusted by more than one CA <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>to issue CRLs.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>Talking to you in your capacity of&nbsp;co-chair, I =
would
like to recall that the full story <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>of how to check a CRL that is not issued by a CA is =
still
not crystal clear in 3280bis, <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>and we should clarify that before. =
:-)<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>Talking to you as PKIX member, I would favor the =
use
of&nbsp;&nbsp;one extension with two pointers&nbsp;per =
CA:<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>&nbsp;- one&nbsp;pointing to the current or old =
certificate
still valid, and <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;- another one pointing the new or current =
certificate
already valid. <o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>This will allow to fetch once the certificate(s) =
that
is/are&nbsp;needed.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>The AIA extension is not the right vehicule, since =
it cannot
include a hash of the data that is pointed.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>We should add a hash of the certificate, which =
would allow
to make sure that the right certificate <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>was obtained without the need to build and verify =
the
certification path.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>From the above observations, the problem is much =
more
complex than originally presented.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>Denis<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

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

</div>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Taking the
pkix chair hat off and the vendor hat on</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I'm asking
this group to consider a new standards task to solve a real =
implementation
issue with indirect CRLs and CRLs issued by a re-keyed CA. I.e. where =
the
target certificate and it's CRL are signed by different keys and the RP =
does
not have access to the CRL Issuer certificate.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>It is
basically the same situation we solved with allowing the AIA extension =
in CRL's
namely the problem to obtain the CRL issuer's certificate, =
alternatively,
certificate path.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>In our
efforts to implement the AIA solution we have encountered some real =
issues.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif"'>1)</span><span lang=3DEN-GB =
style=3D'font-size:
7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Each time we =
are
forced to go out and retrieve new information on the network, we have a =
source
of potential problems such as unavailable network resources, timeouts =
etc. It
all adds to the validation time and harms the user =
experience.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif"'>2)</span><span lang=3DEN-GB =
style=3D'font-size:
7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>The AIA in =
CRL's
provide another opening for DoS attacks if rouge CRL's point their AIA =
to a
targeted web server. This is tough not as serious as the DoS problems =
with AIA
in certificates, but this one we might avoid more =
easily.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;The
proposed solution is to define a new CRL extension that may contain the =
CRL
Issuer certificate (not just a URL to its location). Preferably this =
would be a
PKCS#7 (or CMS) Certs only message that may contain a single certificate =
or a
bag of certificates (a chain).</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;While
it wouldn't be attractive to define such extension for certificates due =
to
certificate size considerations, CRL's are often of such size that =
including
the certs needed to validate it only leads to an insignificant increase =
of
size, while it may offer substantial processing =
advantages.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;I
would like to hear the opinion of this group on =
this.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;I
volunteer to write a first draft if there is interest from the =
group.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;</span>=
<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><strong><spa=
n
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:maroon'>=
Stefan
Santesson</span></strong><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#400040'=
>Senior
Program Manager</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><strong><spa=
n
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#400040'=
>Windows
Security, Standards</span></strong><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB>&nbsp;</span><o:p></o:p></p>

</div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

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

</div>

</div>

</blockquote>

</blockquote>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C6DB37.A9458305--

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Mon, 18 Sep 2006 10:51:20 -0400
From: "Kemp David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Two of the Big 3 cert consuming protocols (IPSec, TLS, and CMS) already
are designed to transport any needed combination of certificates and
CRLs.
The third (TLS) has no mechanism for transmitting CRLs at all,
regardless of whether a CRL has embedded certs.

-----------------------------------------------------------
RFC 4306 (IKE) defines Certificate payload type 13: "Hash and URL of
X.509 Bundle" which carries a pointer to a bundle of certificates:

  CertificateBundle ::= SEQUENCE OF CertificateOrCRL

  CertificateOrCRL ::= CHOICE {
    cert [0] Certificate,
    crl  [1] CertificateList }

  Hash and URL encodings (12-13) allow IKE messages to remain short
  by replacing long data structures with a 20 octet SHA-1 hash (see
  [SHA]) of the replaced value followed by a variable-length URL
  that resolves to the DER encoded data structure itself.  This
  improves efficiency when the endpoints have certificate data
  cached and makes IKE less subject to denial of service attacks
  that become easier to mount when IKE messages are large enough to
  require IP fragmentation [KPS03].

-----------------------------------------------------------
RFC 3369 (CMS) includes similar bags of certificates and CRLs for
its SignedData and EnvelopedData structures:

  OriginatorInfo ::= SEQUENCE {
     certs [0] IMPLICIT CertificateSet OPTIONAL,
     crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }

  certificates is a collection of certificates.  It is intended that
  the set of certificates be sufficient to contain chains from a
  recognized "root" or "top-level certification authority" to all of
  the signers in the signerInfos field.  There may be more
  certificates than necessary, and there may be certificates
  sufficient to contain chains from two or more independent top-
  level certification authorities.  There may also be fewer
  certificates than necessary, if it is expected that recipients
  have an alternate means of obtaining necessary certificates (e.g.,
  from a previous set of certificates).  The signer's certificate
  MAY be included.  The use of version 1 attribute certificates is
  strongly discouraged.

  crls is a collection of certificate revocation lists (CRLs).  It
  is intended that the set contain information sufficient to
  determine whether or not the certificates in the certificates
  field are valid, but such correspondence is not necessary.  There
  MAY be more CRLs than necessary, and there MAY also be fewer CRLs
  than necessary.

-----------------------------------------------------------
RFC 4387 (Certificate Store Access via HTTP) specifies a simple
query/response protocol that returns certs or CRLs that match
individual HTTP GET queries.  The World Wide Web seems to survive
pretty well using a document structure that includes HTML/XML
markup with links to images displayed within a document.
The Web has not found it necessary or desirable to use HTML/XML
documents with embedded image data (as opposed to links) in order
to improve efficiency.  Images, Certs, and CRLs are all examples
of standalone data blobs that can be retrieved sequentially with
acceptable performance.  I've never heard anyone propose that
because sometimes external images fail to load, the optimum
solution is to imbed image data into referencing documents.

To improve the performance and availability of systems that 
consume both CRLs and CRL issuer certificates, the design
pattern to be followed is to leave Certs and CRLs as
independent data units but make them available from the
same repository or within the same IKE payload or CMS message.
If the repository is up, both CRL and cert can be retrieved
over a single TCP handshake.  If an IKE or CMS protocol data
unit is received, it can be structured to contain all data
needed to support path validation without requiring any
changes to the existing protocols.  The bags/bundles within
these protocols were explicitly designed for flexibility
(as opposed to TLS's rigid certificate path with no CRLs);
that flexibility is the system designer's friend.

IMO, improving implementations of the existing standards is
preferable to 1) creating new syntax, and 2) establishing
a design pattern of embedding certificates within CRLs or
vice versa.  From an architectural perspective, 2) is even
uglier than 1).

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tom Gindin
Sent: Saturday, September 16, 2006 5:44 PM
To: Hallam-Baker, Phillip
Cc: [email-masked]; Stefan Santesson; Stephen Farrell
Subject: RE: Certs in CRLs - New standards task?

        Phill:

        IMHO that's even uglier than defining an OTHER-NAME type 
containing a certificate.  Such a definition would have other uses, most

of which would be equally ugly - just think of an issuer Alt Name with
the 
full text of the CA certificate inside.  A CRL-specific extension has
got 
to be cleaner than these.

                Tom Gindin

"Hallam-Baker, Phillip" <[email-masked]> 
Sent by: [email-masked]
09/14/2006 02:05 PM

To
"Stefan Santesson" <[email-masked]>, "Stephen Farrell" 
<[email-masked]>
cc
<[email-masked]>
Subject
RE: Certs in CRLs - New standards task?

It is a grotty hack but you could use the VALUE: URI which contains the 
raw data referenced by itself.

"VALUE:" + base64 (cert); 

Like I say.... Ugh! But....

> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Thursday, September 14, 2006 1:30 PM
> To: Hallam-Baker, Phillip; Stephen Farrell
> Cc: [email-masked]
> Subject: RE: Certs in CRLs - New standards task?
> 
> I'm open to all solutions that in an effective and practical 
> way solves the issue.
> 
> The reason I primary suggested a non-critical CRL extension 
> was to not disturb how legacy clients are configured to fetch 
> CRL's and the format they expect them to arrive.
> 
> RFC 3280bis states.
> 
>    If the DistributionPointName contains a general name of 
> type URI, the
>    following semantics MUST be assumed: the URI is a pointer to the
>    current CRL for the associated reasons and will be issued by the
>    associated cRLIssuer.  When the HTTP or FTP scheme is 
> specified, the
>    URI MUST point to a CRL file.  The CRL file MUST contain a 
> single DER
>    encoded CRL as specified in [RFC 2585].
> 
> As such I feel uncertain of the impacts on legacy 
> implementations if a bag of CRL+Certs is returned. But if 
> this can be done in a smooth way without causing problems, 
> then I'm all ear.
> 
> A non critical CRL extension with a certificate path would 
> simply be ignored by legacy clients and would not cause any 
> backwards compatibility problems. Thus it seems like an 
> easier path to me.
> 
> I don't believe the CA need to issue one CRL with certs and 
> one without, as David Kemp suggest. One CRL with a 
> non-critical extension with certs would work for all. And 
> this would not be included in the common CRLs of today. It 
> would only be a case for indirect CRLs and possibly when a 
> rekeyed CA take over revocation of certs issued under an older key.
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > From: Hallam-Baker, Phillip [mailto:[email-masked]]
> > Sent: den 14 september 2006 07:09
> > To: Stephen Farrell; Stefan Santesson
> > Cc: [email-masked]
> > Subject: RE: Certs in CRLs - New standards task?
> > 
> > I would prefer a bag as well, DIME would be ideal but I guess this 
> > group would want something ASN.1
> > 
> > Provided BER encoding is allowed I don't see a problem.
> > 
> > 
> > Another area where the same problem comes up is when using logotype,
> it
> > would be nice to be able to deliver the certificate and the logo in
> one
> > bag. Currently I am using MIME for this.
> > 
> > 
> > I would tend to see this as an HTTP extension rather than a PKIX 
> > extension. We already have MIME archives of HTML documents with 
> > interelated parts. This would be fine for small CRLs but for large
> CRLs
> > you really do need binary encoding not base 64.
> > 
> > 
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Stephen Farrell
> > > Sent: Wednesday, September 13, 2006 5:46 PM
> > > To: Stefan Santesson
> > > Cc: [email-masked]
> > > Subject: Re: Certs in CRLs - New standards task?
> > >
> > >
> > >
> > >
> > > Stefan Santesson wrote:
> > > > I would like to hear the opinion of this group on this.
> > >
> > > Sounds like an interesting idea - would like to see a draft all 
> > > right. (Though David Kemp's idea of wrapping the cert and 
> CRL a bag 
> > > might also be worth investigating, depending on the CRL consuming 
> > > protocols one is considering.)
> > >
> > > However, I'd have to wonder whether extending the life of 
> the PKIX 
> > > WG by another couple of years would be the right approach.
> > > Would it be better to first consider re-chartering or else 
> > > chartering a new WG? (I'm not saying I think either is the way to 
> > > go, but PKIX has been on the go for a looong time.)
> > >
> > > S.
> > >
> > >
> > >
> 
> 

Date: Mon, 18 Sep 2006 16:26:43 +0200
To: [email-masked]
From: Christine Karman <[email-masked]>
Subject: large crl's
Sender: [email-masked]

This is a multi-part message in MIME format.

--{ED9EABF7-3DB7-44CA-88DA-0F3E7E9674D3}
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,
I'm more of a lurker here, and I don't know if my question is 
appropriate in this forum.

We see crl's that are huge, like a DOD crl of 20MB. Assuming that you 
want to refresh the crl every couple of hours, this can put a strain 
on an application or a machine. Imagine using wifi at Starbucks, and 
your mail comes with 40MB of crls. Or an appliance that decrypts 15 
msgs/sec and then has to stop for downloading 20MB.
We're optimizing our code, but wouldn't it be better to limit the 
size of a crl and rather use multiple crl distribution points?

dagdag
Christine
-- 
Izecom BV
Secure e-mail and digital signatures
www.izecom.com

--{ED9EABF7-3DB7-44CA-88DA-0F3E7E9674D3}
Content-Type: application/x-pkcs7-signature; 
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

--{ED9EABF7-3DB7-44CA-88DA-0F3E7E9674D3}--

From: Sharon Boeyen <[email-masked]>
To: Sharon Boeyen <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, Denis Pinkas <[email-masked]>, [email-masked]
Subject: RE: Certs in CRLs - New standards task?
Date: Mon, 18 Sep 2006 10:08:00 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C6DB2B.5B7257E8
Content-Type: text/plain

A further concern with putting certificate(s) in CRLs really is the impact
of the size of the CRL on network load. Although this might be ok on a LAN -
what about a wireless segment or the connection between a CA and its ISP? In
practice, we find that often partitioned CRLs are no larger, or only
slightly larger than an OCSP response. Even adding one certificate could
make that CRL at least 3 times larger. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sharon Boeyen
Sent: Monday, September 18, 2006 9:25 AM
To: 'Stefan Santesson'; Denis Pinkas; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

With respect to indirect CRLs I can see some utility to this feature, for
hopefully just a single certificate (and then use pointers in that
certificate to build the path if there are more differences between that
path and the one used for the certificate being validated). I don't fully
understand the other situation you are proposing this for though and think I
would be uncomfortable if this extension became widely used for environments
other than indirect CRLs. If this is a wider problem that indirect CRLs, I
think I'm leaning to the approach of bundling the CRL with the bag of certs
in a separate structure, enabling environments that have no problems
building paths today without this new feature to continue doing what they do
today and not be forced with having a bag of certs added to common CRLs.
However I do admit to not fully understanding the problem you are stating so
these are just my current thoughts.
 
Cheers,
Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Monday, September 18, 2006 8:48 AM
To: Denis Pinkas; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

BM__MailEndComposeHi Denis,

Speaking as an implementer and from the experience from how our own products
work, the issue and the solution is much more simple than the solution you
propose.

The  validation engine does not need to know which certificate that
represents the old or the new CA key or what the hash of the certificate is.
The task of the validation engine for this issue is simply to validate the
signature of the CRL using a valid path to a trusted root (being the same
used to validate the target certificate).

First of all the validation engine will try to build a path using all certs
from the validated path and all cashed and locally stored certificates and
root keys. If this fails it could use the certs provided in the CRL using
this new extension (just a bag of certificates with no specific
information).

In the end, if the provided bag of certificates (typically only 1
certificate if present) does not help the RP, we did not do any particular
damage to the RP (just slightly increased the CRL), we just couldn't help
him and he will now have to try directory search etc as before. But the fact
is that by including certificate/s in the CRL we may in many PKI
configurations considerably help the RP.

I fully agree that this information can not be stored in an AIA. A new CRL
extension is needed.

Finally I don't agree to the term "overloading" here. We usually use that
term to describe when we stretch the semantics of existing fields and name
forms. This is just an new optional non-critical extension with useful data,
relevant to the processing of the CRL.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: den 18 september 2006 00:51
To: [email-masked]
Subject: Re: Certs in CRLs - New standards task?

Stefan,

I am not in favour of the proposed approach.

I have concern by always overloading the CRL, not simply with one additional
certificate, 

but with two additional certificates, because of CA key rollover.

The situation will be even worse when a CRL issuer is trusted by more than
one CA 

to issue CRLs.

Talking to you in your capacity of co-chair, I would like to recall that the
full story 

of how to check a CRL that is not issued by a CA is still not crystal clear
in 3280bis, 

and we should clarify that before. :-)

Talking to you as PKIX member, I would favor the use of  one extension with
two pointers per CA:

 - one pointing to the current or old certificate still valid, and 

 - another one pointing the new or current certificate already valid. 

This will allow to fetch once the certificate(s) that is/are needed.

The AIA extension is not the right vehicule, since it cannot include a hash
of the data that is pointed.

We should add a hash of the certificate, which would allow to make sure that
the right certificate 

was obtained without the need to build and verify the certification path.

>From the above observations, the problem is much more complex than
originally presented.

Denis

  _____  

Taking the pkix chair hat off and the vendor hat on

I'm asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed CA.
I.e. where the target certificate and it's CRL are signed by different keys
and the RP does not have access to the CRL Issuer certificate.

It is basically the same situation we solved with allowing the AIA extension
in CRL's namely the problem to obtain the CRL issuer's certificate,
alternatively, certificate path.

In our efforts to implement the AIA solution we have encountered some real
issues.

1)       Each time we are forced to go out and retrieve new information on
the network, we have a source of potential problems such as unavailable
network resources, timeouts etc. It all adds to the validation time and
harms the user experience.

2)       The AIA in CRL's provide another opening for DoS attacks if rouge
CRL's point their AIA to a targeted web server. This is tough not as serious
as the DoS problems with AIA in certificates, but this one we might avoid
more easily.

 The proposed solution is to define a new CRL extension that may contain the
CRL Issuer certificate (not just a URL to its location). Preferably this
would be a PKCS#7 (or CMS) Certs only message that may contain a single
certificate or a bag of certificates (a chain).

 While it wouldn't be attractive to define such extension for certificates
due to certificate size considerations, CRL's are often of such size that
including the certs needed to validate it only leads to an insignificant
increase of size, while it may offer substantial processing advantages.

 I would like to hear the opinion of this group on this.

 I volunteer to write a first draft if there is interest from the group.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

  _____  

------_=_NextPart_001_01C6DB2B.5B7257E8
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:m = 
"http://schemas.microsoft.com/office/2004/12/omml"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2900.2963" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt 70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P.MsoListParagraph {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 36pt; FONT-FAMILY: "Times New Roman","serif"; mso-style-priority: 34
}
LI.MsoListParagraph {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 36pt; FONT-FAMILY: "Times New Roman","serif"; mso-style-priority: 34
}
DIV.MsoListParagraph {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 36pt; FONT-FAMILY: "Times New Roman","serif"; mso-style-priority: 34
}
SPAN.EmailStyle18 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0cm
}
UL {
	MARGIN-BOTTOM: 0cm
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=SV vLink=purple link=blue>
<DIV><SPAN class=372320414-18092006><FONT face=Arial color=#0000ff size=2>A 
further concern with putting certificate(s) in CRLs really is the impact of the 
size of the CRL on network load. Although this might be ok on a LAN - what about 
a wireless segment or the connection between a CA and its ISP? In practice, we 
find that often partitioned CRLs are no larger, or only slightly larger than an 
OCSP response. Even adding one certificate could make that CRL at least 3 times 
larger. </FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
  [email-masked] [mailto:[email-masked]] <B>On 
  Behalf Of </B>Sharon Boeyen<BR><B>Sent:</B> Monday, September 18, 2006 9:25 
  AM<BR><B>To:</B> 'Stefan Santesson'; Denis Pinkas; 
  [email-masked]<BR><B>Subject:</B> RE: Certs in CRLs - New standards 
  task?<BR><BR></FONT></DIV>
  <DIV><SPAN class=606272013-18092006><FONT face=Arial color=#0000ff size=2>With 
  respect to indirect CRLs I can see some utility to this feature, for hopefully 
  just a single certificate (and then use pointers in that certificate to build 
  the path if there are more differences between that path and the one used for 
  the certificate being validated). I don't fully understand the other situation 
  you are proposing this for though and think I would be uncomfortable if this 
  extension became widely used for environments other than indirect 
  CRLs.&nbsp;If this is&nbsp;a wider problem that indirect CRLs, I think I'm 
  leaning to the approach of bundling the CRL with the bag&nbsp;of certs in a 
  separate structure, enabling environments that have no problems building paths 
  today without this new feature to continue doing what they do today and not be 
  forced&nbsp;with having a bag of certs added to&nbsp;common CRLs. However I do 
  admit to&nbsp;not fully understanding the problem you are stating so these are 
  just my current thoughts.</FONT></SPAN></DIV>
  <DIV><SPAN class=606272013-18092006></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=606272013-18092006><FONT face=Arial color=#0000ff 
  size=2>Cheers,</FONT></SPAN></DIV>
  <DIV><SPAN class=606272013-18092006><FONT face=Arial color=#0000ff 
  size=2>Sharon</FONT>&nbsp;</SPAN></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
    face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
    [email-masked] [mailto:[email-masked]] <B>On 
    Behalf Of </B>Stefan Santesson<BR><B>Sent:</B> Monday, September 18, 2006 
    8:48 AM<BR><B>To:</B> Denis Pinkas; [email-masked]<BR><B>Subject:</B> RE: 
    Certs in CRLs - New standards task?<BR><BR></FONT></DIV>
    <DIV class=Section1>
    <P class=MsoNormal><A name=_MailEndCompose><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Hi 
    Denis,<o:p></o:p></SPAN></A></P>
    <P class=MsoNormal><SPAN 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Speaking 
    as an implementer and from the experience from how our own products work, 
    the issue and the solution is much more simple than the solution you 
    propose.<o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">The 
    &nbsp;validation engine does not need to know which certificate that 
    represents the old or the new CA key or what the hash of the certificate is. 
    The task of the validation engine for this issue is simply to validate the 
    signature of the CRL using a valid path to a trusted root (being the same 
    used to validate the target certificate).<o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">First 
    of all the validation engine will try to build a path using all certs from 
    the validated path and all cashed and locally stored certificates and root 
    keys. If this fails it could use the certs provided in the CRL using this 
    new extension (just a bag of certificates with no specific 
    information).<o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">In 
    the end, if the provided bag of certificates (typically only 1 certificate 
    if present) does not help the RP, we did not do any particular damage to the 
    RP (just slightly increased the CRL), we just couldn't help him and he will 
    now have to try directory search etc as before. But the fact is that by 
    including certificate/s in the CRL we may in many PKI configurations 
    considerably help the RP.<o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I 
    fully agree that this information can not be stored in an AIA. A new CRL 
    extension is needed.<o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Finally 
    I don't agree to the term "overloading" here. We usually use that term to 
    describe when we stretch the semantics of existing fields and name forms. 
    This is just an new optional non-critical extension with useful data, 
    relevant to the processing of the CRL.<o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
    <DIV>
    <P class=MsoNormal><B><SPAN lang=EN-GB 
    style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan 
    Santesson</SPAN></B><SPAN lang=EN-GB 
    style="COLOR: #1f497d"><o:p></o:p></SPAN></P>
    <P class=MsoNormal><SPAN lang=EN-GB 
    style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Senior 
    Program Manager</SPAN><SPAN lang=EN-GB 
    style="COLOR: navy"><o:p></o:p></SPAN></P></DIV>
    <P class=MsoNormal><B><SPAN lang=EN-GB 
    style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows 
    Security, Standards</SPAN></B><SPAN lang=EN-US 
    style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p></o:p></SPAN></P>
    <DIV 
    style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
    <DIV>
    <DIV 
    style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
    <P class=MsoNormal><B><SPAN lang=EN-US 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
    lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> 
    [email-masked] [mailto:[email-masked]] <B>On 
    Behalf Of </B>Denis Pinkas<BR><B>Sent:</B> den 18 september 2006 
    00:51<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Re: Certs in CRLs - 
    New standards task?<o:p></o:p></SPAN></P></DIV></DIV>
    <P class=MsoNormal><o:p>&nbsp;</o:p></P>
    <DIV>
    <P class=MsoNormal>Stefan,<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>I am not in favour of the proposed 
    approach.<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>I have concern by always overloading the CRL, not simply 
    with one additional certificate, <o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>but with two additional certificates, because of CA key 
    rollover.<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>The situation will&nbsp;be even worse when a CRL issuer 
    is trusted by more than one CA <o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>to issue CRLs.<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>Talking to you in your capacity of&nbsp;co-chair, I would 
    like to recall that the full story <o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>of how to check a CRL that is not issued by a CA is still 
    not crystal clear in 3280bis, <o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>and we should clarify that before. 
    :-)<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>Talking to you as PKIX member, I would favor the use 
    of&nbsp;&nbsp;one extension with two pointers&nbsp;per 
    CA:<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;- one&nbsp;pointing to the current or old 
    certificate still valid, and <o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;- another one pointing the new or current 
    certificate already valid. <o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>This will allow to fetch once the certificate(s) that 
    is/are&nbsp;needed.<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>The AIA extension is not the right vehicule, since it 
    cannot include a hash of the data that is pointed.<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>We should add a hash of the certificate, which would 
    allow to make sure that the right certificate <o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>was obtained without the need to build and verify the 
    certification path.<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>From the above observations, the problem is much more 
    complex than originally presented.<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>Denis<o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
    <DIV>
    <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center>
    <HR align=center width="100%" SIZE=2>
    </DIV></DIV>
    <DIV>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Taking 
    the pkix chair hat off and the vendor hat on</SPAN><o:p></o:p></P>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I'm 
    asking this group to consider a new standards task to solve a real 
    implementation issue with indirect CRLs and CRLs issued by a re-keyed CA. 
    I.e. where the target certificate and it's CRL are signed by different keys 
    and the RP does not have access to the CRL Issuer 
    certificate.</SPAN><o:p></o:p></P>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">It is 
    basically the same situation we solved with allowing the AIA extension in 
    CRL's namely the problem to obtain the CRL issuer's certificate, 
    alternatively, certificate path.</SPAN><o:p></o:p></P>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">In our 
    efforts to implement the AIA solution we have encountered some real 
    issues.</SPAN><o:p></o:p></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">1)</SPAN><SPAN 
    lang=EN-GB style="FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </SPAN><SPAN lang=EN-GB 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Each time we are 
    forced to go out and retrieve new information on the network, we have a 
    source of potential problems such as unavailable network resources, timeouts 
    etc. It all adds to the validation time and harms the user 
    experience.</SPAN><o:p></o:p></P>
    <P class=MsoNormal 
    style="MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">2)</SPAN><SPAN 
    lang=EN-GB style="FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </SPAN><SPAN lang=EN-GB 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">The AIA in CRL's 
    provide another opening for DoS attacks if rouge CRL's point their AIA to a 
    targeted web server. This is tough not as serious as the DoS problems with 
    AIA in certificates, but this one we might avoid more 
    easily.</SPAN><o:p></o:p></P>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;The 
    proposed solution is to define a new CRL extension that may contain the CRL 
    Issuer certificate (not just a URL to its location). Preferably this would 
    be a PKCS#7 (or CMS) Certs only message that may contain a single 
    certificate or a bag of certificates (a chain).</SPAN><o:p></o:p></P>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;While it 
    wouldn't be attractive to define such extension for certificates due to 
    certificate size considerations, CRL's are often of such size that including 
    the certs needed to validate it only leads to an insignificant increase of 
    size, while it may offer substantial processing 
    advantages.</SPAN><o:p></o:p></P>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;I would 
    like to hear the opinion of this group on this.</SPAN><o:p></o:p></P>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;I volunteer 
    to write a first draft if there is interest from the 
    group.</SPAN><o:p></o:p></P>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB 
    style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;</SPAN><o:p></o:p></P>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><STRONG><SPAN 
    lang=EN-GB 
    style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan 
    Santesson</SPAN></STRONG><o:p></o:p></P>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB 
    style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Senior 
    Program Manager</SPAN><o:p></o:p></P>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><STRONG><SPAN 
    lang=EN-GB 
    style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows 
    Security, Standards</SPAN></STRONG><o:p></o:p></P>
    <P class=MsoNormal 
    style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
    lang=EN-GB>&nbsp;</SPAN><o:p></o:p></P></DIV>
    <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center>
    <HR align=center width="100%" SIZE=2>
    </DIV></DIV></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6DB2B.5B7257E8--

From: Sharon Boeyen <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Denis Pinkas <[email-masked]>, [email-masked]
Subject: RE: Certs in CRLs - New standards task?
Date: Mon, 18 Sep 2006 09:25:08 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C6DB25.34607788
Content-Type: text/plain

With respect to indirect CRLs I can see some utility to this feature, for
hopefully just a single certificate (and then use pointers in that
certificate to build the path if there are more differences between that
path and the one used for the certificate being validated). I don't fully
understand the other situation you are proposing this for though and think I
would be uncomfortable if this extension became widely used for environments
other than indirect CRLs. If this is a wider problem that indirect CRLs, I
think I'm leaning to the approach of bundling the CRL with the bag of certs
in a separate structure, enabling environments that have no problems
building paths today without this new feature to continue doing what they do
today and not be forced with having a bag of certs added to common CRLs.
However I do admit to not fully understanding the problem you are stating so
these are just my current thoughts.
 
Cheers,
Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Monday, September 18, 2006 8:48 AM
To: Denis Pinkas; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

BM__MailEndComposeHi Denis,

Speaking as an implementer and from the experience from how our own products
work, the issue and the solution is much more simple than the solution you
propose.

The  validation engine does not need to know which certificate that
represents the old or the new CA key or what the hash of the certificate is.
The task of the validation engine for this issue is simply to validate the
signature of the CRL using a valid path to a trusted root (being the same
used to validate the target certificate).

First of all the validation engine will try to build a path using all certs
from the validated path and all cashed and locally stored certificates and
root keys. If this fails it could use the certs provided in the CRL using
this new extension (just a bag of certificates with no specific
information).

In the end, if the provided bag of certificates (typically only 1
certificate if present) does not help the RP, we did not do any particular
damage to the RP (just slightly increased the CRL), we just couldn't help
him and he will now have to try directory search etc as before. But the fact
is that by including certificate/s in the CRL we may in many PKI
configurations considerably help the RP.

I fully agree that this information can not be stored in an AIA. A new CRL
extension is needed.

Finally I don't agree to the term "overloading" here. We usually use that
term to describe when we stretch the semantics of existing fields and name
forms. This is just an new optional non-critical extension with useful data,
relevant to the processing of the CRL.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: den 18 september 2006 00:51
To: [email-masked]
Subject: Re: Certs in CRLs - New standards task?

Stefan,

I am not in favour of the proposed approach.

I have concern by always overloading the CRL, not simply with one additional
certificate, 

but with two additional certificates, because of CA key rollover.

The situation will be even worse when a CRL issuer is trusted by more than
one CA 

to issue CRLs.

Talking to you in your capacity of co-chair, I would like to recall that the
full story 

of how to check a CRL that is not issued by a CA is still not crystal clear
in 3280bis, 

and we should clarify that before. :-)

Talking to you as PKIX member, I would favor the use of  one extension with
two pointers per CA:

 - one pointing to the current or old certificate still valid, and 

 - another one pointing the new or current certificate already valid. 

This will allow to fetch once the certificate(s) that is/are needed.

The AIA extension is not the right vehicule, since it cannot include a hash
of the data that is pointed.

We should add a hash of the certificate, which would allow to make sure that
the right certificate 

was obtained without the need to build and verify the certification path.

>From the above observations, the problem is much more complex than
originally presented.

Denis

  _____  

Taking the pkix chair hat off and the vendor hat on

I'm asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed CA.
I.e. where the target certificate and it's CRL are signed by different keys
and the RP does not have access to the CRL Issuer certificate.

It is basically the same situation we solved with allowing the AIA extension
in CRL's namely the problem to obtain the CRL issuer's certificate,
alternatively, certificate path.

In our efforts to implement the AIA solution we have encountered some real
issues.

1)       Each time we are forced to go out and retrieve new information on
the network, we have a source of potential problems such as unavailable
network resources, timeouts etc. It all adds to the validation time and
harms the user experience.

2)       The AIA in CRL's provide another opening for DoS attacks if rouge
CRL's point their AIA to a targeted web server. This is tough not as serious
as the DoS problems with AIA in certificates, but this one we might avoid
more easily.

 The proposed solution is to define a new CRL extension that may contain the
CRL Issuer certificate (not just a URL to its location). Preferably this
would be a PKCS#7 (or CMS) Certs only message that may contain a single
certificate or a bag of certificates (a chain).

 While it wouldn't be attractive to define such extension for certificates
due to certificate size considerations, CRL's are often of such size that
including the certs needed to validate it only leads to an insignificant
increase of size, while it may offer substantial processing advantages.

 I would like to hear the opinion of this group on this.

 I volunteer to write a first draft if there is interest from the group.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

  _____  

------_=_NextPart_001_01C6DB25.34607788
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:m = 
"http://schemas.microsoft.com/office/2004/12/omml"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2900.2963" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt 70.85pt 70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P.MsoListParagraph {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 36pt; FONT-FAMILY: "Times New Roman","serif"; mso-style-priority: 34
}
LI.MsoListParagraph {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 36pt; FONT-FAMILY: "Times New Roman","serif"; mso-style-priority: 34
}
DIV.MsoListParagraph {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 36pt; FONT-FAMILY: "Times New Roman","serif"; mso-style-priority: 34
}
SPAN.EmailStyle18 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0cm
}
UL {
	MARGIN-BOTTOM: 0cm
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=SV vLink=purple link=blue>
<DIV><SPAN class=606272013-18092006><FONT face=Arial color=#0000ff size=2>With 
respect to indirect CRLs I can see some utility to this feature, for hopefully 
just a single certificate (and then use pointers in that certificate to build 
the path if there are more differences between that path and the one used for 
the certificate being validated). I don't fully understand the other situation 
you are proposing this for though and think I would be uncomfortable if this 
extension became widely used for environments other than indirect CRLs.&nbsp;If 
this is&nbsp;a wider problem that indirect CRLs, I think I'm leaning to the 
approach of bundling the CRL with the bag&nbsp;of certs in a separate structure, 
enabling environments that have no problems building paths today without this 
new feature to continue doing what they do today and not be forced&nbsp;with 
having a bag of certs added to&nbsp;common CRLs. However I do admit to&nbsp;not 
fully understanding the problem you are stating so these are just my current 
thoughts.</FONT></SPAN></DIV>
<DIV><SPAN class=606272013-18092006></SPAN>&nbsp;</DIV>
<DIV><SPAN class=606272013-18092006><FONT face=Arial color=#0000ff 
size=2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=606272013-18092006><FONT face=Arial color=#0000ff 
size=2>Sharon</FONT>&nbsp;</SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
  [email-masked] [mailto:[email-masked]] <B>On 
  Behalf Of </B>Stefan Santesson<BR><B>Sent:</B> Monday, September 18, 2006 8:48 
  AM<BR><B>To:</B> Denis Pinkas; [email-masked]<BR><B>Subject:</B> RE: Certs 
  in CRLs - New standards task?<BR><BR></FONT></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><A name=_MailEndCompose><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Hi 
  Denis,<o:p></o:p></SPAN></A></P>
  <P class=MsoNormal><SPAN 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Speaking 
  as an implementer and from the experience from how our own products work, the 
  issue and the solution is much more simple than the solution you 
  propose.<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">The 
  &nbsp;validation engine does not need to know which certificate that 
  represents the old or the new CA key or what the hash of the certificate is. 
  The task of the validation engine for this issue is simply to validate the 
  signature of the CRL using a valid path to a trusted root (being the same used 
  to validate the target certificate).<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">First 
  of all the validation engine will try to build a path using all certs from the 
  validated path and all cashed and locally stored certificates and root keys. 
  If this fails it could use the certs provided in the CRL using this new 
  extension (just a bag of certificates with no specific 
  information).<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">In 
  the end, if the provided bag of certificates (typically only 1 certificate if 
  present) does not help the RP, we did not do any particular damage to the RP 
  (just slightly increased the CRL), we just couldn't help him and he will now 
  have to try directory search etc as before. But the fact is that by including 
  certificate/s in the CRL we may in many PKI configurations considerably help 
  the RP.<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I 
  fully agree that this information can not be stored in an AIA. A new CRL 
  extension is needed.<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Finally 
  I don't agree to the term "overloading" here. We usually use that term to 
  describe when we stretch the semantics of existing fields and name forms. This 
  is just an new optional non-critical extension with useful data, relevant to 
  the processing of the CRL.<o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <P class=MsoNormal><B><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan 
  Santesson</SPAN></B><SPAN lang=EN-GB 
  style="COLOR: #1f497d"><o:p></o:p></SPAN></P>
  <P class=MsoNormal><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Senior 
  Program Manager</SPAN><SPAN lang=EN-GB 
  style="COLOR: navy"><o:p></o:p></SPAN></P></DIV>
  <P class=MsoNormal><B><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows 
  Security, Standards</SPAN></B><SPAN lang=EN-US 
  style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"><o:p></o:p></SPAN></P>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=MsoNormal><B><SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN 
  lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> 
  [email-masked] [mailto:[email-masked]] <B>On 
  Behalf Of </B>Denis Pinkas<BR><B>Sent:</B> den 18 september 2006 
  00:51<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Re: Certs in CRLs - 
  New standards task?<o:p></o:p></SPAN></P></DIV></DIV>
  <P class=MsoNormal><o:p>&nbsp;</o:p></P>
  <DIV>
  <P class=MsoNormal>Stefan,<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>I am not in favour of the proposed 
  approach.<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>I have concern by always overloading the CRL, not simply 
  with one additional certificate, <o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>but with two additional certificates, because of CA key 
  rollover.<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>The situation will&nbsp;be even worse when a CRL issuer is 
  trusted by more than one CA <o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>to issue CRLs.<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>Talking to you in your capacity of&nbsp;co-chair, I would 
  like to recall that the full story <o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>of how to check a CRL that is not issued by a CA is still 
  not crystal clear in 3280bis, <o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>and we should clarify that before. :-)<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>Talking to you as PKIX member, I would favor the use 
  of&nbsp;&nbsp;one extension with two pointers&nbsp;per 
CA:<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;- one&nbsp;pointing to the current or old certificate 
  still valid, and <o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;- another one pointing the new or current certificate 
  already valid. <o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>This will allow to fetch once the certificate(s) that 
  is/are&nbsp;needed.<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>The AIA extension is not the right vehicule, since it 
  cannot include a hash of the data that is pointed.<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>We should add a hash of the certificate, which would allow 
  to make sure that the right certificate <o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>was obtained without the need to build and verify the 
  certification path.<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>From the above observations, the problem is much more 
  complex than originally presented.<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>Denis<o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal>&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center>
  <HR align=center width="100%" SIZE=2>
  </DIV></DIV>
  <DIV>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Taking the pkix 
  chair hat off and the vendor hat on</SPAN><o:p></o:p></P>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I'm asking this 
  group to consider a new standards task to solve a real implementation issue 
  with indirect CRLs and CRLs issued by a re-keyed CA. I.e. where the target 
  certificate and it's CRL are signed by different keys and the RP does not have 
  access to the CRL Issuer certificate.</SPAN><o:p></o:p></P>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">It is basically the 
  same situation we solved with allowing the AIA extension in CRL's namely the 
  problem to obtain the CRL issuer's certificate, alternatively, certificate 
  path.</SPAN><o:p></o:p></P>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">In our efforts to 
  implement the AIA solution we have encountered some real 
  issues.</SPAN><o:p></o:p></P>
  <P class=MsoNormal 
  style="MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
  lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">1)</SPAN><SPAN 
  lang=EN-GB style="FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Each time we are 
  forced to go out and retrieve new information on the network, we have a source 
  of potential problems such as unavailable network resources, timeouts etc. It 
  all adds to the validation time and harms the user 
  experience.</SPAN><o:p></o:p></P>
  <P class=MsoNormal 
  style="MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
  lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">2)</SPAN><SPAN 
  lang=EN-GB style="FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">The AIA in CRL's 
  provide another opening for DoS attacks if rouge CRL's point their AIA to a 
  targeted web server. This is tough not as serious as the DoS problems with AIA 
  in certificates, but this one we might avoid more 
easily.</SPAN><o:p></o:p></P>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;The proposed 
  solution is to define a new CRL extension that may contain the CRL Issuer 
  certificate (not just a URL to its location). Preferably this would be a 
  PKCS#7 (or CMS) Certs only message that may contain a single certificate or a 
  bag of certificates (a chain).</SPAN><o:p></o:p></P>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;While it 
  wouldn't be attractive to define such extension for certificates due to 
  certificate size considerations, CRL's are often of such size that including 
  the certs needed to validate it only leads to an insignificant increase of 
  size, while it may offer substantial processing 
  advantages.</SPAN><o:p></o:p></P>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;I would like 
  to hear the opinion of this group on this.</SPAN><o:p></o:p></P>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;I volunteer 
  to write a first draft if there is interest from the 
  group.</SPAN><o:p></o:p></P>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">&nbsp;</SPAN><o:p></o:p></P>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><STRONG><SPAN 
  lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Arial','sans-serif'">Stefan 
  Santesson</SPAN></STRONG><o:p></o:p></P>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Senior 
  Program Manager</SPAN><o:p></o:p></P>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><STRONG><SPAN 
  lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: 'Arial','sans-serif'">Windows 
  Security, Standards</SPAN></STRONG><o:p></o:p></P>
  <P class=MsoNormal 
  style="mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"><SPAN 
  lang=EN-GB>&nbsp;</SPAN><o:p></o:p></P></DIV>
  <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center>
  <HR align=center width="100%" SIZE=2>
  </DIV></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6DB25.34607788--

Date: Mon, 18 Sep 2006 15:21:31 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Certs in CRLs - New standards task?
Sender: [email-masked]

Ryan Hurst wrote:
> Have you considered the idea of introducing a new access method to the
> AIA that would point to a P7c that possibly contained the CRL, its
> issuers and maybe the certificates issuers?
>   
I vote for p7c. Most CAs already include an option to distribute CRL 
this way.

After reading  RFC 2585, I think it misses something  by not saying a 
word about the popular option of distributing crl and certificates 
inside pkcs#7/CMS bags.

When RFC 3280bis says that URIs inside a DistributionPointName must 
point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it just  
making explicit a rule that was already required for proper 
interoperability ?

Date: Mon, 18 Sep 2006 15:09:56 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re:  Certs in CRLs - New standards task?
Sender: [email-masked]

This is a multi-part message in MIME format.

--=====003_Dragon565333730724_=====
Content-Transfer-Encoding: base64
Content-Type: text/plain;
	charset="iso-8859-1"

--=====003_Dragon565333730724_=====
Content-Transfer-Encoding: base64
Content-Type: text/html;
	charset="iso-8859-1"

--=====003_Dragon565333730724_=====--

To: "Santosh Chokhani" <[email-masked]>
Cc: "David A. Cooper" <[email-masked]>, "pkix" <[email-masked]>
Subject: RE: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
From: Tom Gindin <[email-masked]>
Date: Mon, 18 Sep 2006 09:08:55 -0400
Sender: [email-masked]

        Santosh:

        I see uses for a general RP in setting max_path_length to 0.  It 
trusts a given CA to issue EE certificates, but refuses to accept cross 
certificates.  The most obvious scenario where this is useful is if you 
are trusting an organization's internal CA to issue certificates to 
employees or members, but you don't have any use for its cross 
certificates.
        I suppose there might be some conditions under which setting it to 
1 makes sense, since that effectively sets a path length constraint on a 
CA which doesn't use them itself, but I have never come up with a good 
scenario for it.

                Tom Gindin

"Santosh Chokhani" <[email-masked]> 
09/16/2006 10:01 PM

To
Tom Gindin/Watson/IBM@IBMUS
cc
"David A. Cooper" <[email-masked]>, "pkix" <[email-masked]>
Subject
RE: 3280 Bis: Initial Values for Permitted and Excluded Subtrees

Tom,

I can see the path length usefulness (specifically path length = 0)when
a CA is validating one of its trusted operator certificates.

Do you see other usage of setting the value (to 0 or some non-zero)
value.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Saturday, September 16, 2006 5:57 PM
To: Santosh Chokhani
Cc: David A. Cooper; pkix
Subject: RE: 3280 Bis: Initial Values for Permitted and Excluded
Subtrees

        I'm for this too.  Does including max_path_length make sense as 
well?  I believe that it does.  Setting it to 0, in particular, trusts a

CA to issue end-entity certificates without trusting it to issue cross 
certificates.

                Tom Gindin

"Santosh Chokhani" <[email-masked]> 
Sent by: [email-masked]
09/15/2006 09:55 PM

To
"David A. Cooper" <[email-masked]>, "pkix" <[email-masked]>
cc

Subject
RE: 3280 Bis: Initial Values for Permitted and Excluded Subtrees

David,
 
I would request that we do that, i.e., make it explicit in
initialization.
 
Thanks.

From: [email-masked] [mailto:[email-masked]]

On Behalf Of David A. Cooper
Sent: Friday, September 15, 2006 5:51 PM
To: pkix
Subject: Re: 3280 Bis: Initial Values for Permitted and Excluded
Subtrees
 
Russ Housley wrote: 
I have been thinking about this, and I think it would be a very good
idea 
to add these.  The algorithm in section 6 already has state variables
for 
permitted and excluded subtrees.  This is a minor change to permit them
to 
be initialized to algorithm input values.
3280bis already permits setting initial values for name constraints,
just 
not in section 6.1.  The following text appears in section 6.2 (Using
the 
Path Validation Algorithm) and is basically unchanged from RFC 3280:

         An implementation MAY augment the algorithm presented in
section 
6.1
         to further limit the set of valid certification paths that
begin 
with
         a particular trust anchor.  For example, an implementation MAY 
modify
         the algorithm to apply name constraints to a specific trust 
anchor
         during the initialization phase, ....

Of course, 3280bis could formally add the initialization of permitted
and 
excluded subtrees to the path validation algorithm by adding it to
section 
6.1.  Since RFC 3280 and 3280bis already permit this it wouldn't really
be 
a change, it would just make the option more visible.  So, I would have
no 
objection to moving this option to section 6.1.

Dave

At 07:00 PM 8/24/2006, Santosh Chokhani wrote:

All,
 
The new version of X.509 (2005 Edition) permits initial values other
than 
infinity and null for permitted and excluded subtrees respectively.
 
Should we also revise 3280Bis to include these options so that the
relying 
parties can constrain the trust anchors?
 
I would consider infinity and null values only for the two respective 
fields still compliant with the applicable standard.
 
Thanks in advance for your opinion.

Santosh Chokhani 
Orion Security Solutions, Inc. 
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101 
(703) 917-0060 Ext. 35 (voice) 
(703) 917-0260 (Fax) 
[email-masked] 
Visit our Web site 
http://www.orionsec.com 

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Mon, 18 Sep 2006 13:47:52 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6DB20.A7546475
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

=20

Speaking as an implementer and from the experience from how our own
products work, the issue and the solution is much more simple than the
solution you propose.

=20

The  validation engine does not need to know which certificate that
represents the old or the new CA key or what the hash of the certificate
is. The task of the validation engine for this issue is simply to
validate the signature of the CRL using a valid path to a trusted root
(being the same used to validate the target certificate).

=20

First of all the validation engine will try to build a path using all
certs from the validated path and all cashed and locally stored
certificates and root keys. If this fails it could use the certs
provided in the CRL using this new extension (just a bag of certificates
with no specific information).

=20

In the end, if the provided bag of certificates (typically only 1
certificate if present) does not help the RP, we did not do any
particular damage to the RP (just slightly increased the CRL), we just
couldn't help him and he will now have to try directory search etc as
before. But the fact is that by including certificate/s in the CRL we
may in many PKI configurations considerably help the RP.

=20

I fully agree that this information can not be stored in an AIA. A new
CRL extension is needed.

=20

Finally I don't agree to the term "overloading" here. We usually use
that term to describe when we stretch the semantics of existing fields
and name forms. This is just an new optional non-critical extension with
useful data, relevant to the processing of the CRL.

=20

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: den 18 september 2006 00:51
To: [email-masked]
Subject: Re: Certs in CRLs - New standards task?

=20

Stefan,

=20

I am not in favour of the proposed approach.

=20

I have concern by always overloading the CRL, not simply with one
additional certificate,=20

but with two additional certificates, because of CA key rollover.

=20

The situation will be even worse when a CRL issuer is trusted by more
than one CA=20

to issue CRLs.

=20

Talking to you in your capacity of co-chair, I would like to recall that
the full story=20

of how to check a CRL that is not issued by a CA is still not crystal
clear in 3280bis,=20

and we should clarify that before. :-)

=20

Talking to you as PKIX member, I would favor the use of  one extension
with two pointers per CA:

=20

 - one pointing to the current or old certificate still valid, and=20

 - another one pointing the new or current certificate already valid.=20

=20

This will allow to fetch once the certificate(s) that is/are needed.

=20

The AIA extension is not the right vehicule, since it cannot include a
hash of the data that is pointed.

We should add a hash of the certificate, which would allow to make sure
that the right certificate=20

was obtained without the need to build and verify the certification
path.

=20

>From the above observations, the problem is much more complex than
originally presented.

=20

Denis

=20

________________________________

Taking the pkix chair hat off and the vendor hat on

I'm asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed
CA. I.e. where the target certificate and it's CRL are signed by
different keys and the RP does not have access to the CRL Issuer
certificate.

It is basically the same situation we solved with allowing the AIA
extension in CRL's namely the problem to obtain the CRL issuer's
certificate, alternatively, certificate path.

In our efforts to implement the AIA solution we have encountered some
real issues.

1)       Each time we are forced to go out and retrieve new information
on the network, we have a source of potential problems such as
unavailable network resources, timeouts etc. It all adds to the
validation time and harms the user experience.

2)       The AIA in CRL's provide another opening for DoS attacks if
rouge CRL's point their AIA to a targeted web server. This is tough not
as serious as the DoS problems with AIA in certificates, but this one we
might avoid more easily.

 The proposed solution is to define a new CRL extension that may contain
the CRL Issuer certificate (not just a URL to its location). Preferably
this would be a PKCS#7 (or CMS) Certs only message that may contain a
single certificate or a bag of certificates (a chain).

 While it wouldn't be attractive to define such extension for
certificates due to certificate size considerations, CRL's are often of
such size that including the certs needed to validate it only leads to
an insignificant increase of size, while it may offer substantial
processing advantages.

 I would like to hear the opinion of this group on this.

 I volunteer to write a first draft if there is interest from the group.

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

________________________________

------_=_NextPart_001_01C6DB20.A7546475
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:213741828;
	mso-list-type:hybrid;
	mso-list-template-ids:694970306 69009425 69009433 69009435 69009423 =
69009433 69009435 69009423 69009433 69009435;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Speaking as an implementer and from the experience from =
how our
own products work, the issue and the solution is much more simple than =
the
solution you propose.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The &nbsp;validation engine does not need to know which
certificate that represents the old or the new CA key or what the hash =
of the
certificate is. The task of the validation engine for this issue is =
simply to validate
the signature of the CRL using a valid path to a trusted root (being the =
same
used to validate the target certificate).<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>First of all the validation engine will try to build a =
path
using all certs from the validated path and all cashed and locally =
stored
certificates and root keys. If this fails it could use the certs =
provided in
the CRL using this new extension (just a bag of certificates with no =
specific
information).<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In the end, if the provided bag of certificates =
(typically only
1 certificate if present) does not help the RP, we did not do any =
particular
damage to the RP (just slightly increased the CRL), we just =
couldn&#8217;t help
him and he will now have to try directory search etc as before. But the =
fact is
that by including certificate/s in the CRL we may in many PKI =
configurations
considerably help the RP.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I fully agree that this information can not be stored in =
an AIA.
A new CRL extension is needed.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Finally I don&#8217;t agree to the term =
&#8220;overloading&#8221;
here. We usually use that term to describe when we stretch the semantics =
of
existing fields and name forms. This is just an new optional =
non-critical
extension with useful data, relevant to the processing of the =
CRL.<o:p></o:p></span></p>

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

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

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

<div>

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

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

</div>

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

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

<div>

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

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Denis =
Pinkas<br>
<b>Sent:</b> den 18 september 2006 00:51<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Re: Certs in CRLs - New standards =
task?<o:p></o:p></span></p>

</div>

</div>

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

<div>

<p class=3DMsoNormal>Stefan,<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>I am not in favour of the proposed =
approach.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>I have concern by always overloading the CRL, not =
simply
with one additional certificate, <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>but with two additional certificates, because of CA =
key
rollover.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>The situation will&nbsp;be even worse when a CRL =
issuer is
trusted by more than one CA <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>to issue CRLs.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>Talking to you in your capacity of&nbsp;co-chair, I =
would
like to recall that the full story <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>of how to check a CRL that is not issued by a CA is =
still
not crystal clear in 3280bis, <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>and we should clarify that before. =
:-)<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>Talking to you as PKIX member, I would favor the =
use
of&nbsp;&nbsp;one extension with two pointers&nbsp;per =
CA:<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>&nbsp;- one&nbsp;pointing to the current or old =
certificate
still valid, and <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;- another one pointing the new or current =
certificate
already valid. <o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>This will allow to fetch once the certificate(s) =
that
is/are&nbsp;needed.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>The AIA extension is not the right vehicule, since =
it cannot
include a hash of the data that is pointed.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>We should add a hash of the certificate, which =
would allow
to make sure that the right certificate <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>was obtained without the need to build and verify =
the
certification path.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>From the above observations, the problem is much =
more
complex than originally presented.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal>Denis<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

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

</div>

</div>

<div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Taking the
pkix chair hat off and the vendor hat on</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I&#8217;m
asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed =
CA. I.e.
where the target certificate and it&#8217;s CRL are signed by different =
keys
and the RP does not have access to the CRL Issuer =
certificate.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>It is
basically the same situation we solved with allowing the AIA extension =
in
CRL&#8217;s namely the problem to obtain the CRL issuer&#8217;s =
certificate,
alternatively, certificate path.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>In our
efforts to implement the AIA solution we have encountered some real =
issues.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif"'>1)</span><span lang=3DEN-GB =
style=3D'font-size:
7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Each time we =
are
forced to go out and retrieve new information on the network, we have a =
source
of potential problems such as unavailable network resources, timeouts =
etc. It
all adds to the validation time and harms the user =
experience.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif"'>2)</span><span lang=3DEN-GB =
style=3D'font-size:
7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>The AIA in
CRL&#8217;s provide another opening for DoS attacks if rouge CRL&#8217;s =
point
their AIA to a targeted web server. This is tough not as serious as the =
DoS
problems with AIA in certificates, but this one we might avoid more =
easily.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;The
proposed solution is to define a new CRL extension that may contain the =
CRL
Issuer certificate (not just a URL to its location). Preferably this =
would be a
PKCS#7 (or CMS) Certs only message that may contain a single certificate =
or a
bag of certificates (a chain).</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;While
it wouldn&#8217;t be attractive to define such extension for =
certificates due
to certificate size considerations, CRL&#8217;s are often of such size =
that
including the certs needed to validate it only leads to an insignificant
increase of size, while it may offer substantial processing =
advantages.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;I
would like to hear the opinion of this group on =
this.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;I
volunteer to write a first draft if there is interest from the =
group.</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;</span>=
<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><strong><spa=
n
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:maroon'>=
Stefan
Santesson</span></strong><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#400040'=
>Senior
Program Manager</span><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><strong><spa=
n
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#400040'=
>Windows
Security, Standards</span></strong><o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-GB>&nbsp;</span><o:p></o:p></p>

</div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

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

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C6DB20.A7546475--

Date: Mon, 18 Sep 2006 13:27:30 +0200
From: Peter Sylvester <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: [email-masked]
Subject: Re: New time stamping standard by ISO
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms080608000408070609070200
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

> I’m not involved in this work and this is nothing this group can 
> influence directly but I would still see value in getting input from 
> people here on at least one particular change they have made to the 
> ASN.1 syntax.
>
>
I am not involved either, and your text snippet is small, so only some 
speculation.

This format seems to be targetted to transform the rfc 3161 example of 
how to add a timestamp
to a signature into a simple cms countersignature.

There seems to be a requirement to have this alternative format of the asn1
based token, one can either have new mime types or add something like 
the proposed syntax.
I assume that the xml protocol adds -xml to the mime types?

One also has to look what parameter allows client or servers to detect 
what response has to be
made or is acceptable.

maybe Denis knows more?

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

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

--------------ms080608000408070609070200--

Date: Mon, 18 Sep 2006 11:27:47 +0200
From: Peter Sylvester <[email-masked]>
To: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Doesn't the MAY in the sentence permit an implementation to be conformant
if it does not provide the possibility?  This deosn't seem to be the 
same in X.509 where
the possibility of adding the constraints is part of the input of the 
path validation algorithm.

The inputs to the certification path processing procedure are:
...

h) an initial-permitted-subtrees-set containing an initial set of 
subtree specifications defining subtrees within which subject names (of 
the name form used to specify the subtrees) are permitted. In the 
certificates in the certification path all subject names of a given name 
form, for which initial permitted subtrees are defined, shall fall 
within the permitted subtrees set for that given name form. This input 
may also contain the special value unbounded to indicate that initially 
all subject names are acceptable. For clause 10, subject names are those 
name values appearing in the subject field or the subjectAltName extension;

David A. Cooper wrote:
> Russ Housley wrote:
>> I have been thinking about this, and I think it would be a very good 
>> idea to add these.  The algorithm in section 6 already has state 
>> variables for permitted and excluded subtrees.  This is a minor 
>> change to permit them to be initialized to algorithm input values.
> 3280bis already permits setting initial values for name constraints, 
> just not in section 6.1.  The following text appears in section 6.2 
> (Using the Path Validation Algorithm) and is basically unchanged from 
> RFC 3280:
>
>          An implementation MAY augment the algorithm presented in 
> section 6.1
>          to further limit the set of valid certification paths that 
> begin with
>          a particular trust anchor.  For example, an implementation 
> MAY modify
>          the algorithm to apply name constraints to a specific trust 
> anchor
>          during the initialization phase, ....
>
> Of course, 3280bis could formally add the initialization of permitted 
> and excluded subtrees to the path validation algorithm by adding it to 
> section 6.1.  Since RFC 3280 and 3280bis already permit this it 
> wouldn't really be a change, it would just make the option more 
> visible.  So, I would have no objection to moving this option to 
> section 6.1.
>
> Dave
>
>> At 07:00 PM 8/24/2006, Santosh Chokhani wrote:
>>> All,
>>>  
>>> The new version of X.509 (2005 Edition) permits initial values other 
>>> than infinity and null for permitted and excluded subtrees respectively.
>>>  
>>> Should we also revise 3280Bis to include these options so that the 
>>> relying parties can constrain the trust anchors?
>>>  
>>> I would consider infinity and null values only for the two 
>>> respective fields still compliant with the applicable standard.
>>>  
>>> Thanks in advance for your opinion.
>>>
>>> Santosh Chokhani
>>> Orion Security Solutions, Inc.
>>> 1489 Chain Bridge Road, Suite 300
>>> McLean, Virginia 22101
>>> (703) 917-0060 Ext. 35 (voice)
>>> (703) 917-0260 (Fax)
>>> [email-masked] <mailto:[email-masked]>
>>> Visit our Web site
>>> http://www.orionsec.com
>>>   
>

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

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

--------------ms020904070600070803010809--

Date: Mon, 18 Sep 2006 09:51:13 +0200
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Certs in CRLs - New standards task?
Sender: [email-masked]

This is a multi-part message in MIME format.

--=====003_Dragon335055162862_=====
Content-Transfer-Encoding: base64
Content-Type: text/plain;
	charset="iso-8859-1"

--=====003_Dragon335055162862_=====
Content-Transfer-Encoding: base64
Content-Type: text/html;
	charset="iso-8859-1"

--=====003_Dragon335055162862_=====--

Content-Class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Sun, 17 Sep 2006 08:34:45 -0700
From: Ryan Hurst <[email-masked]>
To: Ryan Hurst <[email-masked]>, Stefan Santesson <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, Stephen Farrell <[email-masked]>
CC: <[email-masked]>, Bernard Aboba <[email-masked]>
Sender: [email-masked]

Well Stefan and I spoke off-line; I now that I better understand the
scope of the proposal (recommendations for indirect CRLs for CA issuing
CAs only) I am OK.

:)

Ryan
-----Original Message-----
From: Ryan Hurst 
Sent: Thursday, September 14, 2006 2:17 PM
To: Stefan Santesson; Hallam-Baker, Phillip; Stephen Farrell
Cc: [email-masked]; Bernard Aboba
Subject: RE: Certs in CRLs - New standards task?

I understand - I am not sure you understand my scenario, lets sync
off-line.

-----Original Message-----
From: Stefan Santesson 
Sent: Thursday, September 14, 2006 2:14 PM
To: Ryan Hurst; Hallam-Baker, Phillip; Stephen Farrell
Cc: [email-masked]; Bernard Aboba
Subject: RE: Certs in CRLs - New standards task?

>From RFC 3280bis

   The authority information access extension indicates how to access
   information and services for the issuer of the certificate in which
   the extension appears.  Information and services may include on-line
   validation services and CA policy data.  (The location of CRLs is not
   specified in this extension; that information is provided by the
   cRLDistributionPoints extension.)

I don't like to change the way clients retrieve CRLs.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: Ryan Hurst
> Sent: den 14 september 2006 13:38
> To: Stefan Santesson; Hallam-Baker, Phillip; Stephen Farrell
> Cc: [email-masked]; Bernard Aboba
> Subject: RE: Certs in CRLs - New standards task?
> 
> I have chatted a bit with Stefan off-line about this, I have some
> concerns with embedding certificate chains into CRLs (although I
> appreciate the allure of such a approach, especially in catch 22
> scenarios where net connectivity isn't there yet).
> 
> My largest concern is related to object size, recently I joined the
> Networking Team here at Microsoft and have been reviewing some of our
> PKI related problems; one of the most significant ends up being
> performance of PKI based protocols on high latency links (India to the
> US for example).
> 
> A great example of this class of problem can be seen in EAP, EAP can
be
> thought of as  kind of like PAM for layer 2 systems; it is used as the
> basis of pre-IP authentication scenarios (think 802.1x); EAP itself
> does not provide security services but instead relies on the
> authentication protocol (method) being used within EAP to provide
these
> services. Many EAP methods use TLS as the basis of the security
> properties they offer (EAP-FAST, EAP-TTLS, EAP-TLS, PEAP, etc.); these
> protocols all suffer significant performance problems with long chains
> since EAP doesn't provide real support for fragmentation.
> 
> In the case of the certificate chain related problems in PEAP a 32k
> server chain results in about 20 roundtrips, if you think about that
in
> the context of a roaming wireless user that might experience 1% or
more
> packet loss this is a big deal.
> 
> Although no formal solutions exist here today, we can deal with at the
> authentication protocol layer by implementing models that allow for a
> client to indicate he doesn't need the protocol to provide it all of
> the supplemental evidence (crls, ocsp, intermediates); once you embed
> this data into the object all of the time you remove this capability
as
> it becomes a all or nothing proposition.
> 
> With that in mind I prefer models where the client has a choice of
> which format of the crl to get (the skinny one [never thought I would
> call any crl skinny], or the one with my build :p).
> 
> Have you considered the idea of introducing a new access method to the
> AIA that would point to a P7c that possibly contained the CRL, its
> issuers and maybe the certificates issuers?
> 
> Ryan
> 
> 
> 
> [email-masked]] On Behalf Of Stefan Santesson
> Sent: Thursday, September 14, 2006 10:30 AM
> To: Hallam-Baker, Phillip; Stephen Farrell
> Cc: [email-masked]
> Subject: RE: Certs in CRLs - New standards task?
> 
> 
> I'm open to all solutions that in an effective and practical way
solves
> the issue.
> 
> The reason I primary suggested a non-critical CRL extension was to not
> disturb how legacy clients are configured to fetch CRL's and the
format
> they expect them to arrive.
> 
> RFC 3280bis states.
> 
>    If the DistributionPointName contains a general name of type URI,
> the
>    following semantics MUST be assumed: the URI is a pointer to the
>    current CRL for the associated reasons and will be issued by the
>    associated cRLIssuer.  When the HTTP or FTP scheme is specified,
the
>    URI MUST point to a CRL file.  The CRL file MUST contain a single
> DER
>    encoded CRL as specified in [RFC 2585].
> 
> As such I feel uncertain of the impacts on legacy implementations if a
> bag of CRL+Certs is returned. But if this can be done in a smooth way
> without causing problems, then I'm all ear.
> 
> A non critical CRL extension with a certificate path would simply be
> ignored by legacy clients and would not cause any backwards
> compatibility problems. Thus it seems like an easier path to me.
> 
> I don't believe the CA need to issue one CRL with certs and one
> without,
> as David Kemp suggest. One CRL with a non-critical extension with
certs
> would work for all. And this would not be included in the common CRLs
> of
> today. It would only be a case for indirect CRLs and possibly when a
> rekeyed CA take over revocation of certs issued under an older key.
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > From: Hallam-Baker, Phillip [mailto:[email-masked]]
> > Sent: den 14 september 2006 07:09
> > To: Stephen Farrell; Stefan Santesson
> > Cc: [email-masked]
> > Subject: RE: Certs in CRLs - New standards task?
> >
> > I would prefer a bag as well, DIME would be ideal but I guess this
> > group would want something ASN.1
> >
> > Provided BER encoding is allowed I don't see a problem.
> >
> >
> > Another area where the same problem comes up is when using logotype,
> it
> > would be nice to be able to deliver the certificate and the logo in
> one
> > bag. Currently I am using MIME for this.
> >
> >
> > I would tend to see this as an HTTP extension rather than a PKIX
> > extension. We already have MIME archives of HTML documents with
> > interelated parts. This would be fine for small CRLs but for large
> CRLs
> > you really do need binary encoding not base 64.
> >
> >
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Stephen Farrell
> > > Sent: Wednesday, September 13, 2006 5:46 PM
> > > To: Stefan Santesson
> > > Cc: [email-masked]
> > > Subject: Re: Certs in CRLs - New standards task?
> > >
> > >
> > >
> > >
> > > Stefan Santesson wrote:
> > > > I would like to hear the opinion of this group on this.
> > >
> > > Sounds like an interesting idea - would like to see a draft
> > > all right. (Though David Kemp's idea of wrapping the cert and
> > > CRL a bag might also be worth investigating, depending on the
> > > CRL consuming protocols one is considering.)
> > >
> > > However, I'd have to wonder whether extending the life of the
> > > PKIX WG by another couple of years would be the right approach.
> > > Would it be better to first consider re-chartering or else
> > > chartering a new WG? (I'm not saying I think either is the
> > > way to go, but PKIX has been on the go for a looong time.)
> > >
> > > S.
> > >
> > >
> > >
> 

Content-class: urn:content-classes:message
Subject: RE: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
Date: Sat, 16 Sep 2006 19:01:03 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: "David A. Cooper" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

Tom,

I can see the path length usefulness (specifically path length = 0)when
a CA is validating one of its trusted operator certificates.

Do you see other usage of setting the value (to 0 or some non-zero)
value.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Saturday, September 16, 2006 5:57 PM
To: Santosh Chokhani
Cc: David A. Cooper; pkix
Subject: RE: 3280 Bis: Initial Values for Permitted and Excluded
Subtrees

        I'm for this too.  Does including max_path_length make sense as 
well?  I believe that it does.  Setting it to 0, in particular, trusts a

CA to issue end-entity certificates without trusting it to issue cross 
certificates.

                Tom Gindin

"Santosh Chokhani" <[email-masked]> 
Sent by: [email-masked]
09/15/2006 09:55 PM

To
"David A. Cooper" <[email-masked]>, "pkix" <[email-masked]>
cc

Subject
RE: 3280 Bis: Initial Values for Permitted and Excluded Subtrees

David,
 
I would request that we do that, i.e., make it explicit in
initialization.
 
Thanks.

From: [email-masked] [mailto:[email-masked]]

On Behalf Of David A. Cooper
Sent: Friday, September 15, 2006 5:51 PM
To: pkix
Subject: Re: 3280 Bis: Initial Values for Permitted and Excluded
Subtrees
 
Russ Housley wrote: 
I have been thinking about this, and I think it would be a very good
idea 
to add these.  The algorithm in section 6 already has state variables
for 
permitted and excluded subtrees.  This is a minor change to permit them
to 
be initialized to algorithm input values.
3280bis already permits setting initial values for name constraints,
just 
not in section 6.1.  The following text appears in section 6.2 (Using
the 
Path Validation Algorithm) and is basically unchanged from RFC 3280:

         An implementation MAY augment the algorithm presented in
section 
6.1
         to further limit the set of valid certification paths that
begin 
with
         a particular trust anchor.  For example, an implementation MAY 
modify
         the algorithm to apply name constraints to a specific trust 
anchor
         during the initialization phase, ....

Of course, 3280bis could formally add the initialization of permitted
and 
excluded subtrees to the path validation algorithm by adding it to
section 
6.1.  Since RFC 3280 and 3280bis already permit this it wouldn't really
be 
a change, it would just make the option more visible.  So, I would have
no 
objection to moving this option to section 6.1.

Dave

At 07:00 PM 8/24/2006, Santosh Chokhani wrote:

All,
 
The new version of X.509 (2005 Edition) permits initial values other
than 
infinity and null for permitted and excluded subtrees respectively.
 
Should we also revise 3280Bis to include these options so that the
relying 
parties can constrain the trust anchors?
 
I would consider infinity and null values only for the two respective 
fields still compliant with the applicable standard.
 
Thanks in advance for your opinion.

Santosh Chokhani 
Orion Security Solutions, Inc. 
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101 
(703) 917-0060 Ext. 35 (voice) 
(703) 917-0260 (Fax) 
[email-masked] 
Visit our Web site 
http://www.orionsec.com 

To: "Santosh Chokhani" <[email-masked]>
Cc: "David A. Cooper" <[email-masked]>, "pkix" <[email-masked]>
Subject: RE: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
From: Tom Gindin <[email-masked]>
Date: Sat, 16 Sep 2006 17:57:23 -0400
Sender: [email-masked]

        I'm for this too.  Does including max_path_length make sense as 
well?  I believe that it does.  Setting it to 0, in particular, trusts a 
CA to issue end-entity certificates without trusting it to issue cross 
certificates.

                Tom Gindin

"Santosh Chokhani" <[email-masked]> 
Sent by: [email-masked]
09/15/2006 09:55 PM

To
"David A. Cooper" <[email-masked]>, "pkix" <[email-masked]>
cc

Subject
RE: 3280 Bis: Initial Values for Permitted and Excluded Subtrees

David,
 
I would request that we do that, i.e., make it explicit in initialization.
 
Thanks.

From: [email-masked] [mailto:[email-masked]] 
On Behalf Of David A. Cooper
Sent: Friday, September 15, 2006 5:51 PM
To: pkix
Subject: Re: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
 
Russ Housley wrote: 
I have been thinking about this, and I think it would be a very good idea 
to add these.  The algorithm in section 6 already has state variables for 
permitted and excluded subtrees.  This is a minor change to permit them to 
be initialized to algorithm input values.
3280bis already permits setting initial values for name constraints, just 
not in section 6.1.  The following text appears in section 6.2 (Using the 
Path Validation Algorithm) and is basically unchanged from RFC 3280:

         An implementation MAY augment the algorithm presented in section 
6.1
         to further limit the set of valid certification paths that begin 
with
         a particular trust anchor.  For example, an implementation MAY 
modify
         the algorithm to apply name constraints to a specific trust 
anchor
         during the initialization phase, ....

Of course, 3280bis could formally add the initialization of permitted and 
excluded subtrees to the path validation algorithm by adding it to section 
6.1.  Since RFC 3280 and 3280bis already permit this it wouldn't really be 
a change, it would just make the option more visible.  So, I would have no 
objection to moving this option to section 6.1.

Dave

At 07:00 PM 8/24/2006, Santosh Chokhani wrote:

All,
 
The new version of X.509 (2005 Edition) permits initial values other than 
infinity and null for permitted and excluded subtrees respectively.
 
Should we also revise 3280Bis to include these options so that the relying 
parties can constrain the trust anchors?
 
I would consider infinity and null values only for the two respective 
fields still compliant with the applicable standard.
 
Thanks in advance for your opinion.

Santosh Chokhani 
Orion Security Solutions, Inc. 
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101 
(703) 917-0060 Ext. 35 (voice) 
(703) 917-0260 (Fax) 
[email-masked] 
Visit our Web site 
http://www.orionsec.com 

To: "Hallam-Baker, Phillip" <[email-masked]>
Cc: [email-masked], "Stefan Santesson" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Subject: RE: Certs in CRLs - New standards task?
From: Tom Gindin <[email-masked]>
Date: Sat, 16 Sep 2006 17:44:13 -0400
Sender: [email-masked]

        Phill:

        IMHO that's even uglier than defining an OTHER-NAME type 
containing a certificate.  Such a definition would have other uses, most 
of which would be equally ugly - just think of an issuer Alt Name with the 
full text of the CA certificate inside.  A CRL-specific extension has got 
to be cleaner than these.

                Tom Gindin

"Hallam-Baker, Phillip" <[email-masked]> 
Sent by: [email-masked]
09/14/2006 02:05 PM

To
"Stefan Santesson" <[email-masked]>, "Stephen Farrell" 
<[email-masked]>
cc
<[email-masked]>
Subject
RE: Certs in CRLs - New standards task?

It is a grotty hack but you could use the VALUE: URI which contains the 
raw data referenced by itself.

"VALUE:" + base64 (cert); 

Like I say.... Ugh! But....

> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Thursday, September 14, 2006 1:30 PM
> To: Hallam-Baker, Phillip; Stephen Farrell
> Cc: [email-masked]
> Subject: RE: Certs in CRLs - New standards task?
> 
> I'm open to all solutions that in an effective and practical 
> way solves the issue.
> 
> The reason I primary suggested a non-critical CRL extension 
> was to not disturb how legacy clients are configured to fetch 
> CRL's and the format they expect them to arrive.
> 
> RFC 3280bis states.
> 
>    If the DistributionPointName contains a general name of 
> type URI, the
>    following semantics MUST be assumed: the URI is a pointer to the
>    current CRL for the associated reasons and will be issued by the
>    associated cRLIssuer.  When the HTTP or FTP scheme is 
> specified, the
>    URI MUST point to a CRL file.  The CRL file MUST contain a 
> single DER
>    encoded CRL as specified in [RFC 2585].
> 
> As such I feel uncertain of the impacts on legacy 
> implementations if a bag of CRL+Certs is returned. But if 
> this can be done in a smooth way without causing problems, 
> then I'm all ear.
> 
> A non critical CRL extension with a certificate path would 
> simply be ignored by legacy clients and would not cause any 
> backwards compatibility problems. Thus it seems like an 
> easier path to me.
> 
> I don't believe the CA need to issue one CRL with certs and 
> one without, as David Kemp suggest. One CRL with a 
> non-critical extension with certs would work for all. And 
> this would not be included in the common CRLs of today. It 
> would only be a case for indirect CRLs and possibly when a 
> rekeyed CA take over revocation of certs issued under an older key.
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > From: Hallam-Baker, Phillip [mailto:[email-masked]]
> > Sent: den 14 september 2006 07:09
> > To: Stephen Farrell; Stefan Santesson
> > Cc: [email-masked]
> > Subject: RE: Certs in CRLs - New standards task?
> > 
> > I would prefer a bag as well, DIME would be ideal but I guess this 
> > group would want something ASN.1
> > 
> > Provided BER encoding is allowed I don't see a problem.
> > 
> > 
> > Another area where the same problem comes up is when using logotype,
> it
> > would be nice to be able to deliver the certificate and the logo in
> one
> > bag. Currently I am using MIME for this.
> > 
> > 
> > I would tend to see this as an HTTP extension rather than a PKIX 
> > extension. We already have MIME archives of HTML documents with 
> > interelated parts. This would be fine for small CRLs but for large
> CRLs
> > you really do need binary encoding not base 64.
> > 
> > 
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Stephen Farrell
> > > Sent: Wednesday, September 13, 2006 5:46 PM
> > > To: Stefan Santesson
> > > Cc: [email-masked]
> > > Subject: Re: Certs in CRLs - New standards task?
> > >
> > >
> > >
> > >
> > > Stefan Santesson wrote:
> > > > I would like to hear the opinion of this group on this.
> > >
> > > Sounds like an interesting idea - would like to see a draft all 
> > > right. (Though David Kemp's idea of wrapping the cert and 
> CRL a bag 
> > > might also be worth investigating, depending on the CRL consuming 
> > > protocols one is considering.)
> > >
> > > However, I'd have to wonder whether extending the life of 
> the PKIX 
> > > WG by another couple of years would be the right approach.
> > > Would it be better to first consider re-chartering or else 
> > > chartering a new WG? (I'm not saying I think either is the way to 
> > > go, but PKIX has been on the go for a looong time.)
> > >
> > > S.
> > >
> > >
> > >
> 
> 

Date: Sat, 16 Sep 2006 12:26:25 -0400
To: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
Sender: [email-masked]

<html>
<body>
David:<br><br>
You are correct.&nbsp; I just think it is worth the two paragraphs to
make the inputs more visible.&nbsp; I guess we would also need to change
the &quot;for example&quot; on section 6.1.<br><br>
Russ<br><br>
At 05:50 PM 9/15/2006, David A. Cooper wrote:<br>
<blockquote type=cite class=cite cite="">Russ Housley wrote: <br>
<blockquote type=cite class=cite cite="">I have been thinking about this,
and I think it would be a very good idea to add these.&nbsp; The
algorithm in section 6 already has state variables for permitted and
excluded subtrees.&nbsp; This is a minor change to permit them to be
initialized to algorithm input values.</blockquote>3280bis already
permits setting initial values for name constraints, just not in section
6.1.&nbsp; The following text appears in section 6.2 (Using the Path
Validation Algorithm) and is basically unchanged from RFC 3280:<br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An implementation MAY
augment the algorithm presented in section 6.1<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to further limit the set
of valid certification paths that begin with<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a particular trust
anchor.&nbsp; For example, an implementation MAY modify<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the algorithm to apply
name constraints to a specific trust anchor<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; during the
initialization phase, ....<br><br>
Of course, 3280bis could formally add the initialization of permitted and
excluded subtrees to the path validation algorithm by adding it to
section 6.1.&nbsp; Since RFC 3280 and 3280bis already permit this it
wouldn't really be a change, it would just make the option more
visible.&nbsp; So, I would have no objection to moving this option to
section 6.1.<br><br>
Dave<br><br>
<blockquote type=cite class=cite cite="">At 07:00 PM 8/24/2006, Santosh
Chokhani wrote:<br>
<blockquote type=cite class=cite cite=""><font size=2>All,<br>
&nbsp;<br>
The new version of X.509 (2005 Edition) permits initial values other than
infinity and null for permitted and excluded subtrees respectively.<br>
&nbsp;<br>
Should we also revise 3280Bis to include these options so that the
relying parties can constrain the trust anchors?<br>
&nbsp;<br>
I would consider infinity and null values only for the two respective
fields still compliant with the applicable standard.<br>
&nbsp;<br>
Thanks in advance for your opinion.<br>
</font><br>
<font size=2>Santosh Chokhani</font> <br>
<font size=2>Orion Security Solutions, Inc.</font> <br>
<font size=2>1489 Chain Bridge Road, Suite 300</font> <br>
<font size=2>McLean, Virginia 22101</font> <br>
<font size=2>(703)</font> <font size=2>917-0060</font>
<font size=2 color="#FF0000">Ext. 35</font> <font size=2>(voice)</font>
<br>
<font size=2>(703)</font> <font size=2>917-0260 (Fax)</font> <br>
<font size=2><a href="mailto:[email-masked]">
[email-masked]</a></font> <br>
<font size=2>Visit our Web site</font> <br>
<font size=2><a href="http://www.orionsec.com">http://www.orionsec.com</a>
 </font><br>
<font size=2>&nbsp;</font></blockquote></blockquote></blockquote></body>
</html>

Content-class: urn:content-classes:message
Subject: RE: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
Date: Fri, 15 Sep 2006 18:55:24 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "David A. Cooper" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6D933.26A07A0B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

David,

=20

I would request that we do that, i.e., make it explicit in
initialization.

=20

Thanks.

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: Friday, September 15, 2006 5:51 PM
To: pkix
Subject: Re: 3280 Bis: Initial Values for Permitted and Excluded
Subtrees

=20

Russ Housley wrote:=20

I have been thinking about this, and I think it would be a very good
idea to add these.  The algorithm in section 6 already has state
variables for permitted and excluded subtrees.  This is a minor change
to permit them to be initialized to algorithm input values.

3280bis already permits setting initial values for name constraints,
just not in section 6.1.  The following text appears in section 6.2
(Using the Path Validation Algorithm) and is basically unchanged from
RFC 3280:

         An implementation MAY augment the algorithm presented in
section 6.1
         to further limit the set of valid certification paths that
begin with
         a particular trust anchor.  For example, an implementation MAY
modify
         the algorithm to apply name constraints to a specific trust
anchor
         during the initialization phase, ....

Of course, 3280bis could formally add the initialization of permitted
and excluded subtrees to the path validation algorithm by adding it to
section 6.1.  Since RFC 3280 and 3280bis already permit this it wouldn't
really be a change, it would just make the option more visible.  So, I
would have no objection to moving this option to section 6.1.

Dave

At 07:00 PM 8/24/2006, Santosh Chokhani wrote:

All,
=20
The new version of X.509 (2005 Edition) permits initial values other
than infinity and null for permitted and excluded subtrees respectively.
=20
Should we also revise 3280Bis to include these options so that the
relying parties can constrain the trust anchors?
=20
I would consider infinity and null values only for the two respective
fields still compliant with the applicable standard.
=20
Thanks in advance for your opinion.

Santosh Chokhani=20
Orion Security Solutions, Inc.=20
1489 Chain Bridge Road, Suite 300=20
McLean, Virginia 22101=20
(703) 917-0060 Ext. 35 (voice)=20
(703) 917-0260 (Fax)=20
[email-masked]=20
Visit our Web site=20
http://www.orionsec.com=20
=20

=20

------_=_NextPart_001_01C6D933.26A07A0B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;
	color:black;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I would request that we do that, =
i.e.,
make it explicit in initialization.<o:p></o:p></span></font></p>

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

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

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>David A. Cooper<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, September =
15, 2006
5:51 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> pkix<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: 3280 Bis: =
Initial
Values for Permitted and Excluded Subtrees</span></font><font =
color=3Dblack><span
style=3D'color:windowtext'><o:p></o:p></span></font></p>

</div>

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

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Russ Housley wrote: =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>I have been thinking about this, and I think =
it would
be a very good idea to add these.&nbsp; The algorithm in section 6 =
already has
state variables for permitted and excluded subtrees.&nbsp; This is a =
minor change
to permit them to be initialized to algorithm input =
values.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>3280bis already permits setting initial =
values for
name constraints, just not in section 6.1.&nbsp; The following text =
appears in
section 6.2 (Using the Path Validation Algorithm) and is basically =
unchanged
from RFC 3280:<br>
<br>
&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; An implementation MAY augment the =
algorithm
presented in section 6.1<br>
&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; to further limit the set of valid
certification paths that begin with<br>
&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; a particular trust anchor.&nbsp; For =
example,
an implementation MAY modify<br>
&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; the algorithm to apply name =
constraints to a
specific trust anchor<br>
&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; during the initialization phase, =
....<br>
<br>
Of course, 3280bis could formally add the initialization of permitted =
and
excluded subtrees to the path validation algorithm by adding it to =
section
6.1.&nbsp; Since RFC 3280 and 3280bis already permit this it wouldn't =
really be
a change, it would just make the option more visible.&nbsp; So, I would =
have no
objection to moving this option to section 6.1.<br>
<br>
Dave<br>
<br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>At 07:00 PM 8/24/2006, <st1:PersonName =
w:st=3D"on">Santosh
 Chokhani</st1:PersonName> wrote:<br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:10.0pt'>All,<br>
&nbsp;<br>
The new version of X.509 (2005 Edition) permits initial values other =
than
infinity and null for permitted and excluded subtrees respectively.<br>
&nbsp;<br>
Should we also revise 3280Bis to include these options so that the =
relying
parties can constrain the trust anchors?<br>
&nbsp;<br>
I would consider infinity and null values only for the two respective =
fields
still compliant with the applicable standard.<br>
&nbsp;<br>
Thanks in advance for your opinion.<br>
</span></font><br>
<st1:PersonName w:st=3D"on"><font size=3D2><span =
style=3D'font-size:10.0pt'>Santosh
 Chokhani</span></font></st1:PersonName> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Orion Security =
Solutions, Inc.</span></font>
<br>
<st1:address w:st=3D"on"><st1:Street w:st=3D"on"><font size=3D2><span
  style=3D'font-size:10.0pt'>1489 Chain Bridge Road, Suite =
300</span></font></st1:Street>
 <br>
<st1:City w:st=3D"on"><font size=3D2><span =
style=3D'font-size:10.0pt'>McLean</span></font></st1:City><font
 size=3D2><span style=3D'font-size:10.0pt'>, <st1:State =
w:st=3D"on">Virginia</st1:State>
 <st1:PostalCode =
w:st=3D"on">22101</st1:PostalCode></span></font></st1:address> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>(703)</span></font> =
<font size=3D2><span
style=3D'font-size:10.0pt'>917-0060</span></font> <font size=3D2 =
color=3Dred><span
style=3D'font-size:10.0pt;color:red'>Ext. 35</span></font> <font =
size=3D2><span
style=3D'font-size:10.0pt'>(voice)</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>(703)</span></font> =
<font size=3D2><span
style=3D'font-size:10.0pt'>917-0260 (Fax)</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'><a
href=3D"mailto:[email-masked]">[email-masked]</a></span></f=
ont> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Visit our Web =
site</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'><a =
href=3D"http://www.orionsec.com">http://www.orionsec.com</a>
</span></font><br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&nbsp;</span></font><o:p></o:p></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C6D933.26A07A0B--

Date: Fri, 15 Sep 2006 17:50:36 -0400
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
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">
Russ Housley wrote:
<blockquote cite="[email-masked]"
 type="cite">I have been thinking about this, and I think it would be a
very good idea
to add these.&nbsp; The algorithm in section 6 already has state
variables for permitted and excluded subtrees.&nbsp; This is a minor
change to permit them to be initialized to algorithm input
values.<br>
</blockquote>
3280bis already permits setting initial values for name constraints,
just not in section 6.1.&nbsp; The following text appears in section 6.2
(Using the Path Validation Algorithm) and is basically unchanged from
RFC 3280:<br>
<br>
&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; An implementation MAY augment the algorithm presented in
section 6.1<br>
&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; to further limit the set of valid certification paths that
begin with<br>
&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; a particular trust anchor.&nbsp; For example, an implementation MAY
modify<br>
&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; the algorithm to apply name constraints to a specific trust
anchor<br>
&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; during the initialization phase, ....<br>
<br>
Of course, 3280bis could formally add the initialization of permitted
and excluded subtrees to the path validation algorithm by adding it to
section 6.1.&nbsp; Since RFC 3280 and 3280bis already permit this it
wouldn't really be a change, it would just make the option more
visible.&nbsp; So, I would have no objection to moving this option to
section 6.1.<br>
<br>
Dave<br>
<br>
<blockquote cite="[email-masked]"
 type="cite">At 07:00 PM 8/24/2006, Santosh Chokhani wrote:<br>
  <blockquote type="cite" class="cite" cite=""><font size="2">All,<br>
&nbsp;<br>
The new version of X.509 (2005 Edition) permits initial values other
than
infinity and null for permitted and excluded subtrees respectively.<br>
&nbsp;<br>
Should we also revise 3280Bis to include these options so that the
relying parties can constrain the trust anchors?<br>
&nbsp;<br>
I would consider infinity and null values only for the two respective
fields still compliant with the applicable standard.<br>
&nbsp;<br>
Thanks in advance for your opinion.<br>
    </font><br>
    <font size="2">Santosh Chokhani</font> <br>
    <font size="2">Orion Security Solutions, Inc.</font> <br>
    <font size="2">1489 Chain Bridge Road, Suite 300</font> <br>
    <font size="2">McLean, Virginia 22101</font> <br>
    <font size="2">(703)</font> <font size="2">917-0060</font> <font
 size="2">
    </font><font color="#ff0000" size="2">Ext. 35</font>
    <font size="2">(voice)</font> <br>
    <font size="2">(703)</font> <font size="2">917-0260 (Fax)</font> <br>
    <font size="2"><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></font> <br>
    <font size="2">Visit our Web site</font> <br>
    <font size="2"><a href="http://www.orionsec.com">http://www.orionsec.com</a>
    </font> <br>
    <font size="2">&nbsp;</font></blockquote>
</blockquote>
<br>
</body>
</html>

Date: Fri, 15 Sep 2006 16:11:36 -0400
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
Sender: [email-masked]

<html>
<body>
I have been thinking about this, and I think it would be a very good idea
to add these.&nbsp; The algorithm in section 6 already has state
variables for permitted and excluded subtrees.&nbsp; This is a minor
change to permit them to be initialized to algorithm input
values.<br><br>
Russ<br><br>
At 07:00 PM 8/24/2006, Santosh Chokhani wrote:<br>
<blockquote type=cite class=cite cite=""><font size=2>All,<br>
&nbsp;<br>
The new version of X.509 (2005 Edition) permits initial values other than
infinity and null for permitted and excluded subtrees respectively.<br>
&nbsp;<br>
Should we also revise 3280Bis to include these options so that the
relying parties can constrain the trust anchors?<br>
&nbsp;<br>
I would consider infinity and null values only for the two respective
fields still compliant with the applicable standard.<br>
&nbsp;<br>
Thanks in advance for your opinion.<br>
</font><br>
<font size=2>Santosh Chokhani</font> <br>
<font size=2>Orion Security Solutions, Inc.</font> <br>
<font size=2>1489 Chain Bridge Road, Suite 300</font> <br>
<font size=2>McLean, Virginia 22101</font> <br>
<font size=2>(703)</font> <font size=2>917-0060</font> <font size=2>
</font><font size=2 color="#FF0000">Ext. 35</font>
<font size=2>(voice)</font> <br>
<font size=2>(703)</font> <font size=2>917-0260 (Fax)</font> <br>
<font size=2>[email-masked]</font> <br>
<font size=2>Visit our Web site</font> <br>
<font size=2><a href="http://www.orionsec.com">http://www.orionsec.com</a>
</font> <br>
<font size=2>&nbsp;</font></blockquote></body>
</html>

Date: Fri, 15 Sep 2006 09:43:59 +0200
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: pkix <[email-masked]>
Subject: Re: R: Browser trust models & Smart cards
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Santoni Adriano wrote:
> I fully agree with Anders.
[...]
> For instance, it rejects digital signature certificates as they were 
> unknown beasts. I mean, certificates with a critical KeyUsage extension 
> with the "nonRepudiation" bit raised. If you want to use the signText() 
> function with a qualified certificate, in Mozilla/Firefox, you're out of 
> luck. Why so? Nobody seems to know or care.

This is usually the case when *BAD* CA practice force the presence of
critical extensions on very specific profiles. This is sometimes the case
of some CAs that follow national signature laws... anyway have you submitted
the bug/feature request to the Mozilla developers (bugzilla) ? If so, can you
send (me) the number of the bug #ID ?

-- 

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 062                        Work Phone: +1 (603) 646-9226
--o------------------------------------------------------------------------

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

--------------ms080207080308000503090606--

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?  "value:" scheme
Date: Fri, 15 Sep 2006 16:58:45 +1000
From: "Manger, James H" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I have heard of the "data" URL scheme (RFC 2397), but not the "value" scheme.  Is it defined somewhere?  Supported anywhere?

  data:[mine-type][;base64],data

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
Sent: Friday, 15 September 2006 4:06 AM
To: Stefan Santesson; Stephen Farrell
Cc: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

It is a grotty hack but you could use the VALUE: URI which contains the raw data referenced by itself.

"VALUE:" + base64 (cert); 

Like I say.... Ugh! But....

> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Thursday, September 14, 2006 1:30 PM
> To: Hallam-Baker, Phillip; Stephen Farrell
> Cc: [email-masked]
> Subject: RE: Certs in CRLs - New standards task?
> 
> I'm open to all solutions that in an effective and practical 
> way solves the issue.
> 
> The reason I primary suggested a non-critical CRL extension 
> was to not disturb how legacy clients are configured to fetch 
> CRL's and the format they expect them to arrive.
> 
> RFC 3280bis states.
> 
>    If the DistributionPointName contains a general name of 
> type URI, the
>    following semantics MUST be assumed: the URI is a pointer to the
>    current CRL for the associated reasons and will be issued by the
>    associated cRLIssuer.  When the HTTP or FTP scheme is 
> specified, the
>    URI MUST point to a CRL file.  The CRL file MUST contain a 
> single DER
>    encoded CRL as specified in [RFC 2585].
> 
> As such I feel uncertain of the impacts on legacy 
> implementations if a bag of CRL+Certs is returned. But if 
> this can be done in a smooth way without causing problems, 
> then I'm all ear.
> 
> A non critical CRL extension with a certificate path would 
> simply be ignored by legacy clients and would not cause any 
> backwards compatibility problems. Thus it seems like an 
> easier path to me.
> 
> I don't believe the CA need to issue one CRL with certs and 
> one without, as David Kemp suggest. One CRL with a 
> non-critical extension with certs would work for all. And 
> this would not be included in the common CRLs of today. It 
> would only be a case for indirect CRLs and possibly when a 
> rekeyed CA take over revocation of certs issued under an older key.
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > From: Hallam-Baker, Phillip [mailto:[email-masked]]
> > Sent: den 14 september 2006 07:09
> > To: Stephen Farrell; Stefan Santesson
> > Cc: [email-masked]
> > Subject: RE: Certs in CRLs - New standards task?
> > 
> > I would prefer a bag as well, DIME would be ideal but I guess this 
> > group would want something ASN.1
> > 
> > Provided BER encoding is allowed I don't see a problem.
> > 
> > 
> > Another area where the same problem comes up is when using logotype,
> it
> > would be nice to be able to deliver the certificate and the logo in
> one
> > bag. Currently I am using MIME for this.
> > 
> > 
> > I would tend to see this as an HTTP extension rather than a PKIX 
> > extension. We already have MIME archives of HTML documents with 
> > interelated parts. This would be fine for small CRLs but for large
> CRLs
> > you really do need binary encoding not base 64.
> > 
> > 
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Stephen Farrell
> > > Sent: Wednesday, September 13, 2006 5:46 PM
> > > To: Stefan Santesson
> > > Cc: [email-masked]
> > > Subject: Re: Certs in CRLs - New standards task?
> > >
> > >
> > >
> > >
> > > Stefan Santesson wrote:
> > > > I would like to hear the opinion of this group on this.
> > >
> > > Sounds like an interesting idea - would like to see a draft all 
> > > right. (Though David Kemp's idea of wrapping the cert and 
> CRL a bag 
> > > might also be worth investigating, depending on the CRL consuming 
> > > protocols one is considering.)
> > >
> > > However, I'd have to wonder whether extending the life of 
> the PKIX 
> > > WG by another couple of years would be the right approach.
> > > Would it be better to first consider re-chartering or else 
> > > chartering a new WG? (I'm not saying I think either is the way to 
> > > go, but PKIX has been on the go for a looong time.)
> > >
> > > S.
> > >
> > >
> > >
> 
> 

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: AIA - No  Issuing CA support?
Date: Thu, 14 Sep 2006 23:32:02 +0200
Sender: [email-masked]

RFC 3280   
   "The id-ad-caIssuers OID is used when the additional information lists
   CAs that have issued certificates *superior* to the CA that issued the
   certificate containing this extension.  The referenced CA issuers
   description is intended to aid certificate users in the selection of
   a certification path that terminates at a point trusted by the
   certificate user"

Assume I have a FIPS201 card (that as far as I can tell do not contain
any CA certificates at all), how can I locate the actual issuing CA?

Anders

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 14 Sep 2006 22:19:40 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Carl Wallace" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

My way of looking at this is that a CA MAY provide a bag of certs in a
CRL. Typically it would only be none or 1 certificate for the CRL Issuer
issued by a CA from the validated path, but in theory you could provide
as many certs and paths as you want.

That is purely an implementation performance choice given the community
f RPs you serve. But there is no reason I can see why a CA should have
to produce multiple versions of a CRL because of this feature.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: Carl Wallace [mailto:[email-masked]]
> Sent: den 14 september 2006 12:08
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: RE: Certs in CRLs - New standards task?
> 
> > One CRL with a non-critical extension with certs would work for all.
> 
> How?  Would it be populated with multiple paths to account for
> cross-certified environments?

Content-Class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 14 Sep 2006 14:16:47 -0700
From: Ryan Hurst <[email-masked]>
To: Stefan Santesson <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, Stephen Farrell <[email-masked]>
CC: <[email-masked]>, Bernard Aboba <[email-masked]>
Sender: [email-masked]

I understand - I am not sure you understand my scenario, lets sync
off-line.

-----Original Message-----
From: Stefan Santesson 
Sent: Thursday, September 14, 2006 2:14 PM
To: Ryan Hurst; Hallam-Baker, Phillip; Stephen Farrell
Cc: [email-masked]; Bernard Aboba
Subject: RE: Certs in CRLs - New standards task?

>From RFC 3280bis

   The authority information access extension indicates how to access
   information and services for the issuer of the certificate in which
   the extension appears.  Information and services may include on-line
   validation services and CA policy data.  (The location of CRLs is not
   specified in this extension; that information is provided by the
   cRLDistributionPoints extension.)

I don't like to change the way clients retrieve CRLs.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: Ryan Hurst
> Sent: den 14 september 2006 13:38
> To: Stefan Santesson; Hallam-Baker, Phillip; Stephen Farrell
> Cc: [email-masked]; Bernard Aboba
> Subject: RE: Certs in CRLs - New standards task?
> 
> I have chatted a bit with Stefan off-line about this, I have some
> concerns with embedding certificate chains into CRLs (although I
> appreciate the allure of such a approach, especially in catch 22
> scenarios where net connectivity isn't there yet).
> 
> My largest concern is related to object size, recently I joined the
> Networking Team here at Microsoft and have been reviewing some of our
> PKI related problems; one of the most significant ends up being
> performance of PKI based protocols on high latency links (India to the
> US for example).
> 
> A great example of this class of problem can be seen in EAP, EAP can
be
> thought of as  kind of like PAM for layer 2 systems; it is used as the
> basis of pre-IP authentication scenarios (think 802.1x); EAP itself
> does not provide security services but instead relies on the
> authentication protocol (method) being used within EAP to provide
these
> services. Many EAP methods use TLS as the basis of the security
> properties they offer (EAP-FAST, EAP-TTLS, EAP-TLS, PEAP, etc.); these
> protocols all suffer significant performance problems with long chains
> since EAP doesn't provide real support for fragmentation.
> 
> In the case of the certificate chain related problems in PEAP a 32k
> server chain results in about 20 roundtrips, if you think about that
in
> the context of a roaming wireless user that might experience 1% or
more
> packet loss this is a big deal.
> 
> Although no formal solutions exist here today, we can deal with at the
> authentication protocol layer by implementing models that allow for a
> client to indicate he doesn't need the protocol to provide it all of
> the supplemental evidence (crls, ocsp, intermediates); once you embed
> this data into the object all of the time you remove this capability
as
> it becomes a all or nothing proposition.
> 
> With that in mind I prefer models where the client has a choice of
> which format of the crl to get (the skinny one [never thought I would
> call any crl skinny], or the one with my build :p).
> 
> Have you considered the idea of introducing a new access method to the
> AIA that would point to a P7c that possibly contained the CRL, its
> issuers and maybe the certificates issuers?
> 
> Ryan
> 
> 
> 
> [email-masked]] On Behalf Of Stefan Santesson
> Sent: Thursday, September 14, 2006 10:30 AM
> To: Hallam-Baker, Phillip; Stephen Farrell
> Cc: [email-masked]
> Subject: RE: Certs in CRLs - New standards task?
> 
> 
> I'm open to all solutions that in an effective and practical way
solves
> the issue.
> 
> The reason I primary suggested a non-critical CRL extension was to not
> disturb how legacy clients are configured to fetch CRL's and the
format
> they expect them to arrive.
> 
> RFC 3280bis states.
> 
>    If the DistributionPointName contains a general name of type URI,
> the
>    following semantics MUST be assumed: the URI is a pointer to the
>    current CRL for the associated reasons and will be issued by the
>    associated cRLIssuer.  When the HTTP or FTP scheme is specified,
the
>    URI MUST point to a CRL file.  The CRL file MUST contain a single
> DER
>    encoded CRL as specified in [RFC 2585].
> 
> As such I feel uncertain of the impacts on legacy implementations if a
> bag of CRL+Certs is returned. But if this can be done in a smooth way
> without causing problems, then I'm all ear.
> 
> A non critical CRL extension with a certificate path would simply be
> ignored by legacy clients and would not cause any backwards
> compatibility problems. Thus it seems like an easier path to me.
> 
> I don't believe the CA need to issue one CRL with certs and one
> without,
> as David Kemp suggest. One CRL with a non-critical extension with
certs
> would work for all. And this would not be included in the common CRLs
> of
> today. It would only be a case for indirect CRLs and possibly when a
> rekeyed CA take over revocation of certs issued under an older key.
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > From: Hallam-Baker, Phillip [mailto:[email-masked]]
> > Sent: den 14 september 2006 07:09
> > To: Stephen Farrell; Stefan Santesson
> > Cc: [email-masked]
> > Subject: RE: Certs in CRLs - New standards task?
> >
> > I would prefer a bag as well, DIME would be ideal but I guess this
> > group would want something ASN.1
> >
> > Provided BER encoding is allowed I don't see a problem.
> >
> >
> > Another area where the same problem comes up is when using logotype,
> it
> > would be nice to be able to deliver the certificate and the logo in
> one
> > bag. Currently I am using MIME for this.
> >
> >
> > I would tend to see this as an HTTP extension rather than a PKIX
> > extension. We already have MIME archives of HTML documents with
> > interelated parts. This would be fine for small CRLs but for large
> CRLs
> > you really do need binary encoding not base 64.
> >
> >
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Stephen Farrell
> > > Sent: Wednesday, September 13, 2006 5:46 PM
> > > To: Stefan Santesson
> > > Cc: [email-masked]
> > > Subject: Re: Certs in CRLs - New standards task?
> > >
> > >
> > >
> > >
> > > Stefan Santesson wrote:
> > > > I would like to hear the opinion of this group on this.
> > >
> > > Sounds like an interesting idea - would like to see a draft
> > > all right. (Though David Kemp's idea of wrapping the cert and
> > > CRL a bag might also be worth investigating, depending on the
> > > CRL consuming protocols one is considering.)
> > >
> > > However, I'd have to wonder whether extending the life of the
> > > PKIX WG by another couple of years would be the right approach.
> > > Would it be better to first consider re-chartering or else
> > > chartering a new WG? (I'm not saying I think either is the
> > > way to go, but PKIX has been on the go for a looong time.)
> > >
> > > S.
> > >
> > >
> > >
> 

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 14 Sep 2006 22:14:25 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Ryan Hurst" <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: <[email-masked]>, "Bernard Aboba" <[email-masked]>
Sender: [email-masked]

>From RFC 3280bis

   The authority information access extension indicates how to access
   information and services for the issuer of the certificate in which
   the extension appears.  Information and services may include on-line
   validation services and CA policy data.  (The location of CRLs is not
   specified in this extension; that information is provided by the
   cRLDistributionPoints extension.)

I don't like to change the way clients retrieve CRLs.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: Ryan Hurst
> Sent: den 14 september 2006 13:38
> To: Stefan Santesson; Hallam-Baker, Phillip; Stephen Farrell
> Cc: [email-masked]; Bernard Aboba
> Subject: RE: Certs in CRLs - New standards task?
> 
> I have chatted a bit with Stefan off-line about this, I have some
> concerns with embedding certificate chains into CRLs (although I
> appreciate the allure of such a approach, especially in catch 22
> scenarios where net connectivity isn't there yet).
> 
> My largest concern is related to object size, recently I joined the
> Networking Team here at Microsoft and have been reviewing some of our
> PKI related problems; one of the most significant ends up being
> performance of PKI based protocols on high latency links (India to the
> US for example).
> 
> A great example of this class of problem can be seen in EAP, EAP can
be
> thought of as  kind of like PAM for layer 2 systems; it is used as the
> basis of pre-IP authentication scenarios (think 802.1x); EAP itself
> does not provide security services but instead relies on the
> authentication protocol (method) being used within EAP to provide
these
> services. Many EAP methods use TLS as the basis of the security
> properties they offer (EAP-FAST, EAP-TTLS, EAP-TLS, PEAP, etc.); these
> protocols all suffer significant performance problems with long chains
> since EAP doesn't provide real support for fragmentation.
> 
> In the case of the certificate chain related problems in PEAP a 32k
> server chain results in about 20 roundtrips, if you think about that
in
> the context of a roaming wireless user that might experience 1% or
more
> packet loss this is a big deal.
> 
> Although no formal solutions exist here today, we can deal with at the
> authentication protocol layer by implementing models that allow for a
> client to indicate he doesn't need the protocol to provide it all of
> the supplemental evidence (crls, ocsp, intermediates); once you embed
> this data into the object all of the time you remove this capability
as
> it becomes a all or nothing proposition.
> 
> With that in mind I prefer models where the client has a choice of
> which format of the crl to get (the skinny one [never thought I would
> call any crl skinny], or the one with my build :p).
> 
> Have you considered the idea of introducing a new access method to the
> AIA that would point to a P7c that possibly contained the CRL, its
> issuers and maybe the certificates issuers?
> 
> Ryan
> 
> 
> 
> [email-masked]] On Behalf Of Stefan Santesson
> Sent: Thursday, September 14, 2006 10:30 AM
> To: Hallam-Baker, Phillip; Stephen Farrell
> Cc: [email-masked]
> Subject: RE: Certs in CRLs - New standards task?
> 
> 
> I'm open to all solutions that in an effective and practical way
solves
> the issue.
> 
> The reason I primary suggested a non-critical CRL extension was to not
> disturb how legacy clients are configured to fetch CRL's and the
format
> they expect them to arrive.
> 
> RFC 3280bis states.
> 
>    If the DistributionPointName contains a general name of type URI,
> the
>    following semantics MUST be assumed: the URI is a pointer to the
>    current CRL for the associated reasons and will be issued by the
>    associated cRLIssuer.  When the HTTP or FTP scheme is specified,
the
>    URI MUST point to a CRL file.  The CRL file MUST contain a single
> DER
>    encoded CRL as specified in [RFC 2585].
> 
> As such I feel uncertain of the impacts on legacy implementations if a
> bag of CRL+Certs is returned. But if this can be done in a smooth way
> without causing problems, then I'm all ear.
> 
> A non critical CRL extension with a certificate path would simply be
> ignored by legacy clients and would not cause any backwards
> compatibility problems. Thus it seems like an easier path to me.
> 
> I don't believe the CA need to issue one CRL with certs and one
> without,
> as David Kemp suggest. One CRL with a non-critical extension with
certs
> would work for all. And this would not be included in the common CRLs
> of
> today. It would only be a case for indirect CRLs and possibly when a
> rekeyed CA take over revocation of certs issued under an older key.
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > From: Hallam-Baker, Phillip [mailto:[email-masked]]
> > Sent: den 14 september 2006 07:09
> > To: Stephen Farrell; Stefan Santesson
> > Cc: [email-masked]
> > Subject: RE: Certs in CRLs - New standards task?
> >
> > I would prefer a bag as well, DIME would be ideal but I guess this
> > group would want something ASN.1
> >
> > Provided BER encoding is allowed I don't see a problem.
> >
> >
> > Another area where the same problem comes up is when using logotype,
> it
> > would be nice to be able to deliver the certificate and the logo in
> one
> > bag. Currently I am using MIME for this.
> >
> >
> > I would tend to see this as an HTTP extension rather than a PKIX
> > extension. We already have MIME archives of HTML documents with
> > interelated parts. This would be fine for small CRLs but for large
> CRLs
> > you really do need binary encoding not base 64.
> >
> >
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Stephen Farrell
> > > Sent: Wednesday, September 13, 2006 5:46 PM
> > > To: Stefan Santesson
> > > Cc: [email-masked]
> > > Subject: Re: Certs in CRLs - New standards task?
> > >
> > >
> > >
> > >
> > > Stefan Santesson wrote:
> > > > I would like to hear the opinion of this group on this.
> > >
> > > Sounds like an interesting idea - would like to see a draft
> > > all right. (Though David Kemp's idea of wrapping the cert and
> > > CRL a bag might also be worth investigating, depending on the
> > > CRL consuming protocols one is considering.)
> > >
> > > However, I'd have to wonder whether extending the life of the
> > > PKIX WG by another couple of years would be the right approach.
> > > Would it be better to first consider re-chartering or else
> > > chartering a new WG? (I'm not saying I think either is the
> > > way to go, but PKIX has been on the go for a looong time.)
> > >
> > > S.
> > >
> > >
> > >
> 

Content-Class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 14 Sep 2006 13:38:12 -0700
From: Ryan Hurst <[email-masked]>
To: Stefan Santesson <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>, Stephen Farrell <[email-masked]>
CC: <[email-masked]>, Bernard Aboba <[email-masked]>
Sender: [email-masked]

I have chatted a bit with Stefan off-line about this, I have some
concerns with embedding certificate chains into CRLs (although I
appreciate the allure of such a approach, especially in catch 22
scenarios where net connectivity isn't there yet).

My largest concern is related to object size, recently I joined the
Networking Team here at Microsoft and have been reviewing some of our
PKI related problems; one of the most significant ends up being
performance of PKI based protocols on high latency links (India to the
US for example).

A great example of this class of problem can be seen in EAP, EAP can be
thought of as  kind of like PAM for layer 2 systems; it is used as the
basis of pre-IP authentication scenarios (think 802.1x); EAP itself does
not provide security services but instead relies on the authentication
protocol (method) being used within EAP to provide these services. Many
EAP methods use TLS as the basis of the security properties they offer
(EAP-FAST, EAP-TTLS, EAP-TLS, PEAP, etc.); these protocols all suffer
significant performance problems with long chains since EAP doesn't
provide real support for fragmentation.

In the case of the certificate chain related problems in PEAP a 32k
server chain results in about 20 roundtrips, if you think about that in
the context of a roaming wireless user that might experience 1% or more
packet loss this is a big deal.

Although no formal solutions exist here today, we can deal with at the
authentication protocol layer by implementing models that allow for a
client to indicate he doesn't need the protocol to provide it all of the
supplemental evidence (crls, ocsp, intermediates); once you embed this
data into the object all of the time you remove this capability as it
becomes a all or nothing proposition.

With that in mind I prefer models where the client has a choice of which
format of the crl to get (the skinny one [never thought I would call any
crl skinny], or the one with my build :p).

Have you considered the idea of introducing a new access method to the
AIA that would point to a P7c that possibly contained the CRL, its
issuers and maybe the certificates issuers?

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Thursday, September 14, 2006 10:30 AM
To: Hallam-Baker, Phillip; Stephen Farrell
Cc: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

I'm open to all solutions that in an effective and practical way solves
the issue.

The reason I primary suggested a non-critical CRL extension was to not
disturb how legacy clients are configured to fetch CRL's and the format
they expect them to arrive.

RFC 3280bis states.

   If the DistributionPointName contains a general name of type URI, the
   following semantics MUST be assumed: the URI is a pointer to the
   current CRL for the associated reasons and will be issued by the
   associated cRLIssuer.  When the HTTP or FTP scheme is specified, the
   URI MUST point to a CRL file.  The CRL file MUST contain a single DER
   encoded CRL as specified in [RFC 2585].

As such I feel uncertain of the impacts on legacy implementations if a
bag of CRL+Certs is returned. But if this can be done in a smooth way
without causing problems, then I'm all ear.

A non critical CRL extension with a certificate path would simply be
ignored by legacy clients and would not cause any backwards
compatibility problems. Thus it seems like an easier path to me.

I don't believe the CA need to issue one CRL with certs and one without,
as David Kemp suggest. One CRL with a non-critical extension with certs
would work for all. And this would not be included in the common CRLs of
today. It would only be a case for indirect CRLs and possibly when a
rekeyed CA take over revocation of certs issued under an older key.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: Hallam-Baker, Phillip [mailto:[email-masked]]
> Sent: den 14 september 2006 07:09
> To: Stephen Farrell; Stefan Santesson
> Cc: [email-masked]
> Subject: RE: Certs in CRLs - New standards task?
> 
> I would prefer a bag as well, DIME would be ideal but I guess this
> group would want something ASN.1
> 
> Provided BER encoding is allowed I don't see a problem.
> 
> 
> Another area where the same problem comes up is when using logotype,
it
> would be nice to be able to deliver the certificate and the logo in
one
> bag. Currently I am using MIME for this.
> 
> 
> I would tend to see this as an HTTP extension rather than a PKIX
> extension. We already have MIME archives of HTML documents with
> interelated parts. This would be fine for small CRLs but for large
CRLs
> you really do need binary encoding not base 64.
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stephen Farrell
> > Sent: Wednesday, September 13, 2006 5:46 PM
> > To: Stefan Santesson
> > Cc: [email-masked]
> > Subject: Re: Certs in CRLs - New standards task?
> >
> >
> >
> >
> > Stefan Santesson wrote:
> > > I would like to hear the opinion of this group on this.
> >
> > Sounds like an interesting idea - would like to see a draft
> > all right. (Though David Kemp's idea of wrapping the cert and
> > CRL a bag might also be worth investigating, depending on the
> > CRL consuming protocols one is considering.)
> >
> > However, I'd have to wonder whether extending the life of the
> > PKIX WG by another couple of years would be the right approach.
> > Would it be better to first consider re-chartering or else
> > chartering a new WG? (I'm not saying I think either is the
> > way to go, but PKIX has been on the go for a looong time.)
> >
> > S.
> >
> >
> >

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 14 Sep 2006 12:07:38 -0700
From: "Carl Wallace" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> One CRL with a non-critical extension with certs would work for all. 

How?  Would it be populated with multiple paths to account for
cross-certified environments?

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 14 Sep 2006 11:05:30 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

It is a grotty hack but you could use the VALUE: URI which contains the raw data referenced by itself.

"VALUE:" + base64 (cert); 

Like I say.... Ugh! But....

> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Thursday, September 14, 2006 1:30 PM
> To: Hallam-Baker, Phillip; Stephen Farrell
> Cc: [email-masked]
> Subject: RE: Certs in CRLs - New standards task?
> 
> I'm open to all solutions that in an effective and practical 
> way solves the issue.
> 
> The reason I primary suggested a non-critical CRL extension 
> was to not disturb how legacy clients are configured to fetch 
> CRL's and the format they expect them to arrive.
> 
> RFC 3280bis states.
> 
>    If the DistributionPointName contains a general name of 
> type URI, the
>    following semantics MUST be assumed: the URI is a pointer to the
>    current CRL for the associated reasons and will be issued by the
>    associated cRLIssuer.  When the HTTP or FTP scheme is 
> specified, the
>    URI MUST point to a CRL file.  The CRL file MUST contain a 
> single DER
>    encoded CRL as specified in [RFC 2585].
> 
> As such I feel uncertain of the impacts on legacy 
> implementations if a bag of CRL+Certs is returned. But if 
> this can be done in a smooth way without causing problems, 
> then I'm all ear.
> 
> A non critical CRL extension with a certificate path would 
> simply be ignored by legacy clients and would not cause any 
> backwards compatibility problems. Thus it seems like an 
> easier path to me.
> 
> I don't believe the CA need to issue one CRL with certs and 
> one without, as David Kemp suggest. One CRL with a 
> non-critical extension with certs would work for all. And 
> this would not be included in the common CRLs of today. It 
> would only be a case for indirect CRLs and possibly when a 
> rekeyed CA take over revocation of certs issued under an older key.
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > From: Hallam-Baker, Phillip [mailto:[email-masked]]
> > Sent: den 14 september 2006 07:09
> > To: Stephen Farrell; Stefan Santesson
> > Cc: [email-masked]
> > Subject: RE: Certs in CRLs - New standards task?
> > 
> > I would prefer a bag as well, DIME would be ideal but I guess this 
> > group would want something ASN.1
> > 
> > Provided BER encoding is allowed I don't see a problem.
> > 
> > 
> > Another area where the same problem comes up is when using logotype,
> it
> > would be nice to be able to deliver the certificate and the logo in
> one
> > bag. Currently I am using MIME for this.
> > 
> > 
> > I would tend to see this as an HTTP extension rather than a PKIX 
> > extension. We already have MIME archives of HTML documents with 
> > interelated parts. This would be fine for small CRLs but for large
> CRLs
> > you really do need binary encoding not base 64.
> > 
> > 
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Stephen Farrell
> > > Sent: Wednesday, September 13, 2006 5:46 PM
> > > To: Stefan Santesson
> > > Cc: [email-masked]
> > > Subject: Re: Certs in CRLs - New standards task?
> > >
> > >
> > >
> > >
> > > Stefan Santesson wrote:
> > > > I would like to hear the opinion of this group on this.
> > >
> > > Sounds like an interesting idea - would like to see a draft all 
> > > right. (Though David Kemp's idea of wrapping the cert and 
> CRL a bag 
> > > might also be worth investigating, depending on the CRL consuming 
> > > protocols one is considering.)
> > >
> > > However, I'd have to wonder whether extending the life of 
> the PKIX 
> > > WG by another couple of years would be the right approach.
> > > Would it be better to first consider re-chartering or else 
> > > chartering a new WG? (I'm not saying I think either is the way to 
> > > go, but PKIX has been on the go for a looong time.)
> > >
> > > S.
> > >
> > >
> > >
> 
> 

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 14 Sep 2006 18:39:17 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Kemp David P." <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6D824.B4FC88BD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dave,

=20

I agree that the DoS attack threat is not major so we should not pitch
that as a primary reason for doing this.

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: Kemp David P. [mailto:[email-masked]]=20
Sent: den 13 september 2006 14:22
To: Stefan Santesson; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

=20

Stefan,

=20

I'm skeptical that including a certificate path within the security
envelope of a CRL is the best approach.  In many cases (particularly in
ARLs which should normally be empty) this would add considerable
overhead.  And even in CRLs which are 10x the size of the CRL issuer's
cert path, that extra 10% bandwidth penalty is repeated every time a CRL
is fetched, not just every time a new CRL issuer cert is needed.  Since
CRLs are updated much more frequently than certs, binding them together
forces unnecessary bandwidth inefficiencies.

=20

Issue #2 is not real:  because you cannot make this feature mandatory
(i.e. prohibit the use of AIA in CRLs), you cannot write applications
that refuse to execute AIA and thus refuse to participate in DoS
attacks.  Instead, to avoid this issue applications should not fetch a
CRL from certificates that do not trace back to a trust anchor.  If a
trusted certificate has a rogue AIA, there are bigger problems than DoS.

=20

To address Issue #1, it would be preferable to define a bag that
contains both a CRL and the CRL issuer cert path.  That way CRL issuers
would not be forced to generate both cert-extension CRLs and normal
CRLs.  The bag could instead be generated on demand by the CRL
repository or by local proxies.

=20

Dave Kemp

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Wednesday, September 13, 2006 12:08 PM
To: [email-masked]
Subject: Certs in CRLs - New standards task?

=20

Taking the pkix chair hat off and the vendor hat on

=20

I'm asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed
CA. I.e. where the target certificate and it's CRL are signed by
different keys and the RP does not have access to the CRL Issuer
certificate.

=20

It is basically the same situation we solved with allowing the AIA
extension in CRL's namely the problem to obtain the CRL issuer's
certificate, alternatively, certificate path.

=20

In our efforts to implement the AIA solution we have encountered some
real issues.

=20

1)  Each time we are forced to go out and retrieve new information on
the network, we have a source of potential problems such as unavailable
network resources, timeouts etc. It all adds to the validation time and
harms the user experience.

2)  The AIA in CRL's provide another opening for DoS attacks if rouge
CRL's point their AIA to a targeted web server. This is tough not as
serious as the DoS problems with AIA in certificates, but this one we
might avoid more easily.

=20

The proposed solution is to define a new CRL extension that may contain
the CRL Issuer certificate (not just a URL to its location). Preferably
this would be a PKCS#7 (or CMS) Certs only message that may contain a
single certificate or a bag of certificates (a chain).

=20

While it wouldn't be attractive to define such extension for
certificates due to certificate size considerations, CRL's are often of
such size that including the certs needed to validate it only leads to
an insignificant increase of size, while it may offer substantial
processing advantages.

=20

I would like to hear the opinion of this group on this.

=20

I volunteer to write a first draft if there is interest from the group.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

------_=_NextPart_001_01C6D824.B4FC88BD
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1468089912;
	mso-list-type:hybrid;
	mso-list-template-ids:-795188044 69009425 69009433 69009435 69009423 =
69009433 69009435 69009423 69009433 69009435;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I agree that the DoS attack threat is not major so we =
should not
pitch that as a primary reason for doing this.<o:p></o:p></span></p>

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

<div>

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

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

</div>

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

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

<div>

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

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Kemp David P.
[mailto:[email-masked]] <br>
<b>Sent:</b> den 13 september 2006 14:22<br>
<b>To:</b> Stefan Santesson; [email-masked]<br>
<b>Subject:</b> RE: Certs in CRLs - New standards =
task?<o:p></o:p></span></p>

</div>

</div>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>Stefan,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>I&#8217;m skeptical that including a certificate path within =
the
security envelope of a CRL is the best approach. &nbsp;In many cases
(particularly in ARLs which should normally be empty) this would add =
considerable
overhead. &nbsp;And even in CRLs which are 10x the size of the CRL
issuer&#8217;s cert path, that extra 10% bandwidth penalty is repeated =
every
time a CRL is fetched, not just every time a new CRL issuer cert is
needed.&nbsp; Since CRLs are updated much more frequently than certs, =
binding
them together forces unnecessary bandwidth =
inefficiencies.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>Issue #2 is not real:&nbsp; because you cannot make this =
feature
mandatory (i.e. prohibit the use of AIA in CRLs), you cannot write =
applications
that refuse to execute AIA and thus refuse to participate in DoS =
attacks.
&nbsp;Instead, to avoid this issue applications should not fetch a CRL =
from
certificates that do not trace back to a trust anchor. &nbsp;If a =
trusted
certificate has a rogue AIA, there are bigger problems than =
DoS.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>To address Issue #1, it would be preferable to define a bag =
that
contains both a CRL and the CRL issuer cert path.&nbsp; That way CRL =
issuers
would not be forced to generate both cert-extension CRLs and normal =
CRLs.&nbsp;
The bag could instead be generated on demand by the CRL repository or by =
local
proxies.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>Dave Kemp<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span =
lang=3DEN-US>

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

</span></div>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Stefan =
Santesson<br>
<b>Sent:</b> Wednesday, September 13, 2006 12:08 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Certs in CRLs - New standards task?</span><span =
lang=3DEN-US><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Taking
the pkix chair hat off and the vendor hat on<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I&#8217;m
asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed =
CA. I.e.
where the target certificate and it&#8217;s CRL are signed by different =
keys
and the RP does not have access to the CRL Issuer =
certificate.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>It
is basically the same situation we solved with allowing the AIA =
extension in
CRL&#8217;s namely the problem to obtain the CRL issuer&#8217;s =
certificate,
alternatively, certificate path.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>In
our efforts to implement the AIA solution we have encountered some real =
issues.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><span
style=3D'mso-list:Ignore'>1)<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp; </span></span></span><![endif]><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Each time
we are forced to go out and retrieve new information on the network, we =
have a
source of potential problems such as unavailable network resources, =
timeouts
etc. It all adds to the validation time and harms the user =
experience.<o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><span
style=3D'mso-list:Ignore'>2)<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp; </span></span></span><![endif]><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>The AIA in
CRL&#8217;s provide another opening for DoS attacks if rouge CRL&#8217;s =
point
their AIA to a targeted web server. This is tough not as serious as the =
DoS
problems with AIA in certificates, but this one we might avoid more =
easily.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>The
proposed solution is to define a new CRL extension that may contain the =
CRL
Issuer certificate (not just a URL to its location). Preferably this =
would be a
PKCS#7 (or CMS) Certs only message that may contain a single certificate =
or a
bag of certificates (a chain).<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>While
it wouldn&#8217;t be attractive to define such extension for =
certificates due
to certificate size considerations, CRL&#8217;s are often of such size =
that
including the certs needed to validate it only leads to an insignificant
increase of size, while it may offer substantial processing =
advantages.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I
would like to hear the opinion of this group on =
this.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>I
volunteer to write a first draft if there is interest from the =
group.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><strong><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:maroon'>Stefan Santesson</span></strong><span
lang=3DEN-GB><o:p></o:p></span></p>

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

<p class=3DMsoNormal><strong><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:#400040'>Windows Security, =
Standards</span></strong><span
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB><o:p>&nbsp;</o:p></span></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C6D824.B4FC88BD--

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 14 Sep 2006 18:29:48 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I'm open to all solutions that in an effective and practical way solves
the issue.

The reason I primary suggested a non-critical CRL extension was to not
disturb how legacy clients are configured to fetch CRL's and the format
they expect them to arrive.

RFC 3280bis states.

   If the DistributionPointName contains a general name of type URI, the
   following semantics MUST be assumed: the URI is a pointer to the
   current CRL for the associated reasons and will be issued by the
   associated cRLIssuer.  When the HTTP or FTP scheme is specified, the
   URI MUST point to a CRL file.  The CRL file MUST contain a single DER
   encoded CRL as specified in [RFC 2585].

As such I feel uncertain of the impacts on legacy implementations if a
bag of CRL+Certs is returned. But if this can be done in a smooth way
without causing problems, then I'm all ear.

A non critical CRL extension with a certificate path would simply be
ignored by legacy clients and would not cause any backwards
compatibility problems. Thus it seems like an easier path to me.

I don't believe the CA need to issue one CRL with certs and one without,
as David Kemp suggest. One CRL with a non-critical extension with certs
would work for all. And this would not be included in the common CRLs of
today. It would only be a case for indirect CRLs and possibly when a
rekeyed CA take over revocation of certs issued under an older key.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: Hallam-Baker, Phillip [mailto:[email-masked]]
> Sent: den 14 september 2006 07:09
> To: Stephen Farrell; Stefan Santesson
> Cc: [email-masked]
> Subject: RE: Certs in CRLs - New standards task?
> 
> I would prefer a bag as well, DIME would be ideal but I guess this
> group would want something ASN.1
> 
> Provided BER encoding is allowed I don't see a problem.
> 
> 
> Another area where the same problem comes up is when using logotype,
it
> would be nice to be able to deliver the certificate and the logo in
one
> bag. Currently I am using MIME for this.
> 
> 
> I would tend to see this as an HTTP extension rather than a PKIX
> extension. We already have MIME archives of HTML documents with
> interelated parts. This would be fine for small CRLs but for large
CRLs
> you really do need binary encoding not base 64.
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stephen Farrell
> > Sent: Wednesday, September 13, 2006 5:46 PM
> > To: Stefan Santesson
> > Cc: [email-masked]
> > Subject: Re: Certs in CRLs - New standards task?
> >
> >
> >
> >
> > Stefan Santesson wrote:
> > > I would like to hear the opinion of this group on this.
> >
> > Sounds like an interesting idea - would like to see a draft
> > all right. (Though David Kemp's idea of wrapping the cert and
> > CRL a bag might also be worth investigating, depending on the
> > CRL consuming protocols one is considering.)
> >
> > However, I'd have to wonder whether extending the life of the
> > PKIX WG by another couple of years would be the right approach.
> > Would it be better to first consider re-chartering or else
> > chartering a new WG? (I'm not saying I think either is the
> > way to go, but PKIX has been on the go for a looong time.)
> >
> > S.
> >
> >
> >

Date: Thu, 14 Sep 2006 21:07:44 +0000
From: Lashonda Stiver <[email-masked]>
To: Joaquima Alderman <[email-masked]>
Subject: Best way neall !

This is a multi-part message in MIME format.
-----------00000043.01C6D841
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

One short form will give you the Lowest Rates in America!
You can save up to 10grands a year just by 5 mins.
Get the BEST quotes with any credit.
http://goodloanbiz.com/
them. They got to look in
wait. It'd be terrible scene. He gazed
McDonald's hamburger, it was

-----------00000043.01C6D841
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
</head>
<body>
<p><strong>One short form will give you the Lowest Rates in America!</strong><br>
<p>You can save up to 10grands a year just by 5 mins.</p>
<p>Get the BEST quotes with any credit.</p>
<p><a href="http://goodloanbiz.com/">http://goodloanbiz.com/</a></p>
<br>
them. They got to look in<br>
wait. It'd be terrible scene. He gazed<br>
McDonald's hamburger, it was<br>
</body>
</html>

-----------00000043.01C6D841--

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 14 Sep 2006 07:08:44 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I would prefer a bag as well, DIME would be ideal but I guess this group would want something ASN.1

Provided BER encoding is allowed I don't see a problem.

Another area where the same problem comes up is when using logotype, it would be nice to be able to deliver the certificate and the logo in one bag. Currently I am using MIME for this.

I would tend to see this as an HTTP extension rather than a PKIX extension. We already have MIME archives of HTML documents with interelated parts. This would be fine for small CRLs but for large CRLs you really do need binary encoding not base 64.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Wednesday, September 13, 2006 5:46 PM
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
> 
> 
> 
> Stefan Santesson wrote:
> > I would like to hear the opinion of this group on this.
> 
> Sounds like an interesting idea - would like to see a draft 
> all right. (Though David Kemp's idea of wrapping the cert and 
> CRL a bag might also be worth investigating, depending on the 
> CRL consuming protocols one is considering.)
> 
> However, I'd have to wonder whether extending the life of the 
> PKIX WG by another couple of years would be the right approach.
> Would it be better to first consider re-chartering or else 
> chartering a new WG? (I'm not saying I think either is the 
> way to go, but PKIX has been on the go for a looong time.)
> 
> S.
> 
> 
> 

Date: Thu, 14 Sep 2006 08:10:49 -0400
To: Stefan Santesson <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Certs in CRLs - New standards task?
Sender: [email-masked]

<html>
<body>
Obviously correct.&nbsp; Please excuse the brain bubble.<br><br>
Russ<br><br>
<br>
At 08:55 PM 9/13/2006, Stefan Santesson wrote:<br>
<blockquote type=cite class=cite cite=""><a name="_MailEndCompose"></a>
Not as AIA currently is formed:<br>
&nbsp;<br>
&nbsp;&nbsp; AccessDescription&nbsp; ::=&nbsp; SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
accessMethod&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT
IDENTIFIER,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
accessLocation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
GeneralName&nbsp; }<br>
&nbsp;<br>
This syntax does not allow encapsulation of any data, just a
name/poiner.<br>
&nbsp;<br>
<b>Stefan Santesson<br>
</b>Senior Program Manager<br>
<b>Windows Security, Standards<br>
From:</b> Russ Housley
[<a href="mailto:[email-masked]" eudora="autourl">
mailto:[email-masked]</a>] <br>
<b>Sent:</b> den 13 september 2006 13:56<br>
<b>To:</b> Stefan Santesson; [email-masked]<br>
<b>Subject:</b> Re: Certs in CRLs - New standards task?<br>
&nbsp;<br>
Stefan:<br><br>
Could this be done as a new accessMethod / accessLocation in the
AIA?<br><br>
Russ<br><br>
At 12:07 PM 9/13/2006, Stefan Santesson wrote:<br><br>
Taking the pkix chair hat off and the vendor hat on<br>
&nbsp;<br>
I’m asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed CA.
I.e. where the target certificate and it’s CRL are signed by different
keys and the RP does not have access to the CRL Issuer certificate.<br>
&nbsp;<br>
It is basically the same situation we solved with allowing the AIA
extension in CRL’s namely the problem to obtain the CRL issuer’s
certificate, alternatively, certificate path.<br>
&nbsp;<br>
In our efforts to implement the AIA solution we have encountered some
real issues.<br>
&nbsp;<br>
1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Each time we are forced to
go out and retrieve new information on the network, we have a source of
potential problems such as unavailable network resources, timeouts etc.
It all adds to the validation time and harms the user experience.<br>
2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The AIA in CRL’s provide
another opening for DoS attacks if rouge CRL’s point their AIA to a
targeted web server. This is tough not as serious as the DoS problems
with AIA in certificates, but this one we might avoid more easily.<br>
&nbsp;<br>
The proposed solution is to define a new CRL extension that may contain
the CRL Issuer certificate (not just a URL to its location). Preferably
this would be a PKCS#7 (or CMS) Certs only message that may contain a
single certificate or a bag of certificates (a chain).<br>
&nbsp;<br>
While it wouldn’t be attractive to define such extension for certificates
due to certificate size considerations, CRL’s are often of such size that
including the certs needed to validate it only leads to an insignificant
increase of size, while it may offer substantial processing
advantages.<br>
&nbsp;<br>
I would like to hear the opinion of this group on this.<br>
&nbsp;<br>
I volunteer to write a first draft if there is interest from the
group.<br>
&nbsp;<br>
&nbsp;<br>
<b>Stefan Santesson<br>
</b>Senior Program Manager<br>
<b>Windows Security, Standards<br>
</b>&nbsp;</blockquote></body>
</html>

Content-Class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 14 Sep 2006 01:55:39 +0100
From: Stefan Santesson <[email-masked]>
To: Russ Housley <[email-masked]>, <[email-masked]>
Sender: [email-masked]

------_=_NextPart_001_01C6D798.805BDEED
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Not as AIA currently is formed:

=20

   AccessDescription  ::=3D  SEQUENCE {

           accessMethod          OBJECT IDENTIFIER,

           accessLocation        GeneralName  }

=20

This syntax does not allow encapsulation of any data, just a
name/poiner.

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

From: Russ Housley [mailto:[email-masked]]=20
Sent: den 13 september 2006 13:56
To: Stefan Santesson; [email-masked]
Subject: Re: Certs in CRLs - New standards task?

=20

Stefan:

Could this be done as a new accessMethod / accessLocation in the AIA?

Russ

At 12:07 PM 9/13/2006, Stefan Santesson wrote:

Taking the pkix chair hat off and the vendor hat on
=20
I'm asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed
CA. I.e. where the target certificate and it's CRL are signed by
different keys and the RP does not have access to the CRL Issuer
certificate.
=20
It is basically the same situation we solved with allowing the AIA
extension in CRL's namely the problem to obtain the CRL issuer's
certificate, alternatively, certificate path.
=20
In our efforts to implement the AIA solution we have encountered some
real issues.
=20
1)        Each time we are forced to go out and retrieve new information
on the network, we have a source of potential problems such as
unavailable network resources, timeouts etc. It all adds to the
validation time and harms the user experience.
2)        The AIA in CRL's provide another opening for DoS attacks if
rouge CRL's point their AIA to a targeted web server. This is tough not
as serious as the DoS problems with AIA in certificates, but this one we
might avoid more easily.
=20
The proposed solution is to define a new CRL extension that may contain
the CRL Issuer certificate (not just a URL to its location). Preferably
this would be a PKCS#7 (or CMS) Certs only message that may contain a
single certificate or a bag of certificates (a chain).
=20
While it wouldn't be attractive to define such extension for
certificates due to certificate size considerations, CRL's are often of
such size that including the certs needed to validate it only leads to
an insignificant increase of size, while it may offer substantial
processing advantages.
=20
I would like to hear the opinion of this group on this.
=20
I volunteer to write a first draft if there is interest from the group.
=20
=20
Stefan Santesson
Senior Program Manager
Windows Security, Standards
=20

------_=_NextPart_001_01C6D798.805BDEED
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

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

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

<div class=3DSection1>

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

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

<p class=3DMsoPlainText><span lang=3DEN-US style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp;
AccessDescription&nbsp; ::=3D&nbsp; SEQUENCE {<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
accessMethod&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OBJECT IDENTIFIER,<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US style=3D'font-family:"Courier =
New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
accessLocation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
GeneralName&nbsp; }<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>This syntax does not allow encapsulation of any data, =
just a
name/poiner.<o:p></o:p></span></p>

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

<div>

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

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

</div>

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

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

<div>

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

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Russ Housley =
[mailto:[email-masked]] <br>
<b>Sent:</b> den 13 september 2006 13:56<br>
<b>To:</b> Stefan Santesson; [email-masked]<br>
<b>Subject:</b> Re: Certs in CRLs - New standards =
task?<o:p></o:p></span></p>

</div>

</div>

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

<p class=3DMsoNormal>Stefan:<br>
<br>
Could this be done as a new accessMethod / accessLocation in the =
AIA?<br>
<br>
Russ<br>
<br>
At 12:07 PM 9/13/2006, Stefan Santesson wrote:<br>
<br>
<o:p></o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt'>Taking the pkix =
chair hat off
and the vendor hat on<br>
&nbsp;<br>
I&#8217;m asking this group to consider a new standards task to solve a =
real
implementation issue with indirect CRLs and CRLs issued by a re-keyed =
CA. I.e.
where the target certificate and it&#8217;s CRL are signed by different =
keys and the
RP does not have access to the CRL Issuer certificate.<br>
&nbsp;<br>
It is basically the same situation we solved with allowing the AIA =
extension in
CRL&#8217;s namely the problem to obtain the CRL issuer&#8217;s =
certificate, alternatively,
certificate path.<br>
&nbsp;<br>
In our efforts to implement the AIA solution we have encountered some =
real
issues.<br>
&nbsp;<br>
1)</span><span style=3D'font-size:7.5pt'> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span
style=3D'font-size:10.0pt'>Each time we are forced to go out and =
retrieve new
information on the network, we have a source of potential problems such =
as
unavailable network resources, timeouts etc. It all adds to the =
validation time
and harms the user experience.<br>
2)</span><span style=3D'font-size:7.5pt'> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span
style=3D'font-size:10.0pt'>The AIA in CRL&#8217;s provide another =
opening for DoS
attacks if rouge CRL&#8217;s point their AIA to a targeted web server. =
This is tough
not as serious as the DoS problems with AIA in certificates, but this =
one we
might avoid more easily.<br>
&nbsp;<br>
The proposed solution is to define a new CRL extension that may contain =
the CRL
Issuer certificate (not just a URL to its location). Preferably this =
would be a
PKCS#7 (or CMS) Certs only message that may contain a single certificate =
or a
bag of certificates (a chain).<br>
&nbsp;<br>
While it wouldn&#8217;t be attractive to define such extension for =
certificates due
to certificate size considerations, CRL&#8217;s are often of such size =
that including
the certs needed to validate it only leads to an insignificant increase =
of
size, while it may offer substantial processing advantages.<br>
&nbsp;<br>
I would like to hear the opinion of this group on this.<br>
&nbsp;<br>
I volunteer to write a first draft if there is interest from the =
group.<br>
&nbsp;<br>
&nbsp;<br>
<b><span style=3D'color:maroon'>Stefan Santesson<br>
</span></b><span style=3D'color:#400040'>Senior Program Manager<br>
<b>Windows Security, Standards<br>
</b></span></span>&nbsp;<o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C6D798.805BDEED--

Content-Class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Thu, 14 Sep 2006 01:30:15 +0100
From: Stefan Santesson <[email-masked]>
To: Paul Hoffman <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Paul,

That was my intention. I just wanted to see the reaction from people on
this list before writing the draft.
To assign it to a WG is a secondary problem.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 13 september 2006 16:36
> To: [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
> 
> At 10:45 PM +0100 9/13/06, Stephen Farrell wrote:
> >However, I'd have to wonder whether extending the life of the
> >PKIX WG by another couple of years would be the right approach.
> >Would it be better to first consider re-chartering or else
> >chartering a new WG?
> 
> Or just submitting it as an individual submission without a WG behind
> it? Even after this WG closes down, this mailing list will continue
> on. FWIW, there are about 850 people on the mailing list, and most if
> not all will probably stay on after the WG closes.
> 
> --Paul Hoffman, Director
> --VPN Consortium

Date: Wed, 13 Sep 2006 16:35:54 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: Certs in CRLs - New standards task?
Sender: [email-masked]

At 10:45 PM +0100 9/13/06, Stephen Farrell wrote:
>However, I'd have to wonder whether extending the life of the
>PKIX WG by another couple of years would be the right approach.
>Would it be better to first consider re-chartering or else
>chartering a new WG?

Or just submitting it as an individual submission without a WG behind 
it? Even after this WG closes down, this mailing list will continue 
on. FWIW, there are about 850 people on the mailing list, and most if 
not all will probably stay on after the WG closes.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 13 Sep 2006 22:45:52 +0100
From: Stephen Farrell <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: [email-masked]
Subject: Re: Certs in CRLs - New standards task?
Sender: [email-masked]

Stefan Santesson wrote:
> I would like to hear the opinion of this group on this.

Sounds like an interesting idea - would like to see a draft
all right. (Though David Kemp's idea of wrapping the cert and
CRL a bag might also be worth investigating, depending on the
CRL consuming protocols one is considering.)

However, I'd have to wonder whether extending the life of the
PKIX WG by another couple of years would be the right approach.
Would it be better to first consider re-chartering or else
chartering a new WG? (I'm not saying I think either is the
way to go, but PKIX has been on the go for a looong time.)

S.

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Wed, 13 Sep 2006 17:21:51 -0400
From: "Kemp David P." <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6D77A.A17EDF90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

I'm skeptical that including a certificate path within the security
envelope of a CRL is the best approach.  In many cases (particularly in
ARLs which should normally be empty) this would add considerable
overhead.  And even in CRLs which are 10x the size of the CRL issuer's
cert path, that extra 10% bandwidth penalty is repeated every time a CRL
is fetched, not just every time a new CRL issuer cert is needed.  Since
CRLs are updated much more frequently than certs, binding them together
forces unnecessary bandwidth inefficiencies.

=20

Issue #2 is not real:  because you cannot make this feature mandatory
(i.e. prohibit the use of AIA in CRLs), you cannot write applications
that refuse to execute AIA and thus refuse to participate in DoS
attacks.  Instead, to avoid this issue applications should not fetch a
CRL from certificates that do not trace back to a trust anchor.  If a
trusted certificate has a rogue AIA, there are bigger problems than DoS.

=20

To address Issue #1, it would be preferable to define a bag that
contains both a CRL and the CRL issuer cert path.  That way CRL issuers
would not be forced to generate both cert-extension CRLs and normal
CRLs.  The bag could instead be generated on demand by the CRL
repository or by local proxies.

=20

Dave Kemp

=20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Wednesday, September 13, 2006 12:08 PM
To: [email-masked]
Subject: Certs in CRLs - New standards task?

=20

Taking the pkix chair hat off and the vendor hat on

=20

I'm asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed
CA. I.e. where the target certificate and it's CRL are signed by
different keys and the RP does not have access to the CRL Issuer
certificate.

=20

It is basically the same situation we solved with allowing the AIA
extension in CRL's namely the problem to obtain the CRL issuer's
certificate, alternatively, certificate path.

=20

In our efforts to implement the AIA solution we have encountered some
real issues.

=20

1)       Each time we are forced to go out and retrieve new information
on the network, we have a source of potential problems such as
unavailable network resources, timeouts etc. It all adds to the
validation time and harms the user experience.

2)       The AIA in CRL's provide another opening for DoS attacks if
rouge CRL's point their AIA to a targeted web server. This is tough not
as serious as the DoS problems with AIA in certificates, but this one we
might avoid more easily.

=20

The proposed solution is to define a new CRL extension that may contain
the CRL Issuer certificate (not just a URL to its location). Preferably
this would be a PKCS#7 (or CMS) Certs only message that may contain a
single certificate or a bag of certificates (a chain).

=20

While it wouldn't be attractive to define such extension for
certificates due to certificate size considerations, CRL's are often of
such size that including the certs needed to validate it only leads to
an insignificant increase of size, while it may offer substantial
processing advantages.

=20

I would like to hear the opinion of this group on this.

=20

I volunteer to write a first draft if there is interest from the group.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

------_=_NextPart_001_01C6D77A.A17EDF90
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1468089912;
	mso-list-type:hybrid;
	mso-list-template-ids:-795188044 69009425 69009433 69009435 69009423 =
69009433 69009435 69009423 69009433 69009435;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I&#8217;m skeptical that including =
a
certificate path within the security envelope of a CRL is the best =
approach. &nbsp;In
many cases (particularly in ARLs which should normally be empty) this =
would add
considerable overhead. &nbsp;And even in CRLs which are 10x the size of =
the CRL
issuer&#8217;s cert path, that extra 10% bandwidth penalty is repeated =
every
time a CRL is fetched, not just every time a new CRL issuer cert is =
needed.&nbsp;
Since CRLs are updated much more frequently than certs, binding them =
together
forces unnecessary bandwidth =
inefficiencies.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Issue #2 is not real:&nbsp; because =
you
cannot make this feature mandatory (i.e. prohibit the use of AIA in =
CRLs), you
cannot write applications that refuse to execute AIA and thus refuse to
participate in DoS attacks. &nbsp;Instead, to avoid this issue =
applications
should not fetch a CRL from certificates that do not trace back to a =
trust
anchor. &nbsp;If a trusted certificate has a rogue AIA, there are bigger
problems than DoS.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>To address Issue #1, it would be
preferable to define a bag that contains both a CRL and the CRL issuer =
cert
path.&nbsp; That way CRL issuers would not be forced to generate both =
cert-extension
CRLs and normal CRLs.&nbsp; The bag could instead be generated on demand =
by the
CRL repository or by local proxies.<o:p></o:p></span></font></p>

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

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

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, =
September 13,
2006 12:08 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Certs in CRLs - =
New
standards task?</span></font><o:p></o:p></p>

</div>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Taking the pkix chair hat off and the vendor =
hat on<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I&#8217;m asking this group to consider a new
standards task to solve a real implementation issue with indirect CRLs =
and CRLs
issued by a re-keyed CA. I.e. where the target certificate and =
it&#8217;s CRL
are signed by different keys and the RP does not have access to the CRL =
Issuer
certificate.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>It is basically the same situation we solved =
with
allowing the AIA extension in CRL&#8217;s namely the problem to obtain =
the CRL
issuer&#8217;s certificate, alternatively, certificate =
path.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>In our efforts to implement the AIA solution =
we have
encountered some real issues.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>1)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>Each
time we are forced to go out and retrieve new information on the =
network, we
have a source of potential problems such as unavailable network =
resources,
timeouts etc. It all adds to the validation time and harms the user =
experience.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>2)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>The
AIA in CRL&#8217;s provide another opening for DoS attacks if rouge =
CRL&#8217;s
point their AIA to a targeted web server. This is tough not as serious =
as the
DoS problems with AIA in certificates, but this one we might avoid more =
easily.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The proposed solution is to define a new CRL
extension that may contain the CRL Issuer certificate (not just a URL to =
its
location). Preferably this would be a PKCS#7 (or CMS) Certs only message =
that
may contain a single certificate or a bag of certificates (a =
chain).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>While it wouldn&#8217;t be attractive to =
define such
extension for certificates due to certificate size considerations, =
CRL&#8217;s
are often of such size that including the certs needed to validate it =
only
leads to an insignificant increase of size, while it may offer =
substantial
processing advantages.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I would like to hear the opinion of this group =
on
this.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I volunteer to write a first draft if there is
interest from the group.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan
Santesson</span></font></b></strong><span =
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span lang=3DEN-GB =
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows
Security, Standards</span></font></b></strong><span =
lang=3DEN-GB><o:p></o:p></span></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C6D77A.A17EDF90--

Date: Wed, 13 Sep 2006 16:56:25 -0400
To: Stefan Santesson <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Certs in CRLs - New standards task?
Sender: [email-masked]

<html>
<body>
Stefan:<br><br>
Could this be done as a new accessMethod / accessLocation in the
AIA?<br><br>
Russ<br><br>
At 12:07 PM 9/13/2006, Stefan Santesson wrote:<br>
<blockquote type=cite class=cite cite=""><font size=2>Taking the pkix
chair hat off and the vendor hat on<br>
&nbsp;<br>
I’m asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed CA.
I.e. where the target certificate and it’s CRL are signed by different
keys and the RP does not have access to the CRL Issuer certificate.<br>
&nbsp;<br>
It is basically the same situation we solved with allowing the AIA
extension in CRL’s namely the problem to obtain the CRL issuer’s
certificate, alternatively, certificate path.<br>
&nbsp;<br>
In our efforts to implement the AIA solution we have encountered some
real issues.<br>
&nbsp;<br>
1)</font><font face="Times New Roman, Times" size=1>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font size=2>Each time we are
forced to go out and retrieve new information on the network, we have a
source of potential problems such as unavailable network resources,
timeouts etc. It all adds to the validation time and harms the user
experience.<br>
2)</font><font face="Times New Roman, Times" size=1>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font size=2>The AIA in CRL’s
provide another opening for DoS attacks if rouge CRL’s point their AIA to
a targeted web server. This is tough not as serious as the DoS problems
with AIA in certificates, but this one we might avoid more easily.<br>
&nbsp;<br>
The proposed solution is to define a new CRL extension that may contain
the CRL Issuer certificate (not just a URL to its location). Preferably
this would be a PKCS#7 (or CMS) Certs only message that may contain a
single certificate or a bag of certificates (a chain).<br>
&nbsp;<br>
While it wouldn’t be attractive to define such extension for certificates
due to certificate size considerations, CRL’s are often of such size that
including the certs needed to validate it only leads to an insignificant
increase of size, while it may offer substantial processing
advantages.<br>
&nbsp;<br>
I would like to hear the opinion of this group on this.<br>
&nbsp;<br>
I volunteer to write a first draft if there is interest from the
group.<br>
&nbsp;<br>
&nbsp;<br>
</font><font size=2 color="#800000"><b>Stefan Santesson<br>
</b></font><font size=2 color="#400040">Senior Program Manager<br>
<b>Windows Security, Standards<br>
</b></font><font face="Times New Roman, Times">&nbsp;</font></blockquote>
</body>
</html>

Date: Wed, 13 Sep 2006 22:07:47 +0200
From: Tilo Kienitz <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: [email-masked]
Subject: Re: Certs in CRLs - New standards task?
Sender: [email-masked]

Stefan Santesson wrote:
 > [...]
> The proposed solution is to define a new CRL extension that may contain 
> the CRL Issuer certificate (not just a URL to its location). Preferably 
> this would be a PKCS#7 (or CMS) Certs only message that may contain a 
> single certificate or a bag of certificates (a chain).

I like this idea. It would make CRL validation as easy as OCSP response
validation where the issuer's certificate is also included.

Kind regards
Tilo Kienitz

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

Content-class: urn:content-classes:message
Subject: RE: Certs in CRLs - New standards task?
Date: Wed, 13 Sep 2006 15:23:40 -0400
From: "Dave Engberg" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_06AE_01C6D748.979B91D0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_06AF_01C6D748.979B91D0"

------=_NextPart_001_06AF_01C6D748.979B91D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

This sounds like a great idea.  Real-world availability and reliability of
directories and servers is a gigantic issue for complex (e.g.
cross-certified) PKI environments.  This solution removes one extra lookup
from the mix with a negligible size overhead on the CRL.

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Wednesday, September 13, 2006 12:08 PM
To: [email-masked]
Subject: Certs in CRLs - New standards task?

Taking the pkix chair hat off and the vendor hat on

I'm asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed CA.
I.e. where the target certificate and it's CRL are signed by different keys
and the RP does not have access to the CRL Issuer certificate.

It is basically the same situation we solved with allowing the AIA extension
in CRL's namely the problem to obtain the CRL issuer's certificate,
alternatively, certificate path.

In our efforts to implement the AIA solution we have encountered some real
issues.

1)       Each time we are forced to go out and retrieve new information on
the network, we have a source of potential problems such as unavailable
network resources, timeouts etc. It all adds to the validation time and
harms the user experience.

2)       The AIA in CRL's provide another opening for DoS attacks if rouge
CRL's point their AIA to a targeted web server. This is tough not as serious
as the DoS problems with AIA in certificates, but this one we might avoid
more easily.

The proposed solution is to define a new CRL extension that may contain the
CRL Issuer certificate (not just a URL to its location). Preferably this
would be a PKCS#7 (or CMS) Certs only message that may contain a single
certificate or a bag of certificates (a chain).

While it wouldn't be attractive to define such extension for certificates
due to certificate size considerations, CRL's are often of such size that
including the certs needed to validate it only leads to an insignificant
increase of size, while it may offer substantial processing advantages.

I would like to hear the opinion of this group on this.

I volunteer to write a first draft if there is interest from the group.

Stefan Santesson

Senior Program Manager

Windows Security, Standards

------=_NextPart_001_06AF_01C6D748.979B91D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE>@page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt =
70.85pt 70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0cm
}
UL {
	MARGIN-BOTTOM: 0cm
}
</STYLE>
</HEAD>
<BODY lang=3DSV vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D375192019-13092006>This sounds like a great idea.&nbsp; =
Real-world=20
availability and reliability of directories and servers is a gigantic =
issue for=20
complex (e.g. cross-certified) PKI environments.&nbsp; This=20
solution&nbsp;removes one extra lookup from the mix with a negligible =
size=20
overhead on the CRL.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Stefan=20
Santesson<BR><B>Sent:</B> Wednesday, September 13, 2006 12:08 =
PM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> Certs in CRLs - New standards=20
task?<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Taking the pkix chair hat =
off and=20
the vendor hat on<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I&#8217;m asking this =
group to consider a=20
new standards task to solve a real implementation issue with indirect =
CRLs and=20
CRLs issued by a re-keyed CA. I.e. where the target certificate and =
it&#8217;s CRL are=20
signed by different keys and the RP does not have access to the CRL =
Issuer=20
certificate.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">It is basically the same =
situation=20
we solved with allowing the AIA extension in CRL&#8217;s namely the =
problem to obtain=20
the CRL issuer&#8217;s certificate, alternatively, certificate=20
path.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">In our efforts to =
implement the AIA=20
solution we have encountered some real =
issues.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt; mso-list: l0 level1 =
lfo1"><![if !supportLists]><FONT=20
face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN=20
style=3D"mso-list: Ignore">1)<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
size=3D2><SPAN=20
lang=3DEN-GB style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Each time we =
are forced=20
to go out and retrieve new information on the network, we have a source =
of=20
potential problems such as unavailable network resources, timeouts etc. =
It all=20
adds to the validation time and harms the user=20
experience.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 36pt; TEXT-INDENT: -18pt; mso-list: l0 level1 =
lfo1"><![if !supportLists]><FONT=20
face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><SPAN=20
style=3D"mso-list: Ignore">2)<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
size=3D2><SPAN=20
lang=3DEN-GB style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The AIA in =
CRL&#8217;s provide=20
another opening for DoS attacks if rouge CRL&#8217;s point their AIA to =
a targeted web=20
server. This is tough not as serious as the DoS problems with AIA in=20
certificates, but this one we might avoid more=20
easily.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The proposed solution is =
to define a=20
new CRL extension that may contain the CRL Issuer certificate (not just =
a URL to=20
its location). Preferably this would be a PKCS#7 (or CMS) Certs only =
message=20
that may contain a single certificate or a bag of certificates (a=20
chain).<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">While it wouldn&#8217;t be =
attractive to=20
define such extension for certificates due to certificate size =
considerations,=20
CRL&#8217;s are often of such size that including the certs needed to =
validate it only=20
leads to an insignificant increase of size, while it may offer =
substantial=20
processing advantages.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I would like to hear the =
opinion of=20
this group on this.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I volunteer to write a =
first draft=20
if there is interest from the group.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><STRONG><B><FONT face=3DArial color=3Dmaroon =
size=3D2><SPAN=20
lang=3DEN-GB style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
Arial">Stefan=20
Santesson</SPAN></FONT></B></STRONG><SPAN =
lang=3DEN-GB><o:p></o:p></SPAN></P>
<P class=3DMsoNormal><FONT face=3DArial color=3D#400040 size=3D2><SPAN =
lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: Arial">Senior =
Program=20
Manager</SPAN></FONT><FONT color=3Dnavy><SPAN lang=3DEN-GB=20
style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><STRONG><B><FONT face=3DArial color=3D#400040 =
size=3D2><SPAN=20
lang=3DEN-GB style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
Arial">Windows=20
Security, Standards</SPAN></FONT></B></STRONG><SPAN=20
lang=3DEN-GB><o:p></o:p></SPAN></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =
lang=3DEN-GB=20
style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BODY></HTML>

------=_NextPart_001_06AF_01C6D748.979B91D0--

------=_NextPart_000_06AE_01C6D748.979B91D0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_06AE_01C6D748.979B91D0--

Content-Class: urn:content-classes:message
Subject: Certs in CRLs - New standards task?
Date: Wed, 13 Sep 2006 17:07:41 +0100
From: Stefan Santesson <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

------_=_NextPart_001_01C6D74E.BECD57B5
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Taking the pkix chair hat off and the vendor hat on

=20

I'm asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed
CA. I.e. where the target certificate and it's CRL are signed by
different keys and the RP does not have access to the CRL Issuer
certificate.

=20

It is basically the same situation we solved with allowing the AIA
extension in CRL's namely the problem to obtain the CRL issuer's
certificate, alternatively, certificate path.

=20

In our efforts to implement the AIA solution we have encountered some
real issues.

=20

1)       Each time we are forced to go out and retrieve new information
on the network, we have a source of potential problems such as
unavailable network resources, timeouts etc. It all adds to the
validation time and harms the user experience.

2)       The AIA in CRL's provide another opening for DoS attacks if
rouge CRL's point their AIA to a targeted web server. This is tough not
as serious as the DoS problems with AIA in certificates, but this one we
might avoid more easily.

=20

The proposed solution is to define a new CRL extension that may contain
the CRL Issuer certificate (not just a URL to its location). Preferably
this would be a PKCS#7 (or CMS) Certs only message that may contain a
single certificate or a bag of certificates (a chain).

=20

While it wouldn't be attractive to define such extension for
certificates due to certificate size considerations, CRL's are often of
such size that including the certs needed to validate it only leads to
an insignificant increase of size, while it may offer substantial
processing advantages.

=20

I would like to hear the opinion of this group on this.

=20

I volunteer to write a first draft if there is interest from the group.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

------_=_NextPart_001_01C6D74E.BECD57B5
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:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1468089912;
	mso-list-type:hybrid;
	mso-list-template-ids:-795188044 69009425 69009433 69009435 69009423 =
69009433 69009435 69009423 69009433 69009435;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Taking the pkix chair hat off and the vendor =
hat on<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I&#8217;m asking this group to consider a new
standards task to solve a real implementation issue with indirect CRLs =
and CRLs
issued by a re-keyed CA. I.e. where the target certificate and =
it&#8217;s CRL
are signed by different keys and the RP does not have access to the CRL =
Issuer
certificate.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>It is basically the same situation we solved =
with
allowing the AIA extension in CRL&#8217;s namely the problem to obtain =
the CRL
issuer&#8217;s certificate, alternatively, certificate =
path.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>In our efforts to implement the AIA solution =
we have
encountered some real issues.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>1)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>Each
time we are forced to go out and retrieve new information on the =
network, we
have a source of potential problems such as unavailable network =
resources,
timeouts etc. It all adds to the validation time and harms the user =
experience.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>2)<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>The
AIA in CRL&#8217;s provide another opening for DoS attacks if rouge =
CRL&#8217;s
point their AIA to a targeted web server. This is tough not as serious =
as the
DoS problems with AIA in certificates, but this one we might avoid more =
easily.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The proposed solution is to define a new CRL
extension that may contain the CRL Issuer certificate (not just a URL to =
its
location). Preferably this would be a PKCS#7 (or CMS) Certs only message =
that
may contain a single certificate or a bag of certificates (a =
chain).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>While it wouldn&#8217;t be attractive to =
define such
extension for certificates due to certificate size considerations, =
CRL&#8217;s
are often of such size that including the certs needed to validate it =
only
leads to an insignificant increase of size, while it may offer =
substantial
processing advantages.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I would like to hear the opinion of this group =
on
this.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I volunteer to write a first draft if there is
interest from the group.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan
Santesson</span></font></b></strong><span =
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span lang=3DEN-GB =
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows
Security, Standards</span></font></b></strong><span =
lang=3DEN-GB><o:p></o:p></span></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C6D74E.BECD57B5--

From: "Anders Rundgren" <[email-masked]>
To: "Santoni Adriano" <[email-masked]>, <[email-masked]>
Subject: Re: Browser trust models & Smart cards
Date: Tue, 12 Sep 2006 18:11:53 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Adriano,

I believe that the best answer to your highly valid question is that =
IETF standards like TLS-client-authentication and S/MIME leave quite a =
bit to implementers to decide.  To not get completely wrong, =
implementers typically test their software with a few [what they =
perceive as] "normative" PKIs.  Since we (the PKI community), have not =
decided if a specific issuance should use one, two, or three =
certificates including associated KeyUsage specifiers, KeyUsage has =
become a source of rather tricky interoperability issues.   "The cult of =
the NR bit" has in turn brought considerable confusion to the table as =
well.  Since nobody is likely to ever convince the world including =
vendors that these things should be in a certain way, a "wannabe" =
standard for web-form-signing coined WASP (Web Activated Signature =
Protocol), makes certificate selection a thing for the relying party to =
have an opinion about, rather than the client software.  This is natural =
in on-line schemes.  What the default KeyUsage should be I guess will =
still be an implementers choice :-(   But this has little importance =
since the relying party has a pretty decent range of optional =
certificate selection parameters at his/her disposal if the default(s) =
does not work:

<xs:element name=3D"CertificateFilter" minOccurs=3D"0">
<xs:complexType>
At least one of the following attributes MUST be specified.

"Global" (cert-path-wide) signer certificate selection attributes.
<xs:attribute name=3D"Sha1" type=3D"wasp:sha1Hash" use=3D"optional"/>
<xs:attribute name=3D"Issuer" type=3D"wasp:distinguishedNameExpr" =
use=3D"optional"/>
"Local" selection attributes that only apply to signature (EE) =
certificates.
<xs:attribute name=3D"Subject" type=3D"wasp:distinguishedNameExpr" =
use=3D"optional"/>
<xs:attribute name=3D"Serial" type=3D"xs:integer" use=3D"optional"/>
<xs:attribute name=3D"Policy" type=3D"wasp:oidURI" use=3D"optional"/>
<xs:attribute name=3D"Containers" type=3D"wasp:containerList" =
use=3D"optional"/>
<xs:attribute name=3D"KeyUsage" type=3D"wasp:keyUsageBits" =
use=3D"optional"/>
<xs:attribute name=3D"ExtKeyUsage" type=3D"wasp:oidURI" =
use=3D"optional"/>

</xs:complexType>
</xs:element>

It appears that the combination of KeyUsage and Policy should be a nice =
fit for many PKIs rather than using TLS-like issuer filtering since the =
latter requires knowledge of participating "scheme" sub-CAs that the =
relying party may not have (jn advance).

If a relying party accepts multiple independent issuers and trust =
networks, a set of certificate filter objects can [presumably] still =
cope with the lack of standardization in this space.

Regarding the trust model however, it is clear that there should be no =
requirements for anything but EE certificates, although the relying =
party may request that signature packets should contain as much of the =
certificate path that is locally known.

regards
Anders

----- Original Message -----=20
From: Santoni Adriano=20
To: [email-masked]=20
Sent: Monday, September 11, 2006 09:45
Subject: R: Browser trust models & Smart cards

I fully agree with Anders.

Btw, Mozilla and its descendants do a number of weird things with =
certificates, not only the one described below.

For instance, it rejects digital signature certificates as they were =
unknown beasts. I mean, certificates with a critical KeyUsage extension =
with the "nonRepudiation" bit raised. If you want to use the signText() =
function with a qualified certificate, in Mozilla/Firefox, you're out of =
luck. Why so? Nobody seems to know or care.

Adriano

-------------------------------------------------------------------------=
-------
Da: [email-masked] [mailto:[email-masked]] =
Per conto di Anders Rundgren
Inviato: domenica 3 settembre 2006 15.52
A: [email-masked]
Oggetto: Browser trust models & Smart cards

Dear list;

Regarding the trust model for client-based PKI operations, I am a bit =
puzzled concerning how this should work in browsers.

Mozilla Firefox requires that an EE certificate CA is known and marked =
as "trusted" in order to perform private key operations.  IMHO, this =
requirement is unnecessary, particularly for TLS-client-authentication =
and on-line signatures (signText), because in these use-cases there are =
no trust issues on the client-side except for TLS server-certificates.  =
This requirement also limits mobility for smart card users.  There are =
to my knowledge few if any smart card standards requiring complete =
certificate-paths to be stored in the card.

As a comparison you could take credit-cards; it is important that =
end-users recognize the brand (and possibly some user-related data as =
well), but there is no need to carry around any card issuer documents, =
because card verification is only performed by relying parties =
(merchants, banks etc.).

I would be interested to know how this is handled by other PKI-enabled =
clients.  AFAIK, such [small but vital] details are not only outside of =
standards like TLS, but you can hardly get your hands on any vendor =
documentation either, because the running code seems currently to be the =
actual specification :-(

Comments?

Anders Rundgren

*******************Internet Email Confidentiality =
Footer*******************=20

Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei =
suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto per =
errore il presente messaggio, Le saremmo grati se ci inviasse, via =
e-mail, una comunicazione al riguardo e provvedesse nel contempo alla =
distruzione del messaggio stesso e dei suoi eventuali allegati. Le =
dichiarazioni contenute nel presente messaggio nonche' nei suoi =
eventuali allegati devono essere attribuite esclusivamente al mittente e =
non possono essere considerate come trasmesse o autorizzate da ACTALIS =
S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei =
confronti del destinatario o di terzi. ACTALIS S.p.A. non si assume =
alcuna responsabilita' per eventuali intercettazioni, modifiche o =
danneggiamenti del presente messaggio e-mail.=20

Any unauthorized use of this e-mail or any of its attachments is =
prohibited and could constitute an offence. If you are not the intended =
addressee please advise immediately the sender by using the reply =
facility in your e-mail software and destroy the message and its =
attachments. The statements and opinions expressed in this e-mail =
message are those of the author of the message and do not necessarily =
represent those of ACTALIS S.p.A. Besides, The contents of this message =
shall be understood as neither given nor endorsed by ACTALIS S.p.A.. =
ACTALIS S.p.A. does not accept liability for corruption, interception or =
amendment, if any, or the consequences thereof.=20

------=_NextPart_000_007D_01C6D696.ECBC9C20
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Adriano,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I believe that the best answer to your =
highly valid=20
question is that IETF standards like TLS-client-authentication and =
S/MIME leave=20
quite a bit to implementers to decide.&nbsp; To not get completely =
wrong,=20
implementers typically test their software with a&nbsp;few [what =
<EM>they</EM>=20
perceive as] "normative" PKIs.&nbsp; Since we (the PKI community), have =
not=20
decided if a specific issuance should use one, two, or three =
certificates=20
including associated KeyUsage specifiers, KeyUsage has become a source =
of=20
rather&nbsp;tricky interoperability issues.&nbsp;&nbsp; "The cult of the =
NR bit"=20
has in turn brought considerable confusion to the table as well.&nbsp; =
Since=20
nobody is likely to ever convince the world including vendors that these =
things=20
should be in a certain way,&nbsp;a "wannabe" standard =
for&nbsp;web-form-signing=20
coined WASP (Web Activated Signature Protocol), makes certificate =
selection a=20
thing for the relying party to have an opinion about, rather than the =
client=20
software.&nbsp; This&nbsp;is&nbsp;natural in on-line schemes.&nbsp; What =
the=20
default KeyUsage should be I guess will still be an implementers choice=20
:-(&nbsp;&nbsp; But this has little importance since the relying party =
has a=20
pretty decent range of optional certificate selection parameters at =
his/her=20
disposal if the default(s) does not work:</FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 15px"><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV>
<DIV style=3D"MARGIN-LEFT: 15px"><FONT face=3DArial size=3D2>&lt;<FONT=20
color=3D#008000>xs</FONT>:<FONT color=3D#c00000>element</FONT> <FONT=20
color=3D#0000c0>name</FONT>=3D"CertificateFilter" <FONT=20
color=3D#0000c0>minOccurs</FONT>=3D"0"&gt;</FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 30px"><FONT face=3DArial size=3D2>&lt;<FONT=20
color=3D#008000>xs</FONT>:<FONT =
color=3D#c00000>complexType</FONT>&gt;</FONT></DIV>
<DIV>
<DIV=20
style=3D"BORDER-RIGHT: #a0a0a0 1px solid; PADDING-RIGHT: 5px; =
BORDER-TOP: #a0a0a0 1px solid; MARGIN-TOP: 15px; PADDING-LEFT: 5px; =
FONT-WEIGHT: normal; BACKGROUND: #f0f0f0; MARGIN-BOTTOM: 5px; =
PADDING-BOTTOM: 5px; MARGIN-LEFT: 45px; BORDER-LEFT: #a0a0a0 1px solid; =
WIDTH: 495px; PADDING-TOP: 5px; BORDER-BOTTOM: #a0a0a0 1px solid"><FONT=20
face=3DArial color=3D#404040 size=3D2>At least one of the following =
attributes MUST be=20
specified.</FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>
<DIV=20
style=3D"BORDER-RIGHT: #a0a0a0 1px solid; PADDING-RIGHT: 5px; =
BORDER-TOP: #a0a0a0 1px solid; MARGIN-TOP: 5px; PADDING-LEFT: 5px; =
FONT-WEIGHT: normal; BACKGROUND: #f0f0f0; MARGIN-BOTTOM: 5px; =
PADDING-BOTTOM: 5px; MARGIN-LEFT: 45px; BORDER-LEFT: #a0a0a0 1px solid; =
WIDTH: 495px; PADDING-TOP: 5px; BORDER-BOTTOM: #a0a0a0 1px solid"><FONT=20
face=3DArial color=3D#404040 size=3D2>"Global" (cert-path-wide) signer =
certificate=20
selection attributes.</FONT></DIV></DIV>
<DIV style=3D"MARGIN-LEFT: 45px"><FONT face=3DArial size=3D2>&lt;<FONT=20
color=3D#008000>xs</FONT>:<FONT color=3D#c00000>attribute</FONT> <FONT=20
color=3D#0000c0>name</FONT>=3D"Sha1" <FONT =
color=3D#0000c0>type</FONT>=3D"<FONT=20
color=3D#008000>wasp</FONT>:sha1Hash" <FONT=20
color=3D#0000c0>use</FONT>=3D"optional"/&gt;</FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 45px"><FONT face=3DArial size=3D2>&lt;<FONT=20
color=3D#008000>xs</FONT>:<FONT color=3D#c00000>attribute</FONT> <FONT=20
color=3D#0000c0>name</FONT>=3D"Issuer" <FONT =
color=3D#0000c0>type</FONT>=3D"<FONT=20
color=3D#008000>wasp</FONT>:distinguishedNameExpr" <FONT=20
color=3D#0000c0>use</FONT>=3D"optional"/&gt;</FONT></DIV>
<DIV>
<DIV=20
style=3D"BORDER-RIGHT: #a0a0a0 1px solid; PADDING-RIGHT: 5px; =
BORDER-TOP: #a0a0a0 1px solid; MARGIN-TOP: 15px; PADDING-LEFT: 5px; =
FONT-WEIGHT: normal; BACKGROUND: #f0f0f0; MARGIN-BOTTOM: 5px; =
PADDING-BOTTOM: 5px; MARGIN-LEFT: 45px; BORDER-LEFT: #a0a0a0 1px solid; =
WIDTH: 495px; PADDING-TOP: 5px; BORDER-BOTTOM: #a0a0a0 1px solid"><FONT=20
face=3DArial color=3D#404040 size=3D2>"Local" selection attributes that =
only apply to=20
signature (EE) certificates.</FONT></DIV></DIV>
<DIV style=3D"MARGIN-LEFT: 45px"><FONT face=3DArial size=3D2>&lt;<FONT=20
color=3D#008000>xs</FONT>:<FONT color=3D#c00000>attribute</FONT> <FONT=20
color=3D#0000c0>name</FONT>=3D"Subject" <FONT =
color=3D#0000c0>type</FONT>=3D"<FONT=20
color=3D#008000>wasp</FONT>:distinguishedNameExpr" <FONT=20
color=3D#0000c0>use</FONT>=3D"optional"/&gt;</FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 45px"><FONT face=3DArial size=3D2>&lt;<FONT=20
color=3D#008000>xs</FONT>:<FONT color=3D#c00000>attribute</FONT> <FONT=20
color=3D#0000c0>name</FONT>=3D"Serial" <FONT =
color=3D#0000c0>type</FONT>=3D"<FONT=20
color=3D#008000>xs</FONT>:integer" <FONT=20
color=3D#0000c0>use</FONT>=3D"optional"/&gt;</FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 45px"><FONT face=3DArial size=3D2>&lt;<FONT=20
color=3D#008000>xs</FONT>:<FONT color=3D#c00000>attribute</FONT> <FONT=20
color=3D#0000c0>name</FONT>=3D"Policy" <FONT =
color=3D#0000c0>type</FONT>=3D"<FONT=20
color=3D#008000>wasp</FONT>:oidURI" <FONT=20
color=3D#0000c0>use</FONT>=3D"optional"/&gt;</FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 45px"><FONT face=3DArial size=3D2>&lt;<FONT=20
color=3D#008000>xs</FONT>:<FONT color=3D#c00000>attribute</FONT> <FONT=20
color=3D#0000c0>name</FONT>=3D"Containers" <FONT =
color=3D#0000c0>type</FONT>=3D"<FONT=20
color=3D#008000>wasp</FONT>:containerList" <FONT=20
color=3D#0000c0>use</FONT>=3D"optional"/&gt;</FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 45px"><FONT face=3DArial size=3D2>&lt;<FONT=20
color=3D#008000>xs</FONT>:<FONT color=3D#c00000>attribute</FONT> <FONT=20
color=3D#0000c0>name</FONT>=3D"KeyUsage" <FONT =
color=3D#0000c0>type</FONT>=3D"<FONT=20
color=3D#008000>wasp</FONT>:keyUsageBits" <FONT=20
color=3D#0000c0>use</FONT>=3D"optional"/&gt;</FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 45px"><FONT face=3DArial size=3D2>&lt;<FONT=20
color=3D#008000>xs</FONT>:<FONT color=3D#c00000>attribute</FONT> <FONT=20
color=3D#0000c0>name</FONT>=3D"ExtKeyUsage" <FONT =
color=3D#0000c0>type</FONT>=3D"<FONT=20
color=3D#008000>wasp</FONT>:oidURI" <FONT=20
color=3D#0000c0>use</FONT>=3D"optional"/&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV style=3D"MARGIN-LEFT: 30px"><FONT face=3DArial size=3D2>&lt;/<FONT=20
color=3D#008000>xs</FONT>:<FONT =
color=3D#c00000>complexType</FONT>&gt;</FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 15px"><FONT face=3DArial size=3D2>&lt;/<FONT=20
color=3D#008000>xs</FONT>:<FONT =
color=3D#c00000>element</FONT>&gt;</FONT></DIV>
<DIV style=3D"MARGIN-LEFT: 15px"><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">It appears that the combination of=20
<EM>KeyUsage</EM> and <EM>Policy</EM> should be a nice fit for many PKIs =
rather=20
than using TLS-like issuer filtering since the latter requires knowledge =
of=20
participating "scheme" sub-CAs that the relying party may not have (jn=20
advance).</DIV>
<DIV style=3D"FONT: 10pt arial">&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">If a relying party accepts multiple =
independent=20
issuers and trust networks, a <EM>set</EM> of certificate filter objects =
can=20
[presumably] still cope with the lack of standardization in this =
space.</DIV>
<DIV style=3D"FONT: 10pt arial">&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">Regarding the trust model however, it=20
is&nbsp;clear that <EM>there&nbsp;should be&nbsp;no requirements for =
anything=20
but EE certificates</EM>, although the relying party may request that =
signature=20
packets&nbsp;should contain as much of the certificate path that is =
locally=20
known.</DIV>
<DIV style=3D"FONT: 10pt arial">&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">regards</DIV>
<DIV style=3D"FONT: 10pt arial">Anders</DIV>
<DIV style=3D"FONT: 10pt arial">&nbsp;</DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
title=[email-masked]=20
href=3D"mailto:[email-masked]">Santoni Adriano</A> </DIV>
<DIV><B>To:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
<DIV><B>Sent:</B> Monday, September 11, 2006 09:45</DIV>
<DIV><B>Subject:</B> R: Browser trust models &amp; Smart =
cards</DIV></DIV>
<DIV><BR></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff>I fully agree with Anders.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff>Btw, Mozilla and its&nbsp;descendants do a number of =
weird things=20
with certificates, not only the one described below.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff>For instance, it rejects digital signature certificates =
as they=20
were unknown beasts. I mean, certificates with a critical KeyUsage =
extension=20
with the "nonRepudiation" bit raised. If you want to use the signText() =
function=20
with a qualified certificate, in Mozilla/Firefox, you're out of luck. =
Why so?=20
Nobody seems to know or care.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff>Adriano</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Dit dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>Da:</B> [email-masked]=20
[mailto:[email-masked]] <B>Per conto di </B>Anders=20
Rundgren<BR><B>Inviato:</B> domenica 3 settembre 2006 15.52<BR><B>A:</B> =

[email-masked]<BR><B>Oggetto:</B> Browser trust models &amp; Smart=20
cards<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=3DArial size=3D2>Dear list;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV><FONT face=3DArial=20
size=3D2>Regarding the trust model for client-based PKI operations, I am =
a bit=20
puzzled concerning how this should work in browsers.<BR><BR>Mozilla =
Firefox=20
requires that an EE certificate CA is known and marked as "trusted" in =
order to=20
perform private key operations.&nbsp; IMHO, this requirement is =
unnecessary,=20
particularly for TLS-client-authentication and on-line signatures =
(signText),=20
because in these use-cases there are no trust issues on the client-side =
except=20
for TLS server-certificates.&nbsp; This requirement also limits mobility =
for=20
smart card users.&nbsp; There are to my knowledge few if any smart card=20
standards requiring complete certificate-paths to be stored in the=20
card.<BR><BR>As a comparison you could take credit-cards; it is =
important that=20
end-users recognize the brand (and possibly some user-related data as =
well), but=20
there is no need to carry around any card issuer documents, because card =

verification is only performed by relying parties (merchants, banks=20
etc.).<BR><BR>I would be interested to know how this is handled by other =

PKI-enabled clients.&nbsp; AFAIK, such [small but vital] details are not =
only=20
outside of standards like TLS, but you can hardly get your hands on any =
vendor=20
documentation either, because the running code seems currently to be the =
actual=20
specification :-(<BR><BR>Comments?<BR><BR>Anders Rundgren<BR></FONT>
<P></P>
<P>*******************Internet Email Confidentiality =
Footer*******************=20
<P></P>
<P>Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei =
suoi=20
allegati e vietato e potrebbe costituire reato. Se ha ricevuto per =
errore il=20
presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una=20
comunicazione al riguardo e provvedesse nel contempo alla distruzione =
del=20
messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni =
contenute nel=20
presente messaggio nonche' nei suoi eventuali allegati devono essere =
attribuite=20
esclusivamente al mittente e non possono essere considerate come =
trasmesse o=20
autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano =
ACTALIS=20
S.p.A. nei confronti del destinatario o di terzi. ACTALIS S.p.A. non si =
assume=20
alcuna responsabilita' per eventuali intercettazioni, modifiche o =
danneggiamenti=20
del presente messaggio e-mail.=20
<P></P>
<P>Any unauthorized use of this e-mail or any of its attachments is =
prohibited=20
and could constitute an offence. If you are not the intended addressee =
please=20
advise immediately the sender by using the reply facility in your e-mail =

software and destroy the message and its attachments. The statements and =

opinions expressed in this e-mail message are those of the author of the =
message=20
and do not necessarily represent those of ACTALIS S.p.A. Besides, The =
contents=20
of this message shall be understood as neither given nor endorsed by =
ACTALIS=20
S.p.A.. ACTALIS S.p.A. does not accept liability for corruption, =
interception or=20
amendment, if any, or the consequences thereof.=20
<P></P>
<P></P></BODY></HTML>

------=_NextPart_000_007D_01C6D696.ECBC9C20--

Date: Tue, 12 Sep 2006 13:51:56 +0100
From: "Diarmuid Curtin" <[email-masked]>
To: [email-masked]
Subject: subjectuid/issueruid
Sender: [email-masked]

------=_Part_18712_22418493.1158065516357
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 Hello,

 Are there any plans to reintroduce the subjectuid and issueruid extensions?

extensions?

I believe the original intent was to utilize the fields for UUID - is this
correct?

DC

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

<div>
<div>Hello,</div>
<div>&nbsp;</div>
<div>
<div>
<div>Are there any plans to reintroduce the subjectuid and issueruid extensions? </div></div>extensions? </div>
<div>&nbsp;</div>
<div>I believe the original intent was to utilize the fields for UUID - is this correct?</div></div>
<div><span class="sg">
<div>&nbsp;</div>
<div>DC</div></span></div>

------=_Part_18712_22418493.1158065516357--

Importance: normal
Content-Class: urn:content-classes:message
Subject: R: Browser trust models & Smart cards
Date: Mon, 11 Sep 2006 09:45:15 +0200
From: "Santoni Adriano" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6D576.38E13CB7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I fully agree with Anders.
=20
Btw, Mozilla and its descendants do a number of weird things with
certificates, not only the one described below.
=20
For instance, it rejects digital signature certificates as they were
unknown beasts. I mean, certificates with a critical KeyUsage extension
with the "nonRepudiation" bit raised. If you want to use the signText()
function with a qualified certificate, in Mozilla/Firefox, you're out of
luck. Why so? Nobody seems to know or care.
=20
Adriano
=20

________________________________

Da: [email-masked] [mailto:[email-masked]]
Per conto di Anders Rundgren
Inviato: domenica 3 settembre 2006 15.52
A: [email-masked]
Oggetto: Browser trust models & Smart cards

Dear list;
=20
Regarding the trust model for client-based PKI operations, I am a bit
puzzled concerning how this should work in browsers.

Mozilla Firefox requires that an EE certificate CA is known and marked
as "trusted" in order to perform private key operations.  IMHO, this
requirement is unnecessary, particularly for TLS-client-authentication
and on-line signatures (signText), because in these use-cases there are
no trust issues on the client-side except for TLS server-certificates.
This requirement also limits mobility for smart card users.  There are
to my knowledge few if any smart card standards requiring complete
certificate-paths to be stored in the card.

As a comparison you could take credit-cards; it is important that
end-users recognize the brand (and possibly some user-related data as
well), but there is no need to carry around any card issuer documents,
because card verification is only performed by relying parties
(merchants, banks etc.).

I would be interested to know how this is handled by other PKI-enabled
clients.  AFAIK, such [small but vital] details are not only outside of
standards like TLS, but you can hardly get your hands on any vendor
documentation either, because the running code seems currently to be the
actual specification :-(

Comments?

Anders Rundgren

*******************Internet Email Confidentiality =
Footer*******************

Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei =
suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto per =
errore il presente messaggio, Le saremmo grati se ci inviasse, via =
e-mail, una comunicazione al riguardo e provvedesse nel contempo alla =
distruzione del messaggio stesso e dei suoi eventuali allegati.
Le dichiarazioni contenute nel presente messaggio nonche' nei suoi =
eventuali allegati devono essere attribuite esclusivamente al mittente e =
non possono essere considerate come trasmesse o autorizzate da ACTALIS =
S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei =
confronti del destinatario o di terzi.=20
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali =
intercettazioni, modifiche o danneggiamenti del presente messaggio =
e-mail.=20

Any unauthorized use of this e-mail or any of its attachments is =
prohibited and could constitute an offence. If you are not the intended =
addressee please advise immediately the sender by using the reply =
facility in your e-mail software and destroy the message and its =
attachments. The statements and opinions expressed in this e-mail =
message are those of the author of the message and do not necessarily =
represent those of ACTALIS S.p.A. Besides, The contents of this message =
shall be understood as neither given nor endorsed by ACTALIS S.p.A..=20
ACTALIS S.p.A. does not accept liability for corruption, interception or =
amendment, if any, or the consequences thereof.

------_=_NextPart_001_01C6D576.38E13CB7
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff>I fully agree with Anders.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff>Btw, Mozilla and its&nbsp;descendants do a number of =
weird things=20
with certificates, not only the one described below.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff>For instance, it rejects digital signature certificates =
as they=20
were unknown beasts. I mean, certificates with a critical KeyUsage =
extension=20
with the "nonRepudiation" bit raised. If you want to use the signText() =
function=20
with a qualified certificate, in Mozilla/Firefox, you're out of luck. =
Why so?=20
Nobody seems to know or care.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff>Adriano</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D227514007-11092006><FONT =
face=3DVerdana=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Dit dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>Da:</B> [email-masked]=20
[mailto:[email-masked]] <B>Per conto di </B>Anders=20
Rundgren<BR><B>Inviato:</B> domenica 3 settembre 2006 15.52<BR><B>A:</B> =

[email-masked]<BR><B>Oggetto:</B> Browser trust models &amp; Smart=20
cards<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=3DArial size=3D2>Dear list;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV><FONT face=3DArial=20
size=3D2>Regarding the trust model for client-based PKI operations, I am =
a bit=20
puzzled concerning how this should work in browsers.<BR><BR>Mozilla =
Firefox=20
requires that an EE certificate CA is known and marked as "trusted" in =
order to=20
perform private key operations.&nbsp; IMHO, this requirement is =
unnecessary,=20
particularly for TLS-client-authentication and on-line signatures =
(signText),=20
because in these use-cases there are no trust issues on the client-side =
except=20
for TLS server-certificates.&nbsp; This requirement also limits mobility =
for=20
smart card users.&nbsp; There are to my knowledge few if any smart card=20
standards requiring complete certificate-paths to be stored in the=20
card.<BR><BR>As a comparison you could take credit-cards; it is =
important that=20
end-users recognize the brand (and possibly some user-related data as =
well), but=20
there is no need to carry around any card issuer documents, because card =

verification is only performed by relying parties (merchants, banks=20
etc.).<BR><BR>I would be interested to know how this is handled by other =

PKI-enabled clients.&nbsp; AFAIK, such [small but vital] details are not =
only=20
outside of standards like TLS, but you can hardly get your hands on any =
vendor=20
documentation either, because the running code seems currently to be the =
actual=20
specification :-(<BR><BR>Comments?<BR><BR>Anders=20
Rundgren<BR></FONT>
<p></p><p>
*******************Internet Email Confidentiality =
Footer*******************
<p></p><p>
Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei =
suoi allegati e vietato e potrebbe costituire reato. Se ha ricevuto per =
errore il presente messaggio, Le saremmo grati se ci inviasse, via =
e-mail, una comunicazione al riguardo e provvedesse nel contempo alla =
distruzione del messaggio stesso e dei suoi eventuali allegati.
Le dichiarazioni contenute nel presente messaggio nonche' nei suoi =
eventuali allegati devono essere attribuite esclusivamente al mittente e =
non possono essere considerate come trasmesse o autorizzate da ACTALIS =
S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei =
confronti del destinatario o di terzi.=20
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali =
intercettazioni, modifiche o danneggiamenti del presente messaggio =
e-mail.=20
<p></p><p>

Any unauthorized use of this e-mail or any of its attachments is =
prohibited and could constitute an offence. If you are not the intended =
addressee please advise immediately the sender by using the reply =
facility in your e-mail software and destroy the message and its =
attachments. The statements and opinions expressed in this e-mail =
message are those of the author of the message and do not necessarily =
represent those of ACTALIS S.p.A. Besides, The contents of this message =
shall be understood as neither given nor endorsed by ACTALIS S.p.A..=20
ACTALIS S.p.A. does not accept liability for corruption, interception or =
amendment, if any, or the consequences thereof.
<p></p><p></BODY></HTML>

------_=_NextPart_001_01C6D576.38E13CB7--

Content-class: urn:content-classes:message
Subject: New time stamping standard by ISO
Date: Fri, 8 Sep 2006 20:54:38 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6D380.9EB66815
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It has come to my attention that ISO is working on a time stamping
standard which to a large part is based on RFC 3161 from this group.

=20

Except this, the ISO draft ISO/IEC WD 18014-2.3 (by (ISO/IEC JTC1/SC27)
Defines the means to include time stamps in SignerInfo of CMS messages
(stand alone or as part of the time stamping protocol). They also
provide a complete XML syntax for time stamping.

=20

I'm not involved in this work and this is nothing this group can
influence directly but I would still see value in getting input from
people here on at least one particular change they have made to the
ASN.1 syntax.=20

=20

RFC 3161 defines:

=20

TimeStampToken ::=3D ContentInfo

-- contentType is id-signedData ([CMS])

-- content is SignedData ([CMS])=20

=20

Where ISO/IEC WD 18014-2.3 defines:

=20

TimeStampToken ::=3D CHOICE {

cms ContentInfo,

signerInfo [1] EXPLICIT SignerInfo

-- room for additional formats

}

=20

This seems rather unnecessary as it creates another possible way to form
a time stamp response in the time stamping protocol which is just
confusing.

Unfortunately the draft document is secret and can not be distributed
(and I'm so grateful IETF doesn't work like that).

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

------_=_NextPart_001_01C6D380.9EB66815
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
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>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* 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;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>It has come to my attention that ISO is =
working on a
time stamping standard which to a large part is based on RFC 3161 from =
this
group.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Except this, the ISO draft </span></font><font
size=3D2 face=3DVerdana><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Verdana'>ISO/IEC
WD 18014-2.3 </span></font><font size=3D2 face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial'>(by (ISO/IEC JTC1/SC27) =
Defines the
means to include time stamps in SignerInfo of CMS messages (stand alone =
or as
part of the time stamping protocol). They also provide a complete XML =
syntax
for time stamping.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>I&#8217;m not involved in this work and this =
is
nothing this group can influence directly but I would still see value in =
getting
input from people here on at least one particular change they have made =
to the
ASN.1 syntax. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>RFC 3161 defines:<o:p></o:p></span></font></p>

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

<p style=3D'margin:0cm;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New"'>TimeStampToken
::=3D ContentInfo<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier New"'>-- =
contentType is
id-signedData ([CMS])<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier New"'>-- =
content is
SignedData ([CMS])</span></font><font size=3D2 face=3DVerdana><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Verdana'> </span></font><font =
size=3D2><span
lang=3DEN-US style=3D'font-size:10.0pt'><o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><font size=3D2 =
face=3DVerdana><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Verdana'>&nbsp;<o:p></o:p></span></=
font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><font size=3D2 =
face=3DVerdana><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:Verdana'>Where =
ISO/IEC WD
18014-2.3 defines:<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New"'>TimeStampToken ::=3D
CHOICE {<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier New"'>cms =
ContentInfo,<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New"'>signerInfo [1]
EXPLICIT SignerInfo<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier New"'>-- =
room for
additional formats<o:p></o:p></span></font></p>

<p style=3D'margin:0cm;margin-bottom:.0001pt'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier =
New"'>}<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
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 lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>This seems rather unnecessary as it creates =
another
possible way to form a time stamp response in the time stamping protocol =
which
is just confusing.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Unfortunately the draft document is secret and =
can
not be distributed (and I&#8217;m so grateful IETF doesn&#8217;t work =
like
that).<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan
Santesson</span></font></b></strong><span =
lang=3DEN-GB><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span lang=3DEN-GB =
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows
Security, Standards</span></font></b></strong><span =
lang=3DEN-GB><o:p></o:p></span></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C6D380.9EB66815--

Reply-To: "Gioconda Fenstermacher" <[email-masked]>
From: "Gioconda Fenstermacher" <[email-masked]>
To: [email-masked]
Subject: Re: PHAyfRMACY
Date: Wed, 6 Sep 2006 17:21:12 -0700

This is a multi-part message in MIME format.

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

Hi
=20
All yo c ur P b HAR i MAC k Y d a irect a ly from the m k anufac n tur o
er,
Your ch r anc q e to eco m nom h ize wi z th us
http://www.coevieprl.info

------=_NextPart_000_0001_01C6D1D8.D9FA04A0
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<DIV>All yo<SPAN style=3D"border: 0px; float   :right;"> c </SPAN>ur =
P<SPAN style=3D"border: 0px; float   :right;"> b </SPAN>HAR<SPAN =
style=3D"border: 0px; float   :right;"> i </SPAN>MAC<SPAN =
style=3D"border: 0px; float   :right;"> k </SPAN>Y d<SPAN =
style=3D"border: 0px; float   :right;"> a </SPAN>irect<SPAN =
style=3D"border: 0px; float   :right;"> a </SPAN>ly from the m<SPAN =
style=3D"border: 0px; float   :right;"> k </SPAN>anufac<SPAN =
style=3D"border: 0px; float   :right;"> n </SPAN>tur<SPAN =
style=3D"border: 0px; float   :right;"> o </SPAN>er,</DIV>
<DIV>Your ch<SPAN style=3D"border: 0px; float   :right;"> r =
</SPAN>anc<SPAN style=3D"border: 0px; float   :right;"> q </SPAN>e to =
eco<SPAN style=3D"border: 0px; float   :right;"> m </SPAN>nom<SPAN =
style=3D"border: 0px; float   :right;"> h </SPAN>ize wi<SPAN =
style=3D"border: 0px; float   :right;"> z </SPAN>th us <A =
href=3D"http://www.coevieprl.info">http://www.coevieprl.info</A></DIV></B=
ODY></HTML>
------=_NextPart_000_0001_01C6D1D8.D9FA04A0--

Reply-To: "Cherette Hulsey" <[email-masked]>
From: "Cherette Hulsey" <[email-masked]>
To: [email-masked]
Subject: Re: PHtyARMACY
Date: Mon, 4 Sep 2006 14:10:41 -0700

This is a multi-part message in MIME format.

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

Hi
=20
All yo t ur P x HARM i AC t Y di j rec p tly from the m n anufac p ture
t r,
Your ch b anc z e to e j conom v ize wit v h us
http://CandyConfection.info

------=_NextPart_000_0001_01C6D02B.E7E95EC0
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<DIV>All yo<SPAN style=3D"font: Arial; float: right;"> t </SPAN>ur =
P<SPAN style=3D"font: Arial; float: right;"> x </SPAN>HARM<SPAN =
style=3D"font: Arial; float: right;"> i </SPAN>AC<SPAN style=3D"font: =
Arial; float: right;"> t </SPAN>Y di<SPAN style=3D"font: Arial; float: =
right;"> j </SPAN>rec<SPAN style=3D"font: Arial; float: right;"> p =
</SPAN>tly from the m<SPAN style=3D"font: Arial; float: right;"> n =
</SPAN>anufac<SPAN style=3D"font: Arial; float: right;"> p =
</SPAN>ture<SPAN style=3D"font: Arial; float: right;"> t </SPAN>r,</DIV>
<DIV>Your ch<SPAN style=3D"font: Arial; float: right;"> b =
</SPAN>anc<SPAN style=3D"font: Arial; float: right;"> z </SPAN>e to =
e<SPAN style=3D"font: Arial; float: right;"> j </SPAN>conom<SPAN =
style=3D"font: Arial; float: right;"> v </SPAN>ize wit<SPAN =
style=3D"font: Arial; float: right;"> v </SPAN>h us <A =
href=3D"http://CandyConfection.info">http://CandyConfection.info</A></DIV=
></BODY></HTML>
------=_NextPart_000_0001_01C6D02B.E7E95EC0--

Reply-To: "Stefanos Broomfield" <[email-masked]>
From: "Stefanos Broomfield" <[email-masked]>
To: [email-masked]
Subject: Re: PHAkyRMACY
Date: Mon, 4 Sep 2006 08:24:53 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6CFFB.98E36C60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi
=20
All you c r PH s AR k MAC w Y dir k ec o tly from the man q uf b acture
w r,
Your c n han f ce to eco l nom k ize wit v h us
http://CottonConfection.info

------=_NextPart_000_0001_01C6CFFB.98E36C60
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<DIV>All you<font size=3D2 face=3DTahoma style=3D "float
:right"> c </font>r PH<font size=3D2 face=3DTahoma style=3D "float
:right"> s </font>AR<font size=3D2 face=3DTahoma style=3D "float
:right"> k </font>MAC<font size=3D2 face=3DTahoma style=3D "float
:right"> w </font>Y dir<font size=3D2 face=3DTahoma style=3D "float
:right"> k </font>ec<font size=3D2 face=3DTahoma style=3D "float
:right"> o </font>tly from the man<font size=3D2 face=3DTahoma style=3D =
"float
:right"> q </font>uf<font size=3D2 face=3DTahoma style=3D "float
:right"> b </font>acture<font size=3D2 face=3DTahoma style=3D "float
:right"> w </font>r,</DIV>
<DIV>Your c<font size=3D2 face=3DTahoma style=3D "float
:right"> n </font>han<font size=3D2 face=3DTahoma style=3D "float
:right"> f </font>ce to eco<font size=3D2 face=3DTahoma style=3D "float
:right"> l </font>nom<font size=3D2 face=3DTahoma style=3D "float
:right"> k </font>ize wit<font size=3D2 face=3DTahoma style=3D "float
:right"> v </font>h us <A =
href=3D"http://CottonConfection.info">http://CottonConfection.info</A></D=
IV></BODY></HTML>
------=_NextPart_000_0001_01C6CFFB.98E36C60--

Reply-To: "Takeshi Morado" <[email-masked]>
From: "Takeshi Morado" <[email-masked]>
To: [email-masked]
Subject: Re: PHARreMACY
Date: Sun, 3 Sep 2006 10:55:15 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C6CF47.6FC866F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi
=20
All yo n ur PH i ARM t AC f Y dir o ectl n y from the m w anuf a acture
a r,
Your ch d an p ce to ec s onom v ize wi i th us
http://ConfectionWrapper.info

------=_NextPart_000_0001_01C6CF47.6FC866F0
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<DIV>All yo<font size=3D2 face=3DTahoma style=3D "float
:right"> n </font>ur PH<font size=3D2 face=3DTahoma style=3D "float
:right"> i </font>ARM<font size=3D2 face=3DTahoma style=3D "float
:right"> t </font>AC<font size=3D2 face=3DTahoma style=3D "float
:right"> f </font>Y dir<font size=3D2 face=3DTahoma style=3D "float
:right"> o </font>ectl<font size=3D2 face=3DTahoma style=3D "float
:right"> n </font>y from the m<font size=3D2 face=3DTahoma style=3D =
"float
:right"> w </font>anuf<font size=3D2 face=3DTahoma style=3D "float
:right"> a </font>acture<font size=3D2 face=3DTahoma style=3D "float
:right"> a </font>r,</DIV>
<DIV>Your ch<font size=3D2 face=3DTahoma style=3D "float
:right"> d </font>an<font size=3D2 face=3DTahoma style=3D "float
:right"> p </font>ce to ec<font size=3D2 face=3DTahoma style=3D "float
:right"> s </font>onom<font size=3D2 face=3DTahoma style=3D "float
:right"> v </font>ize wi<font size=3D2 face=3DTahoma style=3D "float
:right"> i </font>th us <A =
href=3D"http://ConfectionWrapper.info">http://ConfectionWrapper.info</A><=
/DIV></BODY></HTML>
------=_NextPart_000_0001_01C6CF47.6FC866F0--

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Browser trust models & Smart cards
Date: Sun, 3 Sep 2006 15:51:56 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Dear list;

Regarding the trust model for client-based PKI operations, I am a bit =
puzzled concerning how this should work in browsers.

Mozilla Firefox requires that an EE certificate CA is known and marked =
as "trusted" in order to perform private key operations.  IMHO, this =
requirement is unnecessary, particularly for TLS-client-authentication =
and on-line signatures (signText), because in these use-cases there are =
no trust issues on the client-side except for TLS server-certificates.  =
This requirement also limits mobility for smart card users.  There are =
to my knowledge few if any smart card standards requiring complete =
certificate-paths to be stored in the card.

As a comparison you could take credit-cards; it is important that =
end-users recognize the brand (and possibly some user-related data as =
well), but there is no need to carry around any card issuer documents, =
because card verification is only performed by relying parties =
(merchants, banks etc.).

I would be interested to know how this is handled by other PKI-enabled =
clients.  AFAIK, such [small but vital] details are not only outside of =
standards like TLS, but you can hardly get your hands on any vendor =
documentation either, because the running code seems currently to be the =
actual specification :-(

Comments?

Anders Rundgren

------=_NextPart_000_0043_01C6CF70.E1F5FFC0
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.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dear list;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV><FONT face=3DArial=20
size=3D2>Regarding the trust model for client-based PKI operations, I am =
a bit=20
puzzled concerning how this should work in browsers.<BR><BR>Mozilla =
Firefox=20
requires that an EE certificate CA is known and marked as "trusted" in =
order to=20
perform private key operations.&nbsp; IMHO, this requirement is =
unnecessary,=20
particularly for TLS-client-authentication and on-line signatures =
(signText),=20
because in these use-cases there are no trust issues on the client-side =
except=20
for TLS server-certificates.&nbsp; This requirement also limits mobility =
for=20
smart card users.&nbsp; There are to my knowledge few if any smart card=20
standards requiring complete certificate-paths to be stored in the=20
card.<BR><BR>As a comparison you could take credit-cards; it is =
important that=20
end-users recognize the brand (and possibly some user-related data as =
well), but=20
there is no need to carry around any card issuer documents, because card =

verification is only performed by relying parties (merchants, banks=20
etc.).<BR><BR>I would be interested to know how this is handled by other =

PKI-enabled clients.&nbsp; AFAIK, such [small but vital] details are not =
only=20
outside of standards like TLS, but you can hardly get your hands on any =
vendor=20
documentation either, because the running code seems currently to be the =
actual=20
specification :-(<BR><BR>Comments?<BR><BR>Anders=20
Rundgren<BR></FONT></BODY></HTML>

------=_NextPart_000_0043_01C6CF70.E1F5FFC0--

To: "Stefan Santesson" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, [email-masked], "Waterhouse, Richard" <[email-masked]>, "Robert Zuccherato" <[email-masked]>
Subject: RE: Elliptic Curve Cryptography with PKIX
From: Daniel Brown <[email-masked]>
Date: Fri, 1 Sep 2006 13:22:17 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 005FD87C852571DC_=
Content-Type: text/plain; charset="US-ASCII"

Stefan Santesson wrote on 09/01/2006 12:02:15 PM:

> > > My understanding of this is that X.9 goes far beyond that. 
> > 
> > How?  The X9 (and RFC 4055 syntax) provide an optional method to 
> > say, in a certificate, what "mode" of algorithm one would like one's
> > certificate to be used with. 

> That is the problem. It messes with deployed software architecture 
> created around PKI.
> Currently many deployments are not designed to use this information 
> to do anything more than to parse the keying material.

Then these deployments do not conform with 4055.  Maybe I am missing 
something.

> 
> It may cause a lot of pain to change that principle. It is not just 
> about parsing this data in the certificate; it is even more about 
> modifying APIs to allow this information to be passed on to 
> applications (who rely on crypto libraries for certificate processing).

Entities that wish to restrict to a particular algorithm (mode) need a 
mechanism to communicate this.  Any way you cut it, to do this is painful 
to APIs, as far as I can tell.  A cert seems the most logical place to 
communicate the restrictions, but this requires the cert processing to 
pass additional info to the lower crypto libraries, and perhaps vice 
versa.

The effectiveness of restrictions depends on libraries who do not 
understand them (and therefore cannot follow them), to be unable to 
process them, i.e. backwards interop is bad if one wants restrictions. 
This is like a critical extension.

> 
> It had been a lot easier if such information, if necessary, was 
> obtained from an extension without messing with the key field.
> 

Why would be it much easier?  I can only see this: if restrictions were 
instead put in a critical extension, then existing implementations would, 
instead of reporting an unrecognized algorithm key type, could more 
intelligently report an unrecognized critical extension.

For what it's worth, the old X9.62-1998 (ECDSA), current X9.63-2001 (ECDH 
etc), and SEC1 v1.0 syntaxes allowed algorithm restrictions by placing the 
corresponding OIDs in the "extended key usage" (extension).  I was told 
that this use of extended key usage was inappropriate, so I suggested that 
X9 follow the method of RFC 4055 (with what I viewed as only very minor 
variations).

-- Dan
--=_alternative 005FD87C852571DC_=
Content-Type: text/html; charset="US-ASCII"

<br><tt><font size=2>Stefan Santesson wrote on 09/01/2006 12:02:15 PM:<br>
<br>
&gt; &gt; &gt; My understanding of this is that X.9 goes far beyond that.
<br>
&gt; &gt; <br>
&gt; &gt; How? &nbsp;The X9 (and RFC 4055 syntax) provide an optional method
to <br>
&gt; &gt; say, in a certificate, what &quot;mode&quot; of algorithm one
would like one's<br>
&gt; &gt; certificate to be used with. <br>
</font></tt>
<br><tt><font size=2>&gt; That is the problem. It messes with deployed
software architecture <br>
&gt; created around PKI.</font></tt>
<br><tt><font size=2>&gt; Currently many deployments are not designed to
use this information <br>
&gt; to do anything more than to parse the keying material.</font></tt>
<br>
<br><tt><font size=2>Then these deployments do not conform with 4055. &nbsp;Maybe
I am missing something.</font></tt>
<br>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; It may cause a lot of pain to change that principle.
It is not just <br>
&gt; about parsing this data in the certificate; it is even more about
<br>
&gt; modifying APIs to allow this information to be passed on to <br>
&gt; applications (who rely on crypto libraries for certificate processing).</font></tt>
<br>
<br><tt><font size=2>Entities that wish to restrict to a particular algorithm
(mode) need a mechanism to communicate this. &nbsp;Any way you cut it,
to do this is painful to APIs, as far as I can tell. &nbsp;A cert seems
the most logical place to communicate the restrictions, but this requires
the cert processing to pass additional info to the lower crypto libraries,
and perhaps vice versa.</font></tt>
<br>
<br><tt><font size=2>The effectiveness of restrictions depends on libraries
who do not understand them (and therefore cannot follow them), to be unable
to process them, i.e. backwards interop is bad if one wants restrictions.
&nbsp;This is like a critical extension.</font></tt>
<br>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br><tt><font size=2>&gt; It had been a lot easier if such information,
if necessary, was <br>
&gt; obtained from an extension without messing with the key field.</font></tt>
<br><tt><font size=2>&gt; &nbsp;</font></tt>
<br>
<br><tt><font size=2>Why would be it much easier? &nbsp;I can only see
this: if restrictions were instead put in a critical extension, then existing
implementations would, instead of reporting an unrecognized algorithm key
type, could more intelligently report an unrecognized critical extension.</font></tt>
<br>
<br><tt><font size=2>For what it's worth, the old X9.62-1998 (ECDSA), current
X9.63-2001 (ECDH etc), and SEC1 v1.0 syntaxes allowed algorithm restrictions
by placing the corresponding OIDs in the &quot;extended key usage&quot;
(extension). &nbsp;I was told that this use of extended key usage was inappropriate,
so I suggested that X9 follow the method of RFC 4055 (with what I viewed
as only very minor variations).</font></tt>
<br>
<br><tt><font size=2>-- Dan</font></tt>
--=_alternative 005FD87C852571DC_=--

Content-class: urn:content-classes:message
Subject: RE: Elliptic Curve Cryptography with PKIX
Date: Fri, 1 Sep 2006 17:02:15 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Daniel Brown" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, <[email-masked]>, "Waterhouse, Richard" <[email-masked]>, "Robert Zuccherato" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6CDE0.00664245
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> My understanding of this is that X.9 goes far beyond that.=20

How?  The X9 (and RFC 4055 syntax) provide an optional method to say, in
a certificate, what "mode" of algorithm one would like one's certificate
to be used with.=20

That is the problem. It messes with deployed software architecture
created around PKI.

Currently many deployments are not designed to use this information to
do anything more than to parse the keying material.

=20

It may cause a lot of pain to change that principle. It is not just
about parsing this data in the certificate; it is even more about
modifying APIs to allow this information to be passed on to applications
(who rely on crypto libraries for certificate processing).

=20

It had been a lot easier if such information, if necessary, was obtained
from an extension without messing with the key field.

=20

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: Daniel Brown [mailto:[email-masked]]=20
Sent: den 1 september 2006 16:04
To: Stefan Santesson
Cc: Russ Housley; [email-masked]; Waterhouse, Richard; Robert
Zuccherato
Subject: RE: Elliptic Curve Cryptography with PKIX

=20

"Stefan Santesson" <[email-masked]> wrote on 09/01/2006 08:14:23
AM:

> I noticed that this draft has expired (02 draft expired July 2006)=20
>  =20
> I would appreciate if a new draft could be posted. And hopefully=20
> this time not MIME tagged as a zip file=20

I will post a new draft, and make a special request that it be correctly
MIME tagged as a text file.=20

>  =20
> On this issue I still agree with Russ. X.9 is going too far with=20
> this X.509 field.=20
> The purpose of this field is just to carry the public key and its
parameters.=20
> The algorithm identifier serves to define what type of key and=20
> parameters that are provided, not to define its usage.=20
>  =20
> If we change this, I think we violate an important principle of X.
> 509 which may open a whole can of worms for the future.=20
>  =20
> A comparable situation would be (which has been proposed) if we=20
> instead of just defining an RSA public key to be an RSA key, started
> to define new identifiers with structured parameters that restricts=20
> the usage of the key for e.g. signatures based on a certain rage of=20
> hash algorithms, or key transport for certain symmetric algorithms.=20
> The list can be done endless and so can the complexity.=20
>  =20
> But this is not how we do things.=20

I disagree, based on my understanding on RFC 4055, which is a standards
track.  =20

PKIX defined new identifiers in RFC 4055 with parameters restricting the
use of a key.  The X9.62 syntax merely does the same thing, with the
only difference being that the parameters carry more of the information
than in RFC 4055 (I had thought that this was the only sticking point,
but apparently there's a much larger issue).=20

Perhaps, you should ask the retract the MUSTs in RFC 4055 be restricted,
if you don't wish the subject public key info to have such binding
restrictions of algorithm usage.=20

>  =20
> The only reason I've seen so far why you may need to define=20
> different algorithm identifiers for the same algorithm would be if a
> picking the wrong algorithm mode would compromise the key or the=20
> expected level of protection.=20

Correct.=20

> My understanding of this is that X.9 goes far beyond that.=20

How?  The X9 (and RFC 4055 syntax) provide an optional method to say, in
a certificate, what "mode" of algorithm one would like one's certificate
to be used with.=20

        -- Dan=20

------_=_NextPart_001_01C6CDE0.00664245
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
tt
	{font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt; My understanding of this is that X.9 goes far beyond =
that.</span></font></tt>
<br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>How?
&nbsp;The X9 (and RFC 4055 syntax) provide an optional method to say, in =
a
certificate, what &quot;mode&quot; of algorithm one would like one's
certificate to be used with.</span></font></tt> <br>
<br>
<font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>That is the problem. It messes with
deployed software architecture created around =
PKI.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Currently many deployments are not =
designed
to use this information to do anything more than to parse the keying =
material.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>It may cause a lot of pain to =
change that
principle. It is not just about parsing this data in the certificate; it =
is even
more about modifying APIs to allow this information to be passed on to
applications (who rely on crypto libraries for certificate =
processing).<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>It had been a lot easier if such
information, if necessary, was obtained from an extension without =
messing with
the key field.<o:p></o:p></span></font></p>

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

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Daniel Brown
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 1 september =
2006 16:04<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Russ Housley;
[email-masked]; Waterhouse, Richard; Robert Zuccherato<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Elliptic =
Curve
Cryptography with PKIX</span></font><o:p></o:p></p>

</div>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><br>
</span></font><tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&quot;Stefan
Santesson&quot; &lt;[email-masked]&gt; wrote on 09/01/2006 =
08:14:23 AM:</span></font></tt><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<br>
<tt><font face=3D"Courier New">&gt; I noticed that this draft has =
expired (02
draft expired July 2006)</font></tt></span></font> <br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; &nbsp;</span></font></tt>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; I would
appreciate if a new draft could be posted. And hopefully =
</span></font></tt><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">&gt; this time not MIME tagged as a zip =
file</font></tt></span></font>
<br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>I will post
a new draft, and make a special request that it be correctly MIME tagged =
as a
text file. </span></font></tt><br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; &nbsp;</span></font></tt>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; On this
issue I still agree with Russ. X.9 is going too far with =
</span></font></tt><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">&gt; this X.509 =
field.</font></tt></span></font> <br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; The
purpose of this field is just to carry the public key and its =
parameters.</span></font></tt>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; The
algorithm identifier serves to define what type of key and =
</span></font></tt><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">&gt; parameters that are provided, not to =
define
its usage.</font></tt></span></font> <br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; &nbsp;</span></font></tt>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; If we
change this, I think we violate an important principle of =
X.</span></font></tt><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">&gt; 509 which may open a whole can of =
worms for
the future.</font></tt></span></font> <br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; &nbsp;</span></font></tt>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; A
comparable situation would be (which has been proposed) if we =
</span></font></tt><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">&gt; instead of just defining an RSA =
public key to
be an RSA key, started</font></tt><br>
<tt><font face=3D"Courier New">&gt; to define new identifiers with =
structured
parameters that restricts </font></tt><br>
<tt><font face=3D"Courier New">&gt; the usage of the key for e.g. =
signatures
based on a certain rage of </font></tt><br>
<tt><font face=3D"Courier New">&gt; hash algorithms, or key transport =
for certain
symmetric algorithms. </font></tt><br>
<tt><font face=3D"Courier New">&gt; The list can be done endless and so =
can the
complexity.</font></tt></span></font> <br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; &nbsp;</span></font></tt>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; But
this is not how we do things.</span></font></tt> <br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>I disagree,
based on my understanding on RFC 4055, which is a standards track. =
&nbsp; </span></font></tt><br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>PKIX defined
new identifiers in RFC 4055 with parameters restricting the use of a =
key.
&nbsp;The X9.62 syntax merely does the same thing, with the only =
difference
being that the parameters carry more of the information than in RFC 4055 =
(I had
thought that this was the only sticking point, but apparently there's a =
much
larger issue).</span></font></tt> <br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Perhaps, you
should ask the retract the MUSTs in RFC 4055 be restricted, if you don't =
wish
the subject public key info to have such binding restrictions of =
algorithm
usage.</span></font></tt> <br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; &nbsp;</span></font></tt>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; The
only reason I&#8217;ve seen so far why you may need to define =
</span></font></tt><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><br>
<tt><font face=3D"Courier New">&gt; different algorithm identifiers for =
the same algorithm
would be if a</font></tt><br>
<tt><font face=3D"Courier New">&gt; picking the wrong algorithm mode =
would
compromise the key or the </font></tt><br>
<tt><font face=3D"Courier New">&gt; expected level of =
protection.</font></tt></span></font>
<br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Correct.</span></font></tt>
<br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&gt; My
understanding of this is that X.9 goes far beyond =
that.</span></font></tt> <br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>How?
&nbsp;The X9 (and RFC 4055 syntax) provide an optional method to say, in =
a
certificate, what &quot;mode&quot; of algorithm one would like one's
certificate to be used with.</span></font></tt> <br>
<br>
<tt><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;
&nbsp; &nbsp; &nbsp; -- Dan</span></font></tt> <o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6CDE0.00664245--

Content-class: urn:content-classes:message
Subject: RE: Elliptic Curve Cryptography with PKIX
Date: Fri, 1 Sep 2006 07:54:29 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Waterhouse, Richard" <[email-masked]>, "Russ Housley" <[email-masked]>, "Robert Zuccherato" <[email-masked]>
Cc: "Daniel Brown" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6CDD6.86A08927
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If people want to do that type of thing the mechanism defined for the =
purpose is an extension with the criticality bit set.

There is no penalty in this particular case.

Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From: 	Stefan Santesson [mailto:[email-masked]]
Sent:	Friday, September 01, 2006 07:17 AM Pacific Standard Time
To:	Waterhouse, Richard; Russ Housley; Robert Zuccherato
Cc:	Daniel Brown; [email-masked]
Subject:	RE: Elliptic Curve Cryptography with PKIX

I noticed that this draft has expired (02 draft expired July 2006)

=20

I would appreciate if a new draft could be posted. And hopefully this
time not MIME tagged as a zip file :-)

=20

On this issue I still agree with Russ. X.9 is going too far with this
X.509 field.

The purpose of this field is just to carry the public key and its
parameters.

The algorithm identifier serves to define what type of key and
parameters that are provided, not to define its usage.

=20

If we change this, I think we violate an important principle of X.509
which may open a whole can of worms for the future.

=20

A comparable situation would be (which has been proposed) if we instead
of just defining an RSA public key to be an RSA key, started to define
new identifiers with structured parameters that restricts the usage of
the key for e.g. signatures based on a certain rage of hash algorithms,
or key transport for certain symmetric algorithms. The list can be done
endless and so can the complexity.

=20

But this is not how we do things.

=20

The only reason I've seen so far why you may need to define different
algorithm identifiers for the same algorithm would be if a picking the
wrong algorithm mode would compromise the key or the expected level of
protection.

My understanding of this is that X.9 goes far beyond that.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Waterhouse, Richard
Sent: den 31 augusti 2006 18:53
To: Russ Housley; Robert Zuccherato
Cc: Daniel Brown; [email-masked]
Subject: RE: Elliptic Curve Cryptography with PKIX

=20

I liked the approach Mr Brown was proposing some time back though I
don't know where it stands today. I need to, for example, restrict a key
to be used with ECMQV. (I also need to, for example, inform the other
end that the key is based on the NIST p384 curve.)

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
	Sent: Thursday, August 31, 2006 10:48 AM
	To: Robert Zuccherato
	Cc: 'Daniel Brown'; [email-masked]
	Subject: RE: Elliptic Curve Cryptography with PKIX

	My opinion has not changed.  I believe that we need to follow
the precedent set by RFC 4055.
=09
	In my opinion, this situation is a result of the ANSI X9 process
not allowing public review of their draft documents.  However, I do not
expect this policy to change.
=09
	Russ
=09
	At 10:24 AM 8/31/2006, Robert Zuccherato wrote:
=09
=09
=09

	It's been more than a few months now since Russ posted this
message and I haven't seen any further discussion on the topic.  As I
said back in April, my preference would be for PKIX to use the
AlgorithmIdentifier in the already approved X9.62 standard, since I
don't think it is helpful to have more than one AlgorithmIdentifier
defined.
=09
	However, whatever we decide to do, I think that we should
resolve the issue and advance the draft as quickly as possible.
Developers of ECC applications need to know which AlgorithmIdentifier to
use. =20
=09
	Does anyone else have any opinions on this topic?  When can we
hope to see a new ID?=20
=09
	        Robert Zuccherato.=20
=09
	> -----Original Message-----=20
	> From: [email-masked]=20
	> [ mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Russ Housley=20
	> Sent: May 3, 2006 3:01 PM=20
	> To: [email-masked]=20
	> Subject: RE: Elliptic Curve Cryptography with PKIX=20
	>=20
	>=20
	>=20
	> RFC 3280 does not provide as much guidance as I would like.
Section=20
	> 4.1.2.7 says the following about the  Subject Public Key Info
field:=20
	>=20
	>     This field is used to carry the public key and identify=20
	> the algorithm=20
	>     with which the key is used (e.g., RSA, DSA, or=20
	> Diffie-Hellman).  The=20
	>     algorithm is identified using the AlgorithmIdentifier
structure=20
	>     specified in section 4.1.1.2.  The object identifiers for
the=20
	>     supported algorithms and the methods for encoding the
public key=20
	>     materials (public key and parameters) are specified in
[PKIXALGS].=20
	>=20
	> Section 4.1.1.2 includes these words:=20
	>=20
	>     The algorithm identifier is used to identify a
cryptographic=20
	>     algorithm.  The OBJECT IDENTIFIER component identifies=20
	> the algorithm=20
	>     (such as DSA with SHA-1).  The contents of the optional
parameters=20
	>     field will vary according to the algorithm identified.=20
	>=20
	> It does not really provide much guidance to developers of=20
	> AlgorithmIdentifiers.=20
	>=20
	> I characterize the X9.62 approach as using the OBJECT
IDENTIFIER to=20
	> name a class of elliptic curve algorithms, and then using a
portion=20
	> of the parameters to list the members of that class that are=20
	> acceptable for the subject public key.=20
	>=20
	> I am very interested to know how this fits with real
implementations.=20
	>=20
	> My suspicion is that implementation that support key agreement
are=20
	> used to looking into the parameter to determine if the public
key is=20
	> a member of the same group.  This is needed for static-static=20
	> Diffie-Hellman (in discrete log or elliptic curve).  This is
also=20
	> needed for MQV (and KEA, if anyone cares anymore).=20
	>=20
	> My suspicion is that digital signature validation does not
anticipate=20
	> constraints in the public key algorithm parameters.  An
underlying=20
	> crypto routine may need the parameters, but the signature is
not=20
	> going to fail because of a constraint in the parameters, which
could=20
	> happen in this proposed syntax.=20
	>=20
	> I would greatly appreciate some insight from implementors.=20
	>=20
	> Russ=20
	>=20

------_=_NextPart_001_01C6CDD6.86A08927
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>RE: Elliptic Curve Cryptography with PKIX</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>If people want to do that type of thing the mechanism =
defined for the purpose is an extension with the criticality bit =
set.<BR>
<BR>
There is no penalty in this particular case.<BR>
<BR>
Sent from my GoodLink Wireless Handheld (www.good.com)<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Stefan Santesson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<B=
R>
Sent:&nbsp;&nbsp; Friday, September 01, 2006 07:17 AM Pacific Standard =
Time<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Waterhouse, Richard; Russ Housley; Robert =
Zuccherato<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; Daniel Brown; [email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Elliptic Curve =
Cryptography with PKIX<BR>
<BR>
I noticed that this draft has expired (02 draft expired July 2006)<BR>
<BR>
<BR>
<BR>
I would appreciate if a new draft could be posted. And hopefully =
this<BR>
time not MIME tagged as a zip file :-)<BR>
<BR>
<BR>
<BR>
On this issue I still agree with Russ. X.9 is going too far with =
this<BR>
X.509 field.<BR>
<BR>
The purpose of this field is just to carry the public key and its<BR>
parameters.<BR>
<BR>
The algorithm identifier serves to define what type of key and<BR>
parameters that are provided, not to define its usage.<BR>
<BR>
<BR>
<BR>
If we change this, I think we violate an important principle of =
X.509<BR>
which may open a whole can of worms for the future.<BR>
<BR>
<BR>
<BR>
A comparable situation would be (which has been proposed) if we =
instead<BR>
of just defining an RSA public key to be an RSA key, started to =
define<BR>
new identifiers with structured parameters that restricts the usage =
of<BR>
the key for e.g. signatures based on a certain rage of hash =
algorithms,<BR>
or key transport for certain symmetric algorithms. The list can be =
done<BR>
endless and so can the complexity.<BR>
<BR>
<BR>
<BR>
But this is not how we do things.<BR>
<BR>
<BR>
<BR>
The only reason I've seen so far why you may need to define =
different<BR>
algorithm identifiers for the same algorithm would be if a picking =
the<BR>
wrong algorithm mode would compromise the key or the expected level =
of<BR>
protection.<BR>
<BR>
My understanding of this is that X.9 goes far beyond that.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
Stefan Santesson<BR>
<BR>
Senior Program Manager<BR>
<BR>
Windows Security, Standards<BR>
<BR>
________________________________<BR>
<BR>
From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]<BR>
On Behalf Of Waterhouse, Richard<BR>
Sent: den 31 augusti 2006 18:53<BR>
To: Russ Housley; Robert Zuccherato<BR>
Cc: Daniel Brown; [email-masked]<BR>
Subject: RE: Elliptic Curve Cryptography with PKIX<BR>
<BR>
<BR>
<BR>
I liked the approach Mr Brown was proposing some time back though I<BR>
don't know where it stands today. I need to, for example, restrict a =
key<BR>
to be used with ECMQV. (I also need to, for example, inform the =
other<BR>
end that the key is based on the NIST p384 curve.)<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -----Original =
Message-----<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: =
[email-masked]<BR>
[<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]On Behalf Of Russ Housley<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent: Thursday, August 31, =
2006 10:48 AM<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: Robert Zuccherato<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cc: 'Daniel Brown'; =
[email-masked]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject: RE: Elliptic Curve =
Cryptography with PKIX<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; My opinion has not =
changed.&nbsp; I believe that we need to follow<BR>
the precedent set by RFC 4055.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In my opinion, this situation =
is a result of the ANSI X9 process<BR>
not allowing public review of their draft documents.&nbsp; However, I do =
not<BR>
expect this policy to change.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Russ<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; At 10:24 AM 8/31/2006, Robert =
Zuccherato wrote:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It's been more than a few =
months now since Russ posted this<BR>
message and I haven't seen any further discussion on the topic.&nbsp; As =
I<BR>
said back in April, my preference would be for PKIX to use the<BR>
AlgorithmIdentifier in the already approved X9.62 standard, since I<BR>
don't think it is helpful to have more than one AlgorithmIdentifier<BR>
defined.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; However, whatever we decide =
to do, I think that we should<BR>
resolve the issue and advance the draft as quickly as possible.<BR>
Developers of ECC applications need to know which AlgorithmIdentifier =
to<BR>
use.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Does anyone else have any =
opinions on this topic?&nbsp; When can we<BR>
hope to see a new ID?<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Robert Zuccherato.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; -----Original =
Message-----<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; From: =
[email-masked]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; [ <A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A><BR>
&lt;<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>&gt; ] On Behalf Of Russ Housley<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Sent: May 3, 2006 3:01 =
PM<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; To: =
[email-masked]<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Subject: RE: Elliptic =
Curve Cryptography with PKIX<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; RFC 3280 does not =
provide as much guidance as I would like.<BR>
Section<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 4.1.2.7 says the =
following about the&nbsp; Subject Public Key Info<BR>
field:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
This field is used to carry the public key and identify<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; the algorithm<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
with which the key is used (e.g., RSA, DSA, or<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Diffie-Hellman).&nbsp; =
The<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
algorithm is identified using the AlgorithmIdentifier<BR>
structure<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
specified in section 4.1.1.2.&nbsp; The object identifiers for<BR>
the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
supported algorithms and the methods for encoding the<BR>
public key<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
materials (public key and parameters) are specified in<BR>
[PKIXALGS].<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Section 4.1.1.2 includes =
these words:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
The algorithm identifier is used to identify a<BR>
cryptographic<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
algorithm.&nbsp; The OBJECT IDENTIFIER component identifies<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; the algorithm<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
(such as DSA with SHA-1).&nbsp; The contents of the optional<BR>
parameters<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&nbsp;&nbsp;&nbsp;&nbsp; =
field will vary according to the algorithm identified.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; It does not really =
provide much guidance to developers of<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; =
AlgorithmIdentifiers.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; I characterize the X9.62 =
approach as using the OBJECT<BR>
IDENTIFIER to<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; name a class of elliptic =
curve algorithms, and then using a<BR>
portion<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; of the parameters to =
list the members of that class that are<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; acceptable for the =
subject public key.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; I am very interested to =
know how this fits with real<BR>
implementations.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; My suspicion is that =
implementation that support key agreement<BR>
are<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; used to looking into the =
parameter to determine if the public<BR>
key is<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; a member of the same =
group.&nbsp; This is needed for static-static<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Diffie-Hellman (in =
discrete log or elliptic curve).&nbsp; This is<BR>
also<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; needed for MQV (and KEA, =
if anyone cares anymore).<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; My suspicion is that =
digital signature validation does not<BR>
anticipate<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; constraints in the =
public key algorithm parameters.&nbsp; An<BR>
underlying<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; crypto routine may need =
the parameters, but the signature is<BR>
not<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; going to fail because of =
a constraint in the parameters, which<BR>
could<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; happen in this proposed =
syntax.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; I would greatly =
appreciate some insight from implementors.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; Russ<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6CDD6.86A08927--

To: "Stefan Santesson" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, [email-masked], "Waterhouse, Richard" <[email-masked]>, "Robert Zuccherato" <[email-masked]>
Subject: RE: Elliptic Curve Cryptography with PKIX
From: Daniel Brown <[email-masked]>
Date: Fri, 1 Sep 2006 10:03:43 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 004DAA81852571DC_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

"Stefan Santesson" <[email-masked]> wrote on 09/01/2006 08:14:23=20
AM:

> I noticed that this draft has expired (02 draft expired July 2006)
>=20
> I would appreciate if a new draft could be posted. And hopefully=20
> this time not MIME tagged as a zip file

I will post a new draft, and make a special request that it be correctly=20
MIME tagged as a text file.=20

>=20
> On this issue I still agree with Russ. X.9 is going too far with=20
> this X.509 field.
> The purpose of this field is just to carry the public key and its=20
parameters.
> The algorithm identifier serves to define what type of key and=20
> parameters that are provided, not to define its usage.
>=20
> If we change this, I think we violate an important principle of X.
> 509 which may open a whole can of worms for the future.
>=20
> A comparable situation would be (which has been proposed) if we=20
> instead of just defining an RSA public key to be an RSA key, started
> to define new identifiers with structured parameters that restricts=20
> the usage of the key for e.g. signatures based on a certain rage of=20
> hash algorithms, or key transport for certain symmetric algorithms.=20
> The list can be done endless and so can the complexity.
>=20
> But this is not how we do things.

I disagree, based on my understanding on RFC 4055, which is a standards=20
track.=20

PKIX defined new identifiers in RFC 4055 with parameters restricting the=20
use of a key.  The X9.62 syntax merely does the same thing, with the only=20
difference being that the parameters carry more of the information than in =

RFC 4055 (I had thought that this was the only sticking point, but=20
apparently there's a much larger issue).

Perhaps, you should ask the retract the MUSTs in RFC 4055 be restricted,=20
if you don't wish the subject public key info to have such binding=20
restrictions of algorithm usage.

>=20
> The only reason I?ve seen so far why you may need to define=20
> different algorithm identifiers for the same algorithm would be if a
> picking the wrong algorithm mode would compromise the key or the=20
> expected level of protection.

Correct.

> My understanding of this is that X.9 goes far beyond that.

How?  The X9 (and RFC 4055 syntax) provide an optional method to say, in a =

certificate, what "mode" of algorithm one would like one's certificate to=20
be used with.

        -- Dan

--=_alternative 004DAA81852571DC_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<br><tt><font size=3D2>&quot;Stefan Santesson&quot; &lt;[email-masked]=
om&gt;
wrote on 09/01/2006 08:14:23 AM:<br>
<br>
&gt; I noticed that this draft has expired (02 draft expired July 2006)</fo=
nt></tt>
<br><tt><font size=3D2>&gt; &nbsp;</font></tt>
<br><tt><font size=3D2>&gt; I would appreciate if a new draft could be post=
ed.
And hopefully <br>
&gt; this time not MIME tagged as a zip file</font></tt>
<br>
<br><tt><font size=3D2>I will post a new draft, and make a special request
that it be correctly MIME tagged as a text file. </font></tt>
<br>
<br><tt><font size=3D2>&gt; &nbsp;</font></tt>
<br><tt><font size=3D2>&gt; On this issue I still agree with Russ. X.9 is
going too far with <br>
&gt; this X.509 field.</font></tt>
<br><tt><font size=3D2>&gt; The purpose of this field is just to carry the
public key and its parameters.</font></tt>
<br><tt><font size=3D2>&gt; The algorithm identifier serves to define what
type of key and <br>
&gt; parameters that are provided, not to define its usage.</font></tt>
<br><tt><font size=3D2>&gt; &nbsp;</font></tt>
<br><tt><font size=3D2>&gt; If we change this, I think we violate an import=
ant
principle of X.<br>
&gt; 509 which may open a whole can of worms for the future.</font></tt>
<br><tt><font size=3D2>&gt; &nbsp;</font></tt>
<br><tt><font size=3D2>&gt; A comparable situation would be (which has been
proposed) if we <br>
&gt; instead of just defining an RSA public key to be an RSA key, started<b=
r>
&gt; to define new identifiers with structured parameters that restricts
<br>
&gt; the usage of the key for e.g. signatures based on a certain rage of
<br>
&gt; hash algorithms, or key transport for certain symmetric algorithms.
<br>
&gt; The list can be done endless and so can the complexity.</font></tt>
<br><tt><font size=3D2>&gt; &nbsp;</font></tt>
<br><tt><font size=3D2>&gt; But this is not how we do things.</font></tt>
<br>
<br><tt><font size=3D2>I disagree, based on my understanding on RFC 4055,
which is a standards track. &nbsp; </font></tt>
<br>
<br><tt><font size=3D2>PKIX defined new identifiers in RFC 4055 with parame=
ters
restricting the use of a key. &nbsp;The X9.62 syntax merely does the same
thing, with the only difference being that the parameters carry more of
the information than in RFC 4055 (I had thought that this was the only
sticking point, but apparently there's a much larger issue).</font></tt>
<br>
<br><tt><font size=3D2>Perhaps, you should ask the retract the MUSTs in RFC
4055 be restricted, if you don't wish the subject public key info to have
such binding restrictions of algorithm usage.</font></tt>
<br>
<br><tt><font size=3D2>&gt; &nbsp;</font></tt>
<br><tt><font size=3D2>&gt; The only reason I&#8217;ve seen so far why you =
may
need to define <br>
&gt; different algorithm identifiers for the same algorithm would be if
a<br>
&gt; picking the wrong algorithm mode would compromise the key or the <br>
&gt; expected level of protection.</font></tt>
<br>
<br><tt><font size=3D2>Correct.</font></tt>
<br>
<br><tt><font size=3D2>&gt; My understanding of this is that X.9 goes far
beyond that.</font></tt>
<br>
<br><tt><font size=3D2>How? &nbsp;The X9 (and RFC 4055 syntax) provide an
optional method to say, in a certificate, what &quot;mode&quot; of algorithm
one would like one's certificate to be used with.</font></tt>
<br>
<br><tt><font size=3D2>&nbsp; &nbsp; &nbsp; &nbsp; -- Dan</font></tt>
<br>
--=_alternative 004DAA81852571DC_=--

Content-class: urn:content-classes:message
Subject: RE: Elliptic Curve Cryptography with PKIX
Date: Fri, 1 Sep 2006 13:14:23 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Waterhouse, Richard" <[email-masked]>, "Russ Housley" <[email-masked]>, "Robert Zuccherato" <[email-masked]>
Cc: "Daniel Brown" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6CDC0.2AA45665
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I noticed that this draft has expired (02 draft expired July 2006)

=20

I would appreciate if a new draft could be posted. And hopefully this
time not MIME tagged as a zip file :-)

=20

On this issue I still agree with Russ. X.9 is going too far with this
X.509 field.

The purpose of this field is just to carry the public key and its
parameters.

The algorithm identifier serves to define what type of key and
parameters that are provided, not to define its usage.

=20

If we change this, I think we violate an important principle of X.509
which may open a whole can of worms for the future.

=20

A comparable situation would be (which has been proposed) if we instead
of just defining an RSA public key to be an RSA key, started to define
new identifiers with structured parameters that restricts the usage of
the key for e.g. signatures based on a certain rage of hash algorithms,
or key transport for certain symmetric algorithms. The list can be done
endless and so can the complexity.

=20

But this is not how we do things.

=20

The only reason I've seen so far why you may need to define different
algorithm identifiers for the same algorithm would be if a picking the
wrong algorithm mode would compromise the key or the expected level of
protection.

My understanding of this is that X.9 goes far beyond that.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Waterhouse, Richard
Sent: den 31 augusti 2006 18:53
To: Russ Housley; Robert Zuccherato
Cc: Daniel Brown; [email-masked]
Subject: RE: Elliptic Curve Cryptography with PKIX

=20

I liked the approach Mr Brown was proposing some time back though I
don't know where it stands today. I need to, for example, restrict a key
to be used with ECMQV. (I also need to, for example, inform the other
end that the key is based on the NIST p384 curve.)

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
	Sent: Thursday, August 31, 2006 10:48 AM
	To: Robert Zuccherato
	Cc: 'Daniel Brown'; [email-masked]
	Subject: RE: Elliptic Curve Cryptography with PKIX

	My opinion has not changed.  I believe that we need to follow
the precedent set by RFC 4055.
=09
	In my opinion, this situation is a result of the ANSI X9 process
not allowing public review of their draft documents.  However, I do not
expect this policy to change.
=09
	Russ
=09
	At 10:24 AM 8/31/2006, Robert Zuccherato wrote:
=09
=09
=09

	It's been more than a few months now since Russ posted this
message and I haven't seen any further discussion on the topic.  As I
said back in April, my preference would be for PKIX to use the
AlgorithmIdentifier in the already approved X9.62 standard, since I
don't think it is helpful to have more than one AlgorithmIdentifier
defined.
=09
	However, whatever we decide to do, I think that we should
resolve the issue and advance the draft as quickly as possible.
Developers of ECC applications need to know which AlgorithmIdentifier to
use. =20
=09
	Does anyone else have any opinions on this topic?  When can we
hope to see a new ID?=20
=09
	        Robert Zuccherato.=20
=09
	> -----Original Message-----=20
	> From: [email-masked]=20
	> [ mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Russ Housley=20
	> Sent: May 3, 2006 3:01 PM=20
	> To: [email-masked]=20
	> Subject: RE: Elliptic Curve Cryptography with PKIX=20
	>=20
	>=20
	>=20
	> RFC 3280 does not provide as much guidance as I would like.
Section=20
	> 4.1.2.7 says the following about the  Subject Public Key Info
field:=20
	>=20
	>     This field is used to carry the public key and identify=20
	> the algorithm=20
	>     with which the key is used (e.g., RSA, DSA, or=20
	> Diffie-Hellman).  The=20
	>     algorithm is identified using the AlgorithmIdentifier
structure=20
	>     specified in section 4.1.1.2.  The object identifiers for
the=20
	>     supported algorithms and the methods for encoding the
public key=20
	>     materials (public key and parameters) are specified in
[PKIXALGS].=20
	>=20
	> Section 4.1.1.2 includes these words:=20
	>=20
	>     The algorithm identifier is used to identify a
cryptographic=20
	>     algorithm.  The OBJECT IDENTIFIER component identifies=20
	> the algorithm=20
	>     (such as DSA with SHA-1).  The contents of the optional
parameters=20
	>     field will vary according to the algorithm identified.=20
	>=20
	> It does not really provide much guidance to developers of=20
	> AlgorithmIdentifiers.=20
	>=20
	> I characterize the X9.62 approach as using the OBJECT
IDENTIFIER to=20
	> name a class of elliptic curve algorithms, and then using a
portion=20
	> of the parameters to list the members of that class that are=20
	> acceptable for the subject public key.=20
	>=20
	> I am very interested to know how this fits with real
implementations.=20
	>=20
	> My suspicion is that implementation that support key agreement
are=20
	> used to looking into the parameter to determine if the public
key is=20
	> a member of the same group.  This is needed for static-static=20
	> Diffie-Hellman (in discrete log or elliptic curve).  This is
also=20
	> needed for MQV (and KEA, if anyone cares anymore).=20
	>=20
	> My suspicion is that digital signature validation does not
anticipate=20
	> constraints in the public key algorithm parameters.  An
underlying=20
	> crypto routine may need the parameters, but the signature is
not=20
	> going to fail because of a constraint in the parameters, which
could=20
	> happen in this proposed syntax.=20
	>=20
	> I would greatly appreciate some insight from implementors.=20
	>=20
	> Russ=20
	>=20

------_=_NextPart_001_01C6CDC0.2AA45665
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=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)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I noticed that this draft has =
expired (02
draft expired July 2006)<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I would appreciate if a new draft =
could be
posted. And hopefully this time not MIME tagged as a zip file =
</span></font><font
size=3D2 color=3Dnavy face=3DWingdings><span =
style=3D'font-size:10.0pt;font-family:
Wingdings;color:navy'>J</span></font><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span=
></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>On this issue I still agree with =
Russ. X.9
is going too far with this X.509 field.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The purpose of this field is just =
to carry
the public key and its parameters.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The algorithm identifier serves to =
define
what type of key and parameters that are provided, not to define its =
usage.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>If we change this, I think we =
violate an
important principle of X.509 which may open a whole can of worms for the =
future.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>A comparable situation would be =
(which has
been proposed) if we instead of just defining an RSA public key to be an =
RSA
key, started to define new identifiers with structured parameters that =
restricts
the usage of the key for e.g. signatures based on a certain rage of hash
algorithms, or key transport for certain symmetric algorithms. The list =
can be
done endless and so can the complexity.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>But this is not how we do =
things.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The only reason I&#8217;ve seen so =
far why
you may need to define different algorithm identifiers for the same =
algorithm would
be if a picking the wrong algorithm mode would compromise the key or the
expected level of protection.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>My understanding of this is that =
X.9 goes
far beyond that.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Waterhouse, =
Richard<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 31 augusti 2006 =
18:53<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Russ Housley; Robert
Zuccherato<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Daniel Brown;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Elliptic =
Curve
Cryptography with PKIX</span></font><o:p></o:p></p>

</div>

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

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I liked the approach Mr Brown was
proposing some time back though&nbsp;I don't know where it stands today. =
I need
to, for example, restrict a key to be used with ECMQV. (I also need to, =
for
example, inform the other end that the key is&nbsp;based on&nbsp;the =
NIST p384
curve.)</span></font><o:p></o:p></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]]<b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Russ Housley<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, August =
31, 2006
10:48 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Robert Zuccherato<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> 'Daniel Brown';
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Elliptic =
Curve
Cryptography with PKIX</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>My opinion has not changed.&nbsp; I believe that we need to =
follow the
precedent set by RFC 4055.<br>
<br>
In my opinion, this situation is a result of the ANSI X9 process not =
allowing
public review of their draft documents.&nbsp; However, I do not expect =
this
policy to change.<br>
<br>
Russ<br>
<br>
At 10:24 AM 8/31/2006, Robert Zuccherato wrote:<br>
<br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>It's been more than a few months now since Russ posted this =
message and
I haven't seen any further discussion on the topic.&nbsp; As I said back =
in
April, my preference would be for PKIX to use the AlgorithmIdentifier in =
the
already approved X9.62 standard, since I don't think it is helpful to =
have more
than one AlgorithmIdentifier defined.<br>
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>However, whatever we =
decide to do,
I think that we should resolve the issue and advance the draft as =
quickly as
possible.&nbsp; Developers of ECC applications need to know which
AlgorithmIdentifier to use.&nbsp; <br>
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>Does anyone else have =
any opinions
on this topic?&nbsp; When can we hope to see a new ID?</span></font> =
<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size=3D2><span =
style=3D'font-size:
10.0pt'>Robert Zuccherato.</span></font> <br>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; -----Original =
Message-----</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; From:
[email-masked] </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; [<a
href=3D"mailto:[email-masked]"> =
mailto:[email-masked]</a>]
On Behalf Of Russ Housley</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Sent: May 3, 2006 =
3:01 PM</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To: =
[email-masked]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Subject: RE: =
Elliptic Curve
Cryptography with PKIX</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; RFC 3280 does not =
provide as
much guidance as I would like.&nbsp; Section </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; 4.1.2.7 says the =
following
about the&nbsp; Subject Public Key Info field:</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This
field is used to carry the public key and identify </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the =
algorithm</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; with
which the key is used (e.g., RSA, DSA, or </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
Diffie-Hellman).&nbsp; The</span></font>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;
algorithm is identified using the AlgorithmIdentifier =
structure</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;
specified in section 4.1.1.2.&nbsp; The object identifiers for =
the</span></font>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;
supported algorithms and the methods for encoding the public =
key</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;
materials (public key and parameters) are specified in =
[PKIXALGS].</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Section 4.1.1.2 =
includes these
words:</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The
algorithm identifier is used to identify a cryptographic</span></font> =
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; algorithm.&nbsp;
The OBJECT IDENTIFIER component identifies </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the =
algorithm</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; (such
as DSA with SHA-1).&nbsp; The contents of the optional =
parameters</span></font>
<br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp; field
will vary according to the algorithm identified.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; It does not really =
provide
much guidance to developers of </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
AlgorithmIdentifiers.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I characterize the =
X9.62
approach as using the OBJECT IDENTIFIER to </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; name a class of =
elliptic curve
algorithms, and then using a portion </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; of the parameters =
to list the
members of that class that are </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; acceptable for the =
subject
public key.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I am very =
interested to know
how this fits with real implementations.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; My suspicion is =
that
implementation that support key agreement are </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; used to looking =
into the
parameter to determine if the public key is </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; a member of the =
same
group.&nbsp; This is needed for static-static </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Diffie-Hellman (in =
discrete
log or elliptic curve).&nbsp; This is also </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; needed for MQV (and =
KEA, if
anyone cares anymore).</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; My suspicion is =
that digital
signature validation does not anticipate </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; constraints in the =
public key
algorithm parameters.&nbsp; An underlying </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; crypto routine may =
need the
parameters, but the signature is not </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; going to fail =
because of a
constraint in the parameters, which could </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; happen in this =
proposed
syntax.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I would greatly =
appreciate
some insight from implementors.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Russ</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
</span></font><o:p></o:p></p>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C6CDC0.2AA45665--