Re: TimeStampToken mime type?

[Alicia da Conceicao <[e-mail]>]

> Hi Alicia, you're quite right, the corresponding MIME type is missing
> and is required in order to use time stamps properly. In our software,
> our TSP client keeps a copy of the entire TSP response, which is not
> optimal since the status info is not used for further validation. I
> think the underlying problem is that there isn't yet a widespread use of
> time stamps in applications (digital signature for instance), especially
> in the US. RFC 3126 is an informational document, whereas it is a
> standard in Europe (the ETSI technical equivalent). The LTANS group is
> the place to look for standards and guidelines to use time stamps for
> long term digitally signed documents. 
> I think we don't have an official standard for a stand alone
> TimeStampToken.

Hi Miguel:

If I am not mistaken, ISO-18014-2 Time Stamping Tokens with digital
signatures fully interop with RFC-3161 TimeStampTokens.  Does
ISO-18014-2 specify any MIME type for their tokens?  If so, we should
use it.

If not, then what can I do to get offical PKIX support for the new
TimeStampToken MIME type?

	application/timestamp-token            .tst

It would be overkill to draft a new RFC just for a MIME type, so
what can we do instead to make sure that it becomes a standard.

Alicia.

PS. On a side note, I have deployed TSA (Time Stamping Authorities)
	in Canada and Malaysia with my CertEngine TimeTrust system,
	so I am very interested in promoting cryptographic time
	stamp usage, especially when used with digital signatures.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3U9ta7h083974; Sat, 30 Apr 2005 02:55:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3U9taHO083973; Sat, 30 Apr 2005 02:55:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eevee.engine.ca (gate1.engine.ca [207.188.86.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3U9tZPv083953 for <[e-mail]>; Sat, 30 Apr 2005 02:55:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from alicia@localhost) by eevee.engine.ca (8.11.3nb1/8.6.12) id j3U9tvS18353; Sat, 30 Apr 2005 05:55:57 -0400 (EDT)
From: Alicia da Conceicao <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: TimeStampToken mime type?
To: [e-mail] (Miguel A Rodriguez)
Date: Sat, 30 Apr 2005 05:55:56 -0400 (EDT)
Cc: [e-mail]
In-Reply-To: <000001c54cce$ee72ebd0$[e-mail]> from "Miguel A Rodriguez" at Apr 29, 2005 10:20:09 AM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi Alicia, you're quite right, the corresponding MIME type is missing
> and is required in order to use time stamps properly. In our software,
> our TSP client keeps a copy of the entire TSP response, which is not
> optimal since the status info is not used for further validation. I
> think the underlying problem is that there isn't yet a widespread use of
> time stamps in applications (digital signature for instance), especially
> in the US. RFC 3126 is an informational document, whereas it is a
> standard in Europe (the ETSI technical equivalent). The LTANS group is
> the place to look for standards and guidelines to use time stamps for
> long term digitally signed documents. 
> I think we don't have an official standard for a stand alone
> TimeStampToken.

Hi Miguel:

If I am not mistaken, ISO-18014-2 Time Stamping Tokens with digital
signatures fully interop with RFC-3161 TimeStampTokens.  Does
ISO-18014-2 specify any MIME type for their tokens?  If so, we should
use it.

If not, then what can I do to get offical PKIX support for the new
TimeStampToken MIME type?

	application/timestamp-token            .tst

It would be overkill to draft a new RFC just for a MIME type, so
what can we do instead to make sure that it becomes a standard.

Alicia.

PS. On a side note, I have deployed TSA (Time Stamping Authorities)
	in Canada and Malaysia with my CertEngine TimeTrust system,
	so I am very interested in promoting cryptographic time
	stamp usage, especially when used with digital signatures.



Received: from 208.184.76.43 ([71.11.132.15]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3THqodd044620; Fri, 29 Apr 2005 10:53:02 -0700 (PDT) (envelope-from [e-mail])
X-Message-Info: QaNFS0gvSmZTFct96YVQzo247+NVjqq960yD
Received: from ivtfruo314.bigfoot.com (122.184.62.120) by xqg9-fhx0.bigfoot.com with Microsoft SMTPSVC(5.0.2195.6824); Sat, 30 Apr 2005 00:49:59 +0600
Received: from Richiemir4uhw456ynl746jvs (127.52.12.127) by hosogqeyprl743.bigfoot.com (InterMail vM.5.01.06.05 293-084-804-420-557-577295) with SMTP id <14151336853445.OZX167.jzlfw18005.bigfoot.com@viscountura472tjm595xf817ktk> for <[e-mail]>; Fri, 29 Apr 2005 20:46:59 +0200
Message-ID: <4396fln809n19$27175$yar8iol217@Richiepln352j24x084g>
From: "Antone Belanger" <[e-mail]>
To: <[e-mail]>
Subject: Acquire softs for nearly no monney! dee
Date: Fri, 29 Apr 2005 12:45:59 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--epbupze857416cotoqye"

----epbupze857416cotoqye
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit

Tons of cool soft. at incredibly low pr1ces!
just try not to laugh when you see the funny pr1ces :)

just to show you:
Adobe - Photoshop 7, Premiere 7, Illustrator 10 - just 120 dolars!
Macromedia Dreamwaver MX 2004 + Flash MX 2004 - only 100 dolars!
Windows XP Professional+Microsoft Office XP Professional -  80 dolars!!

hmmm take me now!:
http://borosilicate.linchidmch.com/?6R8aEhDemGJl5C6controvertible

p.s. ofers are valid till May, 15
Stock's limited.

Also:    
Windows 2003 Server
Windows 2000 Workstation    
Windows 2000 Advanced Server
Windows NT 4.0
Office XP Professional  
Office 2000  
MS Plus      
MS Visual Studio .NET Architect Edition 
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Picture It Premium 9 
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker   
Adobe Acrobat 6 Professional
Macromedia Dreamwaver MX 2004               
Macromedia Flash MX 2004                               
Macromedia Fireworks MX 2004                               
Macromedia Freehand MX 11            
Corel Draw (all ver's)                                        
Corel Photo Painter 8                                   
Corel Word Perfect Office 2002                                                        
Borland Delphi 7 Enterprise Edition                 
Quark Xpress 6 Passport Multilanguage 

and more...


finally get up when my stomach threatens to strangle me by coiling my intestines around my neck due to lack of coffee and food.
the old scandinavian sagas were written down in iceland snorri sturluson a nobleman historian and poet writes or is believed to have written the.
yaaaaaaaaaaaaaaaaaay we are all lame ass losers now hehe im writting shit on my own guest book lol ok well bye!
so put your pants on like a real man and identify yourself because i am not hiding behind an alias or a fictitious name i am what i am signing no more no less take it or leave it ok?
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 buscador.
i found your webbsite an the los angeles public library genealogy link initially no one in particular-later my husband was curious about bobby flay foodtv com.
metasphere net offers premium web hosting flash communication server hosting and application development custome web software desing flash design and database integration.
er no that s another entry all together but depending on who i thought about during umm wink wink nudge nudge i could say that i was a lot devastated by.
who the hell do you think you are to judge people like that? whats worse is youre generalising in the most small minded way possible just because the majority of us who.
ancient american history great american traditions civilizations investigationinto individual tribes north american civilizations meso american.
nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp name nbsp nbsp nbsp nbsp nbsp jeimy acosta.
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 buscador.
christine gatsby and carrie includes pictures news schedule plus family and vacation photos.
jazz and blues vocalist based in london site includes biography news gig dates and recording information.

----epbupze857416cotoqye--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TH3ej1037217; Fri, 29 Apr 2005 10:03:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3TH3ew2037216; Fri, 29 Apr 2005 10:03:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TH3aoj037196 for <[e-mail]>; Fri, 29 Apr 2005 10:03:37 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Fri, 29 Apr 2005 18:03:30 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Fri, 29 Apr 2005 18:03:30 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on <draft-ietf-pkix-crlaia-00.txt>
Thread-Index: AcVMjbxlXXuyd8E3RNG1T0zQD/yKqwAAca5Q
From: "Stefan Santesson" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 29 Apr 2005 17:03:30.0454 (UTC) FILETIME=[5E5CA360:01C54CDD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3TH3boj037204
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks Russ,

Since my quote in previous mail got hidden way back in my in-line
response, I add it also to this mail for completeness.

RFC 3280, Section 6.3.3 CRL processing - states on page 85: 

   (f)  Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's
   certificate, verify that the cRLSign bit is set.

   (g)  Validate the signature on the complete CRL using the public key
   validated in step (f).



Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: den 29 april 2005 09:26
> To: Denis Pinkas; Stefan Santesson
> Cc: pkix
> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> Here is a quote from RFC 3280.  To me, it is clear that a CRL issuer
has a
> certificate.  Obviously, all certificates need to be validated, which
> includes certification path construction and certification path
> validation.
> 
> 5.1.1.3  signatureValue
> 
>     The signatureValue field contains a digital signature computed
upon
>     the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded
tbsCertList
>     is used as the input to the signature function.  This signature
value
>     is encoded as a BIT STRING and included in the CRL signatureValue
>     field.  The details of this process are specified for each of the
>     supported algorithms in [PKIXALGS].
> 
>     CAs that are also CRL issuers MAY use one private key to digitally
>     sign certificates and CRLs, or MAY use separate private keys to
>     digitally sign certificates and CRLs.  When separate private keys
are
>     employed, each of the public keys associated with these private
keys
>     is placed in a separate certificate, one with the keyCertSign bit
set
>     in the key usage extension, and one with the cRLSign bit set in
the
>     key usage extension (section 4.2.1.3).  When separate private keys
>     are employed, certificates issued by the CA contain one authority
key
>     identifier, and the corresponding CRLs contain a different
authority
>     key identifier.  The use of separate CA certificates for
validation
>     of certificate signatures and CRL signatures can offer improved
>     security characteristics; however, it imposes a burden on
>     applications, and it might limit interoperability.  Many
applications
>     construct a certification path, and then validate the
certification
>     path (section 6).  CRL checking in turn requires a separate
>     certification path to be constructed and validated for the CA's
CRL
>     signature validation certificate.  Applications that perform CRL
>     checking MUST support certification path validation when
certificates
>     and CRLs are digitally signed with the same CA private key.  These
>     applications SHOULD support certification path validation when
>     certificates and CRLs are digitally signed with different CA
private
>     keys.
> 
> Russ
> 
> At 01:12 PM 4/28/2005, Denis Pinkas wrote:
> >Stefan and Russ,
> >
> >>Denis,
> >
> >>Russ and I have taken a thorough look at your text proposal and we
have
> >>edited a counter proposal where we try to meet your needs as much as
> >>possible without compromising what we think is the core purpose of
the
> >>draft (to enable certificate discovery bottom-up).
> >
> >>The conclusion is that we suggest changes to the introduction
section
> >>but we keep the old security considerations intact.
> >
> >I would suggest that a merge would need to be done between the "old"
> >security considerations section and the "new" one.
> >
> >The "old" security considerations section is mentionning a solution
which
> >does NOT suppress the problem, but minimize the risk only in case the
CAs
> >are really "honest".
> >
> >The old" security considerations section does not provide a solution
in
> >case the name collsion between two CRL issuer name is deliberate,
whereas
> >the "new" security considerations section provides a secure solution
in
> >one case and clearly mentions that all other cases are dependant
about
> >"zillions" of *local* trust conditions which cannot all be
standardized.
> >
> >The main purpose of a security considerations section is to provide
the
> >adequate warnings and solutions when they exist and not to hide the
> problems.
> >
> >>That is not because
> >>we necessarily disagree with all of the statements in your proposal,
but
> >>in the cases we don't, we still think it is out of scope for this
work.
> >
> >This is clearly within the scope of a security considerations
section.
> >
> >>The new introduction proposal based on your input is:
> >>--------------------------------------------------------------
> >>RFC 3280 [PKIX1] specifies the validation of certification paths.
One
> >>aspect involves the determination that a certificate has not been
> >>revoked, and one revocation checking mechanism is the Certificate
> >>Revocation List (CRL).  CRL validation is also specified in RFC
3280,
> >
> >I would love this last sentence to be true but the reality is that:
> >"CRL validation is NOT specified in RFC 3280". :-(
> >
> >>which involves the constructions of a valid certification path for
the
> >>CRL issuer.
> >
> >There is no such a statement in RFC 3280.
> >
> >>Building a CRL issuer certification path from the signer of
> >
> >There is no notion of "CRL issuer certification path" in RFC 3280.
> >The primary requirement is to make sure that the CRL issuer
designated by
> >the CA is indeed the right one. In some (but not all) cases, I mean
among
> >the zillion of cases, there MAY be a need to construct a CRL issuer
> >certification path.
> >
> >>the CRL to a trust anchor is straightforward when the certificate of
the
> >>CRL issuer is present in the certification path associated with the
> >>target certificate, but it can be complex in other situations.
> >
> > From the comments above, you can see that I cannot agree with the
above
> > revised text. The remaining of the text is acceptable in general,
but
> > could possibly be slightly revised to be more in continuation with
the
> > changes there are needed above (i.e. it is not cast in concrete).
> >
> >Denis
> >
> >>There are several legitimate scenarios where the certificate of the
CRL
> >>issuer is not present, or easily discovered, from the target
> >>certification path.  This can be the case when indirect CRLs are
used,
> >>when the certification Authority (CA) that issued the target
certificate
> >>changes its certificate signing key, or when the CA employs separate
> >>keys for certificate signing and CRL signing.
> >>Methods of finding the certificate of the CRL issuer are currently
> >>available, such as though an accessible directory location or
through
> >>use of the Subject Information Access extension in intermediary CA
> >>certificates.
> >>Directory lookup requires existence and access to a directory that
has
> >>been populated with all of the necessary certificates.  The Subject
> >>Information Access extension, which supports building the CRL issuer
> >>certification path top-down (in the direction from the trust anchor
to
> >>the CRL issuer), requires that some certificates in the CRL issuer
> >>certification path includes an appropriate Subject Information
Access
> >>extension.
> >>RFC 3280 [PKIX1] provides for bottom-up discovery of certification
paths
> >>through the Authority Information Access extension, where the
> >>id-ad-caIssuers access method may specify one or more accessLocation
> >>fields that reference CA certificates associated with the
certificate
> >>containing this extension.
> >>This document enables the use of the Authority Information Access
> >>extension in CRLs, enabling a CRL checking application to use the
access
> >>method (id-ad-caIssuers) to locate certificates that may be useful
in
> >>the construction of a valid CRL issuer certification path to an
> >>appropriate trust anchor.
> >>
> >>Stefan Santesson
> >>Program Manager, Standards Liaison
> >>Windows Security
> >>
> >>
> >>>-----Original Message-----
> >>>From: Denis Pinkas [mailto:[e-mail]]
> >>>Sent: den 18 april 2005 13:41
> >>>To: Stefan Santesson
> >>>Cc: Russ Housley; pkix
> >>>Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> >>>
> >>>Stefan,
> >>>
> >>>
> >>>>Denis,
> >>>
> >>>>I will come back and comment on your text proposals, but before
> >>that,
> >>
> >>> > a few questions/comments:
> >>>
> >>>
> >>>><snip>
> >>>
> >>>>>>You point out some well known issues related to the lack of
> >>absolute
> >>
> >>>>>>cryptographic binding between CRL and certificates where the
> >>>>>>certificate and CRL is not signed by the same key.
> >>>>>
> >>>>>Not really. It is indeed possible to have an absolute
cryptographic
> >>>>>binding between CRL and certificates where the certificate and
CRL
> >>is
> >>
> >>>not
> >>>
> >>>>>signed by the same key, but the key point is that proposed
> >>extension
> >>
> >>> >> is *not* the means to provide such a binding (and you agree
with
> >>this
> >>
> >>> >> further down in this e-mail).
> >>>
> >>>
> >>>>We agree that this extension does not add to the concept of
> >>>>cryptographic binding. But how do you mean it can be done?
> >>>
> >>>Would this mean that you believed this could not be done ? :-)
> >>>
> >>>I already provided the information, but since at that time you were
> >>>focussing on another issue, you probably missed the point.
> >>>
> >>>I would encourage you to read again that thread, but I will provide
a
> >>>short
> >>>reply here to your question.
> >>>
> >>>This can be done using cRLIssuer from the CRL DP. cRLIssuer
contains
> >>the
> >>
> >>>DN
> >>>of the CRL Issuer and we all know that CAs are free to assign the
DNs
> >>they
> >>
> >>>wish. The next point is for a verifier to make sure that the DN
which
> >>>identifies the CRL Issuer (in the CRL DP) is indeed the one that
was
> >>meant
> >>
> >>>by the CA. The CRL must be issued by a CRL Issuer that has the same
> >>DN.
> >>
> >>>The
> >>>CRL Issuer will have a certificate issued by a CA.
> >>>
> >>>Case a): the CA that has issued that certificate is the same as the
CA
> >>>that
> >>>has issued the target certificate (which contains the hereabove
> >>mentionned
> >>
> >>>CRL DP). This is easy to check for a verifier since the verifier
must
> >>>first
> >>>build the certification path and then test the revocation status of
> >>every
> >>
> >>>element of the path. So the verifier knows the validated sequence
of
> >>DNs
> >>
> >>>starting from a self-signed certificate. It must then use the same
> >>>sequence
> >>>of DNs to validate the CRL Issuer certificate.
> >>>
> >>>This is a general rule which does not require any extra local trust
> >>>information.
> >>>
> >>>Case b) : the CA that has issued that certificate is NOT the same
as
> >>the
> >>
> >>>CA
> >>>that has issued the target certificate. This case requires extra
> >>*0local*
> >>
> >>>trust information. There are many such trust conditions possible
and
> >>thus
> >>
> >>>this cannot be defined in general. Cases a) and b) are thus not
> >>equivalent
> >>
> >>>and have to be distinguished.
> >>>
> >>>
> >>>><snip>
> >>>
> >>>>>>This draft only introduces a new way to locate certificates
> >>>>>>that can be helpful in building this path.
> >>>>>
> >>>>>At least one sentence of which we both agree !
> >>>>>It should be copied and pasted in the abstract.
> >>>>
> >>>>Good, then I suggest that we leave unrelated topics out of this
> >>draft
> >>
> >>>>and focus on the issues that are related to this limited scope.
> >>>
> >>>This is what I did in my proposal, except that we need to have a
> >>security
> >>
> >>>considerations section and the goal of that section is not to hide
> >>>problems
> >>>but to correctly warn users. Thus why an informatiove annex on the
> >>topics
> >>
> >>>mentionned in the security considerations section would be quite
> >>useful.
> >>
> >>>In fact, its content would be along the lines of the explanations
> >>which
> >>
> >>>are
> >>>just above.
> >>>
> >>>I hope this e-mail will help us to progress.
> >>>
> >>>Denis
> >>>
> >>>
> >>>>Stefan Santesson
> >>>>Program Manager - Standards Liaison
> >>>>Windows Security
> >
> >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TFN9S9020491; Fri, 29 Apr 2005 08:23:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3TFN9Qn020490; Fri, 29 Apr 2005 08:23:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [200.53.113.210] (mail.seguridata.com [200.53.113.210]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3TFN7I7020465 for <[e-mail]>; Fri, 29 Apr 2005 08:23:07 -0700 (PDT) (envelope-from [e-mail])
Received: from no.name.available by [200.53.113.210] via smtpd (for www.imc.org [208.184.76.42]) with SMTP; Fri, 29 Apr 2005 10:21:29 -0600
Received: from miguel2 ([192.168.0.214]) by mail.seguridata.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 10:24:20 -0500
From: "Miguel A Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: RE: TimeStampToken mime type?
Date: Fri, 29 Apr 2005 10:20:09 -0500
Message-ID: <000001c54cce$ee72ebd0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 29 Apr 2005 15:24:20.0413 (UTC) FILETIME=[83DC6ED0:01C54CCF]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Alicia, you're quite right, the corresponding MIME type is missing
and is required in order to use time stamps properly. In our software,
our TSP client keeps a copy of the entire TSP response, which is not
optimal since the status info is not used for further validation. I
think the underlying problem is that there isn't yet a widespread use of
time stamps in applications (digital signature for instance), especially
in the US. RFC 3126 is an informational document, whereas it is a
standard in Europe (the ETSI technical equivalent). The LTANS group is
the place to look for standards and guidelines to use time stamps for
long term digitally signed documents. 
I think we don't have an official standard for a stand alone
TimeStampToken.

Miguel
 

-----Original Message-----
From: Alicia da Conceicao [mailto:[e-mail]] 
Sent: Thursday, April 28, 2005 6:15 PM
To: Miguel A Rodriguez
Cc: [e-mail]
Subject: Re: TimeStampToken mime type?


> The entire TSP response is
> TimeStampResp ::= SEQUENCE  {
>      status                  PKIStatusInfo,
>      timeStampToken          TimeStampToken     OPTIONAL  }
> In think you're supposed to send the whole thing (the token plus the 
> status info) and hence the MIME type, when using the TSP protocol. 
> When it comes to using or storing an already acquired time stamp, some

> specs (like RFC 3126) refer to the time stamp token as part of a 
> bigger CMS-type structure. Maybe you can find some info in the LTANS 
> group (also in IETF).

Hi Miguel:

My Time Stamping Authority does indeed submit the entire TSR
(TimeStampResp) to each Time Stamping Client.  However, after validation
of the entire TSR by the client, the client extracts the TST
(TimeStampToken) from the TSR and saves just that token in a file.  It
does this, since the TST is just a type of CMS signedData structure, and
since the PKIStatusInfo in the TSR only carries information about if the
TSQ (TimeStampReq) was successful or not, or if it was unsuccessful, why
it failed:

	PKIStatusInfo ::= SEQUENCE {
	      status        PKIStatus,
	      statusString  PKIFreeText     OPTIONAL,
	      failInfo      PKIFailureInfo  OPTIONAL  }

In other words, all successful TSR typically just have a PKIStatusInfo
with only status==0 or in some rare cases status==1, and optional
failedInfo==NULL and statusString== NULL or statusString==some
unimportant string like "OK".  For any TCR the time stamping client
receives, the client only outputs the PKIStatusInfo temporarily in
message/status window, and archives the actual TST (TimeStampToken)
extracted from any succussful TSR in a perminate database or file.

These days, many modern Operating Systems use file managers that are
MIME aware.  Think Win32 Explorer, KDE, Gnome, MacOSX- Aqua, etc.  And
these MIME aware file managers need a common filename extension and MIME
type for any extracted TimeStampToken, which is why I have been using:

 	application/timestamp-token            .tst

in my own time stamping software, in light of the fact that there does
not appear to be any offical standard.

Alicia.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> On Behalf Of Alicia da Conceicao
> Sent: Thursday, April 28, 2005 10:58 AM
> To: [e-mail]
> Subject: TimeStampToken mime type?
> 
> Greetings:
> 
> RFC-3161 provides the following MIME types and associated
> extensions:
> 
> 	application/timestamp-query            .tsq
> 	application/timestamp-reply            .tsr
> 
> But it does not appear to provide anything for the actual time stamp 
> token, which is a CMS signed-data structure extracted from the time 
> stamp response.  I have done some searching online and did not find 
> any mime standards for the time stamp token.  Does anyone know of any?
> 
> If not, then I propose that we use the following:
> 
> 	application/timestamp-token            .tst
> 
> as the offical standard.  Comments???
> 
> Alicia.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3T7Q0rN039662; Fri, 29 Apr 2005 00:26:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3T7Q0hB039661; Fri, 29 Apr 2005 00:26:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3T7PuTh039612 for <[e-mail]>; Fri, 29 Apr 2005 00:25:57 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 25504 invoked by uid 0); 29 Apr 2005 07:25:44 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (212.147.29.57) by woodstock.binhost.com with SMTP; 29 Apr 2005 07:25:44 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Fri, 29 Apr 2005 03:25:47 -0400
To: Denis Pinkas <[e-mail]>, Stefan Santesson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Cc: pkix <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here is a quote from RFC 3280.  To me, it is clear that a CRL issuer has a 
certificate.  Obviously, all certificates need to be validated, which 
includes certification path construction and certification path validation.

5.1.1.3  signatureValue

    The signatureValue field contains a digital signature computed upon
    the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded tbsCertList
    is used as the input to the signature function.  This signature value
    is encoded as a BIT STRING and included in the CRL signatureValue
    field.  The details of this process are specified for each of the
    supported algorithms in [PKIXALGS].

    CAs that are also CRL issuers MAY use one private key to digitally
    sign certificates and CRLs, or MAY use separate private keys to
    digitally sign certificates and CRLs.  When separate private keys are
    employed, each of the public keys associated with these private keys
    is placed in a separate certificate, one with the keyCertSign bit set
    in the key usage extension, and one with the cRLSign bit set in the
    key usage extension (section 4.2.1.3).  When separate private keys
    are employed, certificates issued by the CA contain one authority key
    identifier, and the corresponding CRLs contain a different authority
    key identifier.  The use of separate CA certificates for validation
    of certificate signatures and CRL signatures can offer improved
    security characteristics; however, it imposes a burden on
    applications, and it might limit interoperability.  Many applications
    construct a certification path, and then validate the certification
    path (section 6).  CRL checking in turn requires a separate
    certification path to be constructed and validated for the CA's CRL
    signature validation certificate.  Applications that perform CRL
    checking MUST support certification path validation when certificates
    and CRLs are digitally signed with the same CA private key.  These
    applications SHOULD support certification path validation when
    certificates and CRLs are digitally signed with different CA private
    keys.

Russ

At 01:12 PM 4/28/2005, Denis Pinkas wrote:
>Stefan and Russ,
>
>>Denis,
>
>>Russ and I have taken a thorough look at your text proposal and we have
>>edited a counter proposal where we try to meet your needs as much as
>>possible without compromising what we think is the core purpose of the
>>draft (to enable certificate discovery bottom-up).
>
>>The conclusion is that we suggest changes to the introduction section
>>but we keep the old security considerations intact.
>
>I would suggest that a merge would need to be done between the "old" 
>security considerations section and the "new" one.
>
>The "old" security considerations section is mentionning a solution which 
>does NOT suppress the problem, but minimize the risk only in case the CAs 
>are really "honest".
>
>The old" security considerations section does not provide a solution in 
>case the name collsion between two CRL issuer name is deliberate, whereas 
>the "new" security considerations section provides a secure solution in 
>one case and clearly mentions that all other cases are dependant about 
>"zillions" of *local* trust conditions which cannot all be standardized.
>
>The main purpose of a security considerations section is to provide the 
>adequate warnings and solutions when they exist and not to hide the problems.
>
>>That is not because
>>we necessarily disagree with all of the statements in your proposal, but
>>in the cases we don't, we still think it is out of scope for this work.
>
>This is clearly within the scope of a security considerations section.
>
>>The new introduction proposal based on your input is:
>>--------------------------------------------------------------
>>RFC 3280 [PKIX1] specifies the validation of certification paths.  One
>>aspect involves the determination that a certificate has not been
>>revoked, and one revocation checking mechanism is the Certificate
>>Revocation List (CRL).  CRL validation is also specified in RFC 3280,
>
>I would love this last sentence to be true but the reality is that:
>"CRL validation is NOT specified in RFC 3280". :-(
>
>>which involves the constructions of a valid certification path for the
>>CRL issuer.
>
>There is no such a statement in RFC 3280.
>
>>Building a CRL issuer certification path from the signer of
>
>There is no notion of "CRL issuer certification path" in RFC 3280.
>The primary requirement is to make sure that the CRL issuer designated by 
>the CA is indeed the right one. In some (but not all) cases, I mean among 
>the zillion of cases, there MAY be a need to construct a CRL issuer 
>certification path.
>
>>the CRL to a trust anchor is straightforward when the certificate of the
>>CRL issuer is present in the certification path associated with the
>>target certificate, but it can be complex in other situations.
>
> From the comments above, you can see that I cannot agree with the above 
> revised text. The remaining of the text is acceptable in general, but 
> could possibly be slightly revised to be more in continuation with the 
> changes there are needed above (i.e. it is not cast in concrete).
>
>Denis
>
>>There are several legitimate scenarios where the certificate of the CRL
>>issuer is not present, or easily discovered, from the target
>>certification path.  This can be the case when indirect CRLs are used,
>>when the certification Authority (CA) that issued the target certificate
>>changes its certificate signing key, or when the CA employs separate
>>keys for certificate signing and CRL signing.
>>Methods of finding the certificate of the CRL issuer are currently
>>available, such as though an accessible directory location or through
>>use of the Subject Information Access extension in intermediary CA
>>certificates.
>>Directory lookup requires existence and access to a directory that has
>>been populated with all of the necessary certificates.  The Subject
>>Information Access extension, which supports building the CRL issuer
>>certification path top-down (in the direction from the trust anchor to
>>the CRL issuer), requires that some certificates in the CRL issuer
>>certification path includes an appropriate Subject Information Access
>>extension.
>>RFC 3280 [PKIX1] provides for bottom-up discovery of certification paths
>>through the Authority Information Access extension, where the
>>id-ad-caIssuers access method may specify one or more accessLocation
>>fields that reference CA certificates associated with the certificate
>>containing this extension.
>>This document enables the use of the Authority Information Access
>>extension in CRLs, enabling a CRL checking application to use the access
>>method (id-ad-caIssuers) to locate certificates that may be useful in
>>the construction of a valid CRL issuer certification path to an
>>appropriate trust anchor.
>>
>>Stefan Santesson
>>Program Manager, Standards Liaison
>>Windows Security
>>
>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[e-mail]]
>>>Sent: den 18 april 2005 13:41
>>>To: Stefan Santesson
>>>Cc: Russ Housley; pkix
>>>Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
>>>
>>>Stefan,
>>>
>>>
>>>>Denis,
>>>
>>>>I will come back and comment on your text proposals, but before
>>that,
>>
>>> > a few questions/comments:
>>>
>>>
>>>><snip>
>>>
>>>>>>You point out some well known issues related to the lack of
>>absolute
>>
>>>>>>cryptographic binding between CRL and certificates where the
>>>>>>certificate and CRL is not signed by the same key.
>>>>>
>>>>>Not really. It is indeed possible to have an absolute cryptographic
>>>>>binding between CRL and certificates where the certificate and CRL
>>is
>>
>>>not
>>>
>>>>>signed by the same key, but the key point is that proposed
>>extension
>>
>>> >> is *not* the means to provide such a binding (and you agree with
>>this
>>
>>> >> further down in this e-mail).
>>>
>>>
>>>>We agree that this extension does not add to the concept of
>>>>cryptographic binding. But how do you mean it can be done?
>>>
>>>Would this mean that you believed this could not be done ? :-)
>>>
>>>I already provided the information, but since at that time you were
>>>focussing on another issue, you probably missed the point.
>>>
>>>I would encourage you to read again that thread, but I will provide a
>>>short
>>>reply here to your question.
>>>
>>>This can be done using cRLIssuer from the CRL DP. cRLIssuer contains
>>the
>>
>>>DN
>>>of the CRL Issuer and we all know that CAs are free to assign the DNs
>>they
>>
>>>wish. The next point is for a verifier to make sure that the DN which
>>>identifies the CRL Issuer (in the CRL DP) is indeed the one that was
>>meant
>>
>>>by the CA. The CRL must be issued by a CRL Issuer that has the same
>>DN.
>>
>>>The
>>>CRL Issuer will have a certificate issued by a CA.
>>>
>>>Case a): the CA that has issued that certificate is the same as the CA
>>>that
>>>has issued the target certificate (which contains the hereabove
>>mentionned
>>
>>>CRL DP). This is easy to check for a verifier since the verifier must
>>>first
>>>build the certification path and then test the revocation status of
>>every
>>
>>>element of the path. So the verifier knows the validated sequence of
>>DNs
>>
>>>starting from a self-signed certificate. It must then use the same
>>>sequence
>>>of DNs to validate the CRL Issuer certificate.
>>>
>>>This is a general rule which does not require any extra local trust
>>>information.
>>>
>>>Case b) : the CA that has issued that certificate is NOT the same as
>>the
>>
>>>CA
>>>that has issued the target certificate. This case requires extra
>>*0local*
>>
>>>trust information. There are many such trust conditions possible and
>>thus
>>
>>>this cannot be defined in general. Cases a) and b) are thus not
>>equivalent
>>
>>>and have to be distinguished.
>>>
>>>
>>>><snip>
>>>
>>>>>>This draft only introduces a new way to locate certificates
>>>>>>that can be helpful in building this path.
>>>>>
>>>>>At least one sentence of which we both agree !
>>>>>It should be copied and pasted in the abstract.
>>>>
>>>>Good, then I suggest that we leave unrelated topics out of this
>>draft
>>
>>>>and focus on the issues that are related to this limited scope.
>>>
>>>This is what I did in my proposal, except that we need to have a
>>security
>>
>>>considerations section and the goal of that section is not to hide
>>>problems
>>>but to correctly warn users. Thus why an informatiove annex on the
>>topics
>>
>>>mentionned in the security considerations section would be quite
>>useful.
>>
>>>In fact, its content would be along the lines of the explanations
>>which
>>
>>>are
>>>just above.
>>>
>>>I hope this e-mail will help us to progress.
>>>
>>>Denis
>>>
>>>
>>>>Stefan Santesson
>>>>Program Manager - Standards Liaison
>>>>Windows Security
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3T60keL009737; Thu, 28 Apr 2005 23:00:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3T60kKX009735; Thu, 28 Apr 2005 23:00:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eevee.engine.ca (gate1.engine.ca [207.188.86.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3T60jY8009724 for <[e-mail]>; Thu, 28 Apr 2005 23:00:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from alicia@localhost) by eevee.engine.ca (8.11.3nb1/8.6.12) id j3SNEY526881; Thu, 28 Apr 2005 19:14:34 -0400 (EDT)
From: Alicia da Conceicao <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: TimeStampToken mime type?
To: [e-mail] (Miguel A Rodriguez)
Date: Thu, 28 Apr 2005 19:14:33 -0400 (EDT)
Cc: [e-mail]
In-Reply-To: <000001c54c1d$41033920$[e-mail]> from "Miguel A Rodriguez" at Apr 28, 2005 01:08:17 PM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<<< No Message Collected >>>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3T5cUL1098117; Thu, 28 Apr 2005 22:38:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3T5cUih098116; Thu, 28 Apr 2005 22:38:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gate1.engine.ca (gate1.engine.ca [207.188.86.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3T5cTlQ098105 for <[e-mail]>; Thu, 28 Apr 2005 22:38:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from alicia@localhost) by eevee.engine.ca (8.11.3nb1/8.6.12) id j3SNEY526881; Thu, 28 Apr 2005 19:14:34 -0400 (EDT)
From: Alicia da Conceicao <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: TimeStampToken mime type?
To: [e-mail] (Miguel A Rodriguez)
Date: Thu, 28 Apr 2005 19:14:33 -0400 (EDT)
Cc: [e-mail]
In-Reply-To: <000001c54c1d$41033920$[e-mail]> from "Miguel A Rodriguez" at Apr 28, 2005 01:08:17 PM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> The entire TSP response is
> TimeStampResp ::= SEQUENCE  {
>      status                  PKIStatusInfo,
>      timeStampToken          TimeStampToken     OPTIONAL  }
> In think you're supposed to send the whole thing (the token plus the
> status info) and hence the MIME type, when using the TSP protocol. When
> it comes to using or storing an already acquired time stamp, some specs
> (like RFC 3126) refer to the time stamp token as part of a bigger
> CMS-type structure. Maybe you can find some info in the LTANS group
> (also in IETF).

Hi Miguel:

My Time Stamping Authority does indeed submit the entire TSR
(TimeStampResp) to each Time Stamping Client.  However, after
validation of the entire TSR by the client, the client extracts
the TST (TimeStampToken) from the TSR and saves just that token
in a file.  It does this, since the TST is just a type of CMS
signedData structure, and since the PKIStatusInfo in the TSR
only carries information about if the TSQ (TimeStampReq) was
successful or not, or if it was unsuccessful, why it failed:

	PKIStatusInfo ::= SEQUENCE {
	      status        PKIStatus,
	      statusString  PKIFreeText     OPTIONAL,
	      failInfo      PKIFailureInfo  OPTIONAL  }

In other words, all successful TSR typically just have a
PKIStatusInfo with only status==0 or in some rare cases
status==1, and optional failedInfo==NULL and statusString==
NULL or statusString==some unimportant string like "OK".  For
any TCR the time stamping client receives, the client only
outputs the PKIStatusInfo temporarily in message/status
window, and archives the actual TST (TimeStampToken) extracted
from any succussful TSR in a perminate database or file.

These days, many modern Operating Systems use file managers
that are MIME aware.  Think Win32 Explorer, KDE, Gnome, MacOSX-
Aqua, etc.  And these MIME aware file managers need a common
filename extension and MIME type for any extracted
TimeStampToken, which is why I have been using:

 	application/timestamp-token            .tst

in my own time stamping software, in light of the fact that
there does not appear to be any offical standard.

Alicia.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Alicia da Conceicao
> Sent: Thursday, April 28, 2005 10:58 AM
> To: [e-mail]
> Subject: TimeStampToken mime type?
> 
> Greetings:
> 
> RFC-3161 provides the following MIME types and associated
> extensions:
> 
> 	application/timestamp-query            .tsq
> 	application/timestamp-reply            .tsr
> 
> But it does not appear to provide anything for the actual time stamp
> token, which is a CMS signed-data structure extracted from the time
> stamp response.  I have done some searching online and did not find any
> mime standards for the time stamp token.  Does anyone know of any?
> 
> If not, then I propose that we use the following:
> 
> 	application/timestamp-token            .tst
> 
> as the offical standard.  Comments???
> 
> Alicia.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SN3jH5026724; Thu, 28 Apr 2005 16:03:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SN3jFT026723; Thu, 28 Apr 2005 16:03:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SN3eig026710 for <[e-mail]>; Thu, 28 Apr 2005 16:03:41 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 00:03:35 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Fri, 29 Apr 2005 00:03:33 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on <draft-ietf-pkix-crlaia-00.txt>
Thread-Index: AcVMFYgIi0dPB8mQRlqZbh31S8CQxwALQdpw
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 28 Apr 2005 23:03:35.0144 (UTC) FILETIME=[8158F680:01C54C46]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3SN3fig026715
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments in line;


Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 28 april 2005 19:12
> To: Stefan Santesson; Russ Housley
> Cc: pkix
> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> Stefan and Russ,
> 
> > Denis,
> 
> > Russ and I have taken a thorough look at your text proposal and we
have
> > edited a counter proposal where we try to meet your needs as much as
> > possible without compromising what we think is the core purpose of
the
> > draft (to enable certificate discovery bottom-up).
> 
> > The conclusion is that we suggest changes to the introduction
section
> > but we keep the old security considerations intact.
> 
> I would suggest that a merge would need to be done between the "old"
> security considerations section and the "new" one.
> 
> The "old" security considerations section is mentionning a solution
which
> does NOT suppress the problem, but minimize the risk only in case the
CAs
> are really "honest".
> 
> The old" security considerations section does not provide a solution
in
> case
> the name collsion between two CRL issuer name is deliberate, whereas
the
> "new" security considerations section provides a secure solution in
one
> case
> and clearly mentions that all other cases are dependant about
"zillions"
> of
> *local* trust conditions which cannot all be standardized.
> 
> The main purpose of a security considerations section is to provide
the
> adequate warnings and solutions when they exist and not to hide the
> problems.
> 
[Stefan] But it has to provide a warning to something that is introduced
by the standard. This standard does not introduce the concept of CRL
signature checking or CRL issuer certificate validation, so that is
clearly out of scope. More about that below;

> > That is not because
> > we necessarily disagree with all of the statements in your proposal,
but
> > in the cases we don't, we still think it is out of scope for this
work.
> 
> This is clearly within the scope of a security considerations section.
> 
> > The new introduction proposal based on your input is:
> > --------------------------------------------------------------
> >
> > RFC 3280 [PKIX1] specifies the validation of certification paths.
One
> > aspect involves the determination that a certificate has not been
> > revoked, and one revocation checking mechanism is the Certificate
> > Revocation List (CRL).  CRL validation is also specified in RFC
3280,
> 
> I would love this last sentence to be true but the reality is that:
> "CRL validation is NOT specified in RFC 3280". :-(
> 
[Stefan] In fact it is.

RFC 3280, Section 6.3.3 CRL processing - on page 85: 

   (f)  Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's
   certificate, verify that the cRLSign bit is set.

   (g)  Validate the signature on the complete CRL using the public key
   validated in step (f).



> > which involves the constructions of a valid certification path for
the
> > CRL issuer.
> 
> There is no such a statement in RFC 3280.
> 
[Stefan] See above

> > Building a CRL issuer certification path from the signer of
> 
> There is no notion of "CRL issuer certification path" in RFC 3280.
> The primary requirement is to make sure that the CRL issuer designated
by
> the CA is indeed the right one. In some (but not all) cases, I mean
among
> the zillion of cases, there MAY be a need to construct a CRL issuer
> certification path.

[Stefan] Again - look in section 6.3.3 
> 
> > the CRL to a trust anchor is straightforward when the certificate of
the
> > CRL issuer is present in the certification path associated with the
> > target certificate, but it can be complex in other situations.
> 
>  From the comments above, you can see that I cannot agree with the
above
> revised text. The remaining of the text is acceptable in general, but
> could
> possibly be slightly revised to be more in continuation with the
changes
> there are needed above (i.e. it is not cast in concrete).
> 
[Stefan] It is my hope that the provided responses here can help
convince you to change your mind about that. If it doesn't I still argue
that the place to specify requirements and security considerations for
CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft.

/Stefan

> Denis
> 
> > There are several legitimate scenarios where the certificate of the
CRL
> > issuer is not present, or easily discovered, from the target
> > certification path.  This can be the case when indirect CRLs are
used,
> > when the certification Authority (CA) that issued the target
certificate
> > changes its certificate signing key, or when the CA employs separate
> > keys for certificate signing and CRL signing.
> >
> > Methods of finding the certificate of the CRL issuer are currently
> > available, such as though an accessible directory location or
through
> > use of the Subject Information Access extension in intermediary CA
> > certificates.
> >
> > Directory lookup requires existence and access to a directory that
has
> > been populated with all of the necessary certificates.  The Subject
> > Information Access extension, which supports building the CRL issuer
> > certification path top-down (in the direction from the trust anchor
to
> > the CRL issuer), requires that some certificates in the CRL issuer
> > certification path includes an appropriate Subject Information
Access
> > extension.
> >
> > RFC 3280 [PKIX1] provides for bottom-up discovery of certification
paths
> > through the Authority Information Access extension, where the
> > id-ad-caIssuers access method may specify one or more accessLocation
> > fields that reference CA certificates associated with the
certificate
> > containing this extension.
> >
> > This document enables the use of the Authority Information Access
> > extension in CRLs, enabling a CRL checking application to use the
access
> > method (id-ad-caIssuers) to locate certificates that may be useful
in
> > the construction of a valid CRL issuer certification path to an
> > appropriate trust anchor.
> >
> >
> >
> > Stefan Santesson
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> >
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[e-mail]]
> >>Sent: den 18 april 2005 13:41
> >>To: Stefan Santesson
> >>Cc: Russ Housley; pkix
> >>Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> >>
> >>Stefan,
> >>
> >>
> >>>Denis,
> >>
> >>>I will come back and comment on your text proposals, but before
> >>
> > that,
> >
> >> > a few questions/comments:
> >>
> >>
> >>><snip>
> >>
> >>>>>You point out some well known issues related to the lack of
> >>>>
> > absolute
> >
> >>>>>cryptographic binding between CRL and certificates where the
> >>>>>certificate and CRL is not signed by the same key.
> >>>>
> >>>>Not really. It is indeed possible to have an absolute
cryptographic
> >>>>binding between CRL and certificates where the certificate and CRL
> >>>
> > is
> >
> >>not
> >>
> >>>>signed by the same key, but the key point is that proposed
> >>>
> > extension
> >
> >> >> is *not* the means to provide such a binding (and you agree with
> >
> > this
> >
> >> >> further down in this e-mail).
> >>
> >>
> >>>We agree that this extension does not add to the concept of
> >>>cryptographic binding. But how do you mean it can be done?
> >>
> >>Would this mean that you believed this could not be done ? :-)
> >>
> >>I already provided the information, but since at that time you were
> >>focussing on another issue, you probably missed the point.
> >>
> >>I would encourage you to read again that thread, but I will provide
a
> >>short
> >>reply here to your question.
> >>
> >>This can be done using cRLIssuer from the CRL DP. cRLIssuer contains
> >
> > the
> >
> >>DN
> >>of the CRL Issuer and we all know that CAs are free to assign the
DNs
> >
> > they
> >
> >>wish. The next point is for a verifier to make sure that the DN
which
> >>identifies the CRL Issuer (in the CRL DP) is indeed the one that was
> >
> > meant
> >
> >>by the CA. The CRL must be issued by a CRL Issuer that has the same
> >
> > DN.
> >
> >>The
> >>CRL Issuer will have a certificate issued by a CA.
> >>
> >>Case a): the CA that has issued that certificate is the same as the
CA
> >>that
> >>has issued the target certificate (which contains the hereabove
> >
> > mentionned
> >
> >>CRL DP). This is easy to check for a verifier since the verifier
must
> >>first
> >>build the certification path and then test the revocation status of
> >
> > every
> >
> >>element of the path. So the verifier knows the validated sequence of
> >
> > DNs
> >
> >>starting from a self-signed certificate. It must then use the same
> >>sequence
> >>of DNs to validate the CRL Issuer certificate.
> >>
> >>This is a general rule which does not require any extra local trust
> >>information.
> >>
> >>Case b) : the CA that has issued that certificate is NOT the same as
> >
> > the
> >
> >>CA
> >>that has issued the target certificate. This case requires extra
> >
> > *0local*
> >
> >>trust information. There are many such trust conditions possible and
> >
> > thus
> >
> >>this cannot be defined in general. Cases a) and b) are thus not
> >
> > equivalent
> >
> >>and have to be distinguished.
> >>
> >>
> >>><snip>
> >>
> >>>>>This draft only introduces a new way to locate certificates
> >>>>>that can be helpful in building this path.
> >>>>
> >>>>At least one sentence of which we both agree !
> >>>>It should be copied and pasted in the abstract.
> >>>
> >>>Good, then I suggest that we leave unrelated topics out of this
> >>
> > draft
> >
> >>>and focus on the issues that are related to this limited scope.
> >>
> >>This is what I did in my proposal, except that we need to have a
> >
> > security
> >
> >>considerations section and the goal of that section is not to hide
> >>problems
> >>but to correctly warn users. Thus why an informatiove annex on the
> >
> > topics
> >
> >>mentionned in the security considerations section would be quite
> >
> > useful.
> >
> >>In fact, its content would be along the lines of the explanations
> >
> > which
> >
> >>are
> >>just above.
> >>
> >>I hope this e-mail will help us to progress.
> >>
> >>Denis
> >>
> >>
> >>>Stefan Santesson
> >>>Program Manager - Standards Liaison
> >>>Windows Security
> >>
> >
> >
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SIRx2T079362; Thu, 28 Apr 2005 11:27:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SIRxjN079361; Thu, 28 Apr 2005 11:27:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SIRwWr079354 for <[e-mail]>; Thu, 28 Apr 2005 11:27:58 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j3SIRQDZ017500; Thu, 28 Apr 2005 14:27:27 -0400
Received: from othello.nist.gov (othello.ncsl.nist.gov [129.6.54.41]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j3SIR49r003002; Thu, 28 Apr 2005 14:27:04 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Thu, 28 Apr 2005 14:25:22 -0400
To: [e-mail]
From: Shu-jen Chang <[e-mail]>
Subject: Cryptographic Hash Workshop - Call for Participation
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_14969562==_"
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=====================_14969562==_
Content-Type: multipart/alternative;
	boundary="=====================_14969562==.ALT"

--=====================_14969562==.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Cryptographic Hash Workshop
NIST Gaithersburg, MD (Green Auditorium)
Oct. 31-Nov. 1, 2005
Submission Deadline: July 15, 2005 (Workshop without Proceedings)

Recently a team of researchers reported that the SHA-1 function offers=20
significantly less collision resistance than could be expected from a=20
cryptographic hash function of its output size.  NIST plans to host a=20
Cryptographic Hash Workshop on Oct. 31-Nov. 1, 2005 to solicit public input=
=20
in how best to respond to the current state of research in this area.  The=
=20
workshop has the following goals:

=B7       Assess the status of the current NIST-approved hash functions,=20
i.e., the SHA-256 and SHA-512 families in        addition to SHA-1;
=B7       Discuss short term actions to mitigate the potential problems with=
=20
the various applications of the approved     hash functions;
=B7       Discuss the conditions that would warrant an early transition away=
=20
from any of the approved hash functions;
=B7       Discuss the potential replacement options for any of the approved=
=20
hash functions;
=B7       Clarify the properties of unkeyed cryptographic hash functions=20
required for different applications such as      digital signatures, key=20
derivation, message authentication, and random number generation.

NIST solicits papers, presentations, case studies, panel proposals, and=20
participation from any interested parties, including researchers, systems=20
architects, vendors, and users.  NIST will post the accepted papers and=20
presentations on the workshop web site and include these in a workshop=20
handout. However, no formal workshop proceedings will be published. NIST=20
encourages presentations and reports on preliminary work that participants=
=20
plan to publish elsewhere. Topics for submissions are included in the=20
attached document, and details about the workshop will be available at the=
=20
following web site shortly: http://www.nist.gov/hash-function


Shu-jen Chang
Computer Security Division
NIST

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

<html>
<font face=3D"Times New Roman, Times" size=3D4>Cryptographic Hash
Workshop<br>
NIST Gaithersburg, MD (Green Auditorium)<br>
Oct. 31-Nov. 1, 2005<br>
<b>Submission Deadline:
</font><font face=3D"Times New Roman, Times" size=3D4 color=3D"#231F20">July
15, 2005 (Workshop without Proceedings)<br><br>
</b></font><font face=3D"Times New Roman, Times" size=3D4>Recently a team of
researchers reported that the SHA-1 function offers significantly less
collision resistance than could be expected from a cryptographic hash
function of its output size.&nbsp; NIST plans to host a Cryptographic
Hash Workshop on Oct. 31-Nov. 1, 2005 to solicit public input in how best
to respond to the current state of research in this area.&nbsp; The
workshop has the following goals:<br><br>
</font><font face=3D"Symbol"=
 size=3D4>=B7<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font=
><font face=3D"Times New Roman, Times" size=3D4>Assess
the status of the current NIST-approved hash functions, i.e., the SHA-256
and SHA-512 families in
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>addition to
SHA-1;<br>
</font><font face=3D"Symbol"=
 size=3D4>=B7<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font=
><font face=3D"Times New Roman, Times" size=3D4>Discuss
short term actions to mitigate the potential problems with the various
applications of the approved <x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>hash
functions;<br>
</font><font face=3D"Symbol"=
 size=3D4>=B7<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font=
><font face=3D"Times New Roman, Times" size=3D4>Discuss
the conditions that would warrant an early transition away from any of
the approved hash functions;<br>
</font><font face=3D"Symbol"=
 size=3D4>=B7<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font=
><font face=3D"Times New Roman, Times" size=3D4>Discuss
the potential replacement options for any of the approved hash
functions;<br>
</font><font face=3D"Symbol"=
 size=3D4>=B7<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font=
><font face=3D"Times New Roman, Times" size=3D4>Clarify
the properties of unkeyed cryptographic hash functions required for
different applications such as
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>digital signatures, key
derivation, message authentication, and random number
generation.<br><br>
NIST solicits papers, presentations, case studies, panel proposals, and
participation from any interested parties, including researchers, systems
architects, vendors, and users.&nbsp; NIST will post the accepted papers
and presentations on the workshop web site and include these in a
workshop handout. However, no formal workshop proceedings will be
published. NIST encourages presentations and reports on preliminary work
that participants plan to publish elsewhere. Topics for submissions are
included in the attached document, and details about the workshop will be
available at the following web site shortly:
</font><a href=3D"http://www.nist.gov/hash-function" eudora=3D"autourl"><fon=
t face=3D"Times New Roman, Times" size=3D4=
 color=3D"#0000FF"><u>http://www.nist.gov/hash-function</a><br><br>
<br>
</u></font><font face=3D"Times New Roman, Times" size=3D4>Shu-jen Chang<br>
Computer Security Division<br>
NIST<br>
</font></html>

--=====================_14969562==.ALT--

--=====================_14969562==_
Content-Type: application/pdf; name="Cryptographic Hash Workshop CFP.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Cryptographic Hash Workshop CFP.pdf"

JVBERi0xLjQNJeLjz9MNCjEzOSAwIG9iajw8L0hbODExIDIzN10vTGluZWFyaXplZCAxL0UgMTg4
NzQvTCAzMTAxMC9OIDIvTyAxNDIvVCAyODE4Mj4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAg
DQp4cmVmDQoxMzkgMjUNCjAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMTIyNSAwMDAwMCBuDQow
MDAwMDAwODExIDAwMDAwIG4NCjAwMDAwMDE0NjEgMDAwMDAgbg0KMDAwMDAwMTc4MCAwMDAwMCBu
DQowMDAwMDAyNDU3IDAwMDAwIG4NCjAwMDAwMDI4ODQgMDAwMDAgbg0KMDAwMDAwMjkyMCAwMDAw
MCBuDQowMDAwMDAzMTYwIDAwMDAwIG4NCjAwMDAwMDM0MDYgMDAwMDAgbg0KMDAwMDAwMzQ4MyAw
MDAwMCBuDQowMDAwMDA0MTI2IDAwMDAwIG4NCjAwMDAwMDQyNTkgMDAwMDAgbg0KMDAwMDAwNDU1
NyAwMDAwMCBuDQowMDAwMDA1MjQyIDAwMDAwIG4NCjAwMDAwMDU4MjIgMDAwMDAgbg0KMDAwMDAw
NjQ3NSAwMDAwMCBuDQowMDAwMDA3MDIyIDAwMDAwIG4NCjAwMDAwMDc1NTMgMDAwMDAgbg0KMDAw
MDAwODE2OSAwMDAwMCBuDQowMDAwMDA4NzA3IDAwMDAwIG4NCjAwMDAwMTEzNzcgMDAwMDAgbg0K
MDAwMDAxODQ1MSAwMDAwMCBuDQowMDAwMDE4NjgyIDAwMDAwIG4NCjAwMDAwMDEwNDggMDAwMDAg
bg0KdHJhaWxlcg0KPDwvU2l6ZSAxNjQvUHJldiAyODE3MC9YUmVmU3RtIDEwNDgvUm9vdCAxNDAg
MCBSL0luZm8gMTIgMCBSL0lEWzwyMzI0ZmU4NTdhZWQ5MjQ0MzgwYmM4YjAwNDhkZTU5Mz48ZTBj
ZDgzYmU2MTk3NWM0Y2E1NjVjOGMxOGEzZTczMzE+XT4+DQpzdGFydHhyZWYNCjANCiUlRU9GDQog
ICAgICAgICAgICANCjE0MSAwIG9iajw8L0xlbmd0aCAxNTAvRmlsdGVyL0ZsYXRlRGVjb2RlL0Mg
MTU4L0wgMTQyL1MgNzc+PnN0cmVhbQ0KeNpiYGBgZmBgOcHAysDAmc3Ax4AAfAwsQFEWBo4JDK8y
GBjOQYUZJ2g6rgl0C17qAOQIdnQASSaNjg6QEiBgYWAIsgDSokAsDhZRYeDluLHAGWhyGrMHq1I8
M4djq5ASo0n7H9tHLvybJm37w2Pgx1DAvwBiPAcDQ3QFyEwgBhnExsAQLAnhc8SDadatDgABBgAg
Zhr6DQplbmRzdHJlYW0NZW5kb2JqDTE2MyAwIG9iajw8L1NpemUgMTM5L0xlbmd0aCAyNy9GaWx0
ZXIvRmxhdGVEZWNvZGUvRGVjb2RlUGFybXM8PC9Db2x1bW5zIDMvUHJlZGljdG9yIDEyPj4vV1sx
IDEgMV0vVHlwZS9YUmVmL0luZGV4WzEzIDEyNl0+PnN0cmVhbQ0KeNpiYmJjYGJgYBzFgwUzzqWH
PQABBgDDSAIfDQplbmRzdHJlYW0NZW5kb2JqDTE0MCAwIG9iajw8L1BhZ2VzIDEwIDAgUi9UeXBl
L0NhdGFsb2cvUGFnZUxhYmVscyA4IDAgUi9TdHJ1Y3RUcmVlUm9vdCAxMyAwIFIvTWV0YWRhdGEg
MTEgMCBSL1BpZWNlSW5mbzw8L01hcmtlZFBERjw8L0xhc3RNb2RpZmllZChEOjIwMDUwNDI4MTEx
NTUyKT4+Pj4vTGFzdE1vZGlmaWVkKEQ6MjAwNTA0MjgxMTE1NTIpL01hcmtJbmZvPDwvTWFya2Vk
IHRydWUvTGV0dGVyc3BhY2VGbGFncyAwPj4+Pg1lbmRvYmoNMTQyIDAgb2JqPDwvQ29udGVudHNb
MTQ5IDAgUiAxNTIgMCBSIDE1MyAwIFIgMTU0IDAgUiAxNTUgMCBSIDE1NiAwIFIgMTU3IDAgUiAx
NTggMCBSXS9UeXBlL1BhZ2UvUGFyZW50IDEwIDAgUi9Sb3RhdGUgMC9NZWRpYUJveFswIDAgNjEy
IDc5Ml0vQ3JvcEJveFswIDAgNjEyIDc5Ml0vUmVzb3VyY2VzPDwvQ29sb3JTcGFjZTw8L0NTMCAx
NDUgMCBSPj4vRm9udDw8L1RUMCAxNDMgMCBSL1RUMSAxNDQgMCBSL0MyXzAgMTUwIDAgUj4+L1By
b2NTZXRbL1BERi9UZXh0XS9FeHRHU3RhdGU8PC9HUzAgMTQ4IDAgUj4+Pj4vU3RydWN0UGFyZW50
cyAwPj4NZW5kb2JqDTE0MyAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9XaW5BbnNpRW5jb2Rp
bmcvQmFzZUZvbnQvVGltZXNOZXdSb21hblBTTVQvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDIyOS9T
dWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDE0NiAwIFIvV2lkdGhzWzI1MCAwIDQwOCAw
IDAgMCAwIDAgMzMzIDMzMyAwIDAgMjUwIDMzMyAyNTAgMjc4IDUwMCA1MDAgNTAwIDUwMCAwIDUw
MCA1MDAgMCA1MDAgMCAyNzggMjc4IDAgMCAwIDQ0NCAwIDcyMiAwIDY2NyA3MjIgNjExIDU1NiA3
MjIgNzIyIDMzMyAwIDAgNjExIDg4OSA3MjIgNzIyIDU1NiAwIDY2NyA1NTYgNjExIDcyMiAwIDk0
NCAwIDAgMCAwIDAgMCAwIDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAw
IDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAg
NTAwIDQ0NCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ0NF0+Pg1l
bmRvYmoNMTQ0IDAgb2JqPDwvVHlwZS9Gb250L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9CYXNl
Rm9udC9UaW1lc05ld1JvbWFuUFMtQm9sZE1UL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjEvU3Vi
dHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAxNDcgMCBSL1dpZHRoc1syNTAgMCAwIDAgMCAw
IDAgMCAzMzMgMzMzIDAgMCAyNTAgMzMzIDI1MCAwIDUwMCA1MDAgNTAwIDUwMCAwIDUwMCAwIDAg
MCAwIDMzMyAwIDAgMCAwIDAgOTMwIDcyMiAwIDAgNzIyIDAgMCAwIDAgMCA1MDAgMCAwIDAgNzIy
IDAgNjExIDAgMCA1NTYgMCAwIDAgMTAwMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgNTU2IDQ0NCA1
NTYgNDQ0IDMzMyA1MDAgNTU2IDI3OCAwIDU1NiAyNzggODMzIDU1NiA1MDAgNTU2IDAgNDQ0IDM4
OSAzMzMgNTU2IDUwMCA3MjIgMCA1MDBdPj4NZW5kb2JqDTE0NSAwIG9ialsvSUNDQmFzZWQgMTU5
IDAgUl0NZW5kb2JqDTE0NiAwIG9iajw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udEJCb3hbLTU2
OCAtMzA3IDIwMDAgMTAwN10vRm9udE5hbWUvVGltZXNOZXdSb21hblBTTVQvRmxhZ3MgMzQvU3Rl
bVYgODIvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IDAvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvSXRh
bGljQW5nbGUgMC9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvRm9udFN0cmV0Y2gvTm9ybWFs
L0ZvbnRXZWlnaHQgNDAwPj4NZW5kb2JqDTE0NyAwIG9iajw8L1R5cGUvRm9udERlc2NyaXB0b3Iv
Rm9udEJCb3hbLTU1OCAtMzA3IDIwMDAgMTAyNl0vRm9udE5hbWUvVGltZXNOZXdSb21hblBTLUJv
bGRNVC9GbGFncyAzNC9TdGVtViAxMzYvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IDAvQXNjZW50IDg5
MS9EZXNjZW50IC0yMTYvSXRhbGljQW5nbGUgMC9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikv
Rm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNzAwPj4NZW5kb2JqDTE0OCAwIG9iajw8L1R5
cGUvRXh0R1N0YXRlL1NBIGZhbHNlL09QIGZhbHNlL1NNIDAuMDIvb3AgZmFsc2UvT1BNIDE+Pg1l
bmRvYmoNMTQ5IDAgb2JqPDwvTGVuZ3RoIDU3My9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0K
SImMVF1vmzAUfedX3EcjFccGDHiqKrVJ1Q+p3bQg7WHZAzEm8UZxZMO67tfPdtpGlRJpQoJry5xz
7j0HZl/g/Hz2ML9bAIGLi6vFHKLZfElAWLfhL7BiiCgot3/j9jc2uqqjWV0ToFB3EcGEUFcJ8BXJ
XPns36otUOKff92qNm6BeRUA9xUnUBKOK8Y5h/op+o7m5iVOSrSLkxSNcYH0xjS7rXKVgNvGbuGb
Nr/sVu8g/lHfR9d1dP3g1R46oG8dfFB4hLngJU6d2mLP/Hi3rOGmUeNWGruezOYMHhawQo76Jk6R
kXKAy6lVozZqeoortIpPakiPaghTKvyUkjCm1E/pmLAqxywnNN0L+yxGDBlNHvVvDE4NPYOUxDki
7CR/9pGfHvhJ8eZScZK+pLiqCA2OoOW0flLWKj1AK5u2V4P8BHH906HRrEyZw6IpZWV4spzvoxKo
Sv6eiMJzcZwx5mBdFNoI3U/9C1Dmm3GdrNC7sc/OAj2NsDNaSNmqYWNXcWA8RJEE5NAAxzzNGH1F
DdKOTCT/71QwjtOKsJCKk3DspMGHAYf+j084L3CRkiLfG/xVCjmMvQt+haCBUTY+XqA7MNLKxgif
SFfvtBllC+O2Gd1NwvL2MqHQTYMYvT266/w5qzaD6pRoBo/nYKGX1oLQfa+CjSE0BBKKKcugXjgF
jkfZsRlEnORIurR7El8P/jt0705966O3liD/7KTwMjqjPUGQGs6CMKGF1283sPjEk/BjgH8CDABx
MBTiDQplbmRzdHJlYW0NZW5kb2JqDTE1MCAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9JZGVu
dGl0eS1IL0Jhc2VGb250L0xLRkFQRStTeW1ib2xNVC9TdWJ0eXBlL1R5cGUwL0Rlc2NlbmRhbnRG
b250c1sxNjIgMCBSXS9Ub1VuaWNvZGUgMTUxIDAgUj4+DWVuZG9iag0xNTEgMCBvYmo8PC9MZW5n
dGggMjI4L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVSQsW7DIBCGd57ixkYZIDRVO1gs
6eIhbVW73QmcHaQa0BkPfvsCtRJ1AHT/3Xf3c/zUvrbeJeAfFEyHCQbnLeEcFjIIFxydh4ME60za
onqbSUfgGe7WOeHU+iFA0zD+mZNzohUe+v5pL3bA38kiOT9m5Si/vrPSLTH+4IQ+gQClwOLA+Oms
45ueEHgF72K/RgRZ48M2O1icozZI2o8IjRDiUZXn+UUBevs/z+QfdRnMVRO7V0uh2AY1UkipWGa3
qtKl/PDmyixE2XBdQ7VVDDmPt03FEMvsctivAAMAGddtKAoNCmVuZHN0cmVhbQ1lbmRvYmoNMTUy
IDAgb2JqPDwvTGVuZ3RoIDYxNS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImEk19P2zAU
xd/zKe5jMhFj5382hAQFCSbBJhFpDxOaTOrW3tI4ih2q7dPv3rQFpMF4S+z4nOPfPeGMc55BswVR
sUKUuQAOzTL4Htr1KAdtoiJsQUunYTX1rTe2B7sC4x3gjp38EGXhFMVJ6MGZP4oB3F7fNRDdN58D
juIiEdC0QI88IZ/4ySgWTOTpzm3oZO/AW9DWeZKWsBh/R3EZDlEsQk9mFAjdtGnhigJ9s+Mvp+0w
J+nhS+sZpCK+tY8sykMQR7SR4AnOc5gVSAqc7UxrZpNhesBnMD1+NEwe6Lb9/NFTfl48xS9ryt98
wLjabuFBYVJMPOIh5QbbL+nNo7UmHooM2mkcVY9ovPS4EOchwhuVU3J8diDdvUUxT6JmWVqK+jCJ
VlNCRAFeGwdyVBIxN1rB9kAAB4SbCla26+zW9Ov9BXbAD3oEPCPyKBuurezcR4ian8FlE1zeLCA4
/gonJ8c3i+sLKOD09PwC186b4LhpOOChFem1IDirK8zG9081h7xKWVqJpIRmE4RvaZYvNRfJj71o
PN+8fk1a8JLVdZ1VkBc1qzNRzg4nyKzCM+kpGr1I9ypMVqR1ekB55pxyO1Q0kslRmemNBkVzxFlR
f2M5DKN9VMtD9bEgu/a7IzBMsaOXg767OouTvJhriy2Y0WNNQlrPRQIruTGdUQ7HCHK5NPNfhF2h
ffHpLVzVu7jm8f6HWZayKkvS9F1mzxX/F9mFce2EzKi82LURO6/GTVSFIHdA5h28Da3h1dbUdK+p
rwoG6xGpkR0MhNc+dGrjYGu8nqk/ytFYHEJ0D38FGABcIy+lDQplbmRzdHJlYW0NZW5kb2JqDTE1
MyAwIG9iajw8L0xlbmd0aCA1MTAvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJpFTBjpsw
EL3zFXM0lXBsIBjUKIdN9tCVVuqBW7WqLDCNWwLUkEb7950xSdiqUvawt/F4eDPvvTHlUyC4EFJC
WQFFIsHwDOWn4BvTw9DaSk+270bow5Q1oWQwHQzgjev/mDBnNRz0eIDm1FWTDTOGpZ8hfCmfgscy
eHzeQbD6CpvN6nn3ZQ8FbLcPe8w9lMFqF38XgM2aIPKNCz8CNZeCFzmG4hJJoXhRFGkOa6m4SmMs
PQYbIVROA2/Ln8GqLC9gHkvd6CgPyLOkSAi8Rlp7O1ancfREqr6rLQ6+psExoycM4dyf2hrO2jnd
TaA7z8fDxQTs500Tj5xzEasbNITRmhnt2tcwylEq/H60pJ+/0Gc95xvXH1E7TErJdDcn+8YX0VS3
fjJejImpX3RtGEku18nc9eKGtwJhDwjLLo6Qa/cckeKjlqSF5ApHUu95kl6ZSCHvmzKQHn0YxWwy
3WR1C84Mra7MEY/QD/NCLiKJRaTUI2e8SNfpFbrpHXmYMtRZzTpn7M0W13R+s8U91Y5hzO7IJj8s
m8p5nCVx9u4qFzdy2f+y7VrtbDMT89I5eoODcZM1I1E9EZlfxlcY5FRDRSWvw0Sr8YNEdno42Gp+
x3h1FWFE1X9jzYlqrEOZSMjaNg0WGUdWLO9ioYx/jn9+HBxCJAV/BRgA+JQhfQ0KZW5kc3RyZWFt
DWVuZG9iag0xNTQgMCBvYmo8PC9MZW5ndGggNTgzL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFt
DQpIiXyTS2/bMBCE7/4Ve6SKmBH1sgQEOeQBNAVSFChvRQ+MvLbVyqJA0hH677skbdkGgsAXmRRn
dj6OnuXi+fURFrc/4O7u9vXx5QlEBvf3D0+0+CAXt1KmIEBuFinIFkTKmxpS+sWnuuFNU9c5FGXG
myIv6NX9gkEi/yyeP5DOP5bmaZqWXj88NSCnT5yKlGd1XlTe6Rf7/vJTgtV913bOwqhGNPYGRoMW
k2XBBqdcpwdaalVcAesO6w5pJfktv0XvVTObV8G84ausqgW5yzWZjGrAnkT1qK3q6aga1uRlHLmO
wQA2Ru+TmtHOv2S5Yhfi2UlbZMKLL2f1peCizKNFNzikoR0G4WRZMReG7Ia2p3mHLfhIyrQ7DLv2
JthYcqsZHdufDas5zKo5phF5VZ3CWEiWJfNK/mjnsHXk847DWptjtIMlihwgwJ26nrJr6y6BnYIE
4cscboeg2hZHn8QbxSuJxHyE040AQfMvT9r8vb6JCbKUiywVTRyZ2Z0eYcI3sDRtUIpU0AtYpH+g
gk540Xcv4BYzhzyCn2X9wMWqFHHkHSnqg0sqxuGrnvAdzQ0MGjba0No+yZnqz/LUghZxnRR0ZVvr
rzwAekMYD299RydskrEdrnnEh0OrD0Zt0X5SOPnFt+wKj49pcNTGBVS02Xe+Yd2gTKyYH4kIKHd1
L62nl5Vze9m5qIP/QnpF3PVMKbA59jNQqrmo03xuvs9kd4C9xSlUr2RI+ThIPXbtRSaRnnkXEXfN
i3x1xB37Af8FGADl/TflDQplbmRzdHJlYW0NZW5kb2JqDTE1NSAwIG9iajw8L0xlbmd0aCA0Nzcv
RmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJpJNRb5swFIXf+RX30Z4KsY0Bs0aR0rRSNq3S
pPitmiYazGAjuMJmXf99bRqmrCrLQ1/QkSXOvd+5996hSvdghvsDFqgxptE4zFCHQ4YMmFoPbQkN
Tl9e9q1TQ6ku4H6wTkLRK+i0hbYZf7eqBKsvwNYKKt22+rHpfmCOPgL+Jj8HNzK4ud1AsPgKy+Xi
dvPpGiiH1erq2j1eyWAhJQEKsgoIyD24zyNQEuXCSXJUIo/yPBMM4pRHseA0A3kIEGD5803/5G3/
iBAS07GKk5T+v1RCo4xxxn2pO7RT+6Fv7BMOBYKdLexgQFewfnjo9W+XwLYwtTLzyOlpSxv2/dhT
ODaVz5JTkvl+YohjEcWck9S3syQkEx5m5QJ4BZhMfN7VGUZpnMfevHQU0s2oLawyFnplcMjR4Efc
WgfTjRM0R04Pt9viDK1DejmPlb0Xi/EoJzzh57Cyv1jZOaxhwsEJqj3ev1Se0q3xbrsOWZJC0ZXg
dUIZVMWhaRs1TrZ2A33hnpblyCI/BKgaur1tdGcuZ3dQnE1mNhSWi0iQxNd8Ryhfml+qfQL1x6rO
+F7dlZ5mMgX2mnG6EufHooSnfDI8SdZFWEyb77Ics5oycadvMEN+aeBZgAEAjOsZUw0KZW5kc3Ry
ZWFtDWVuZG9iag0xNTYgMCBvYmo8PC9MZW5ndGggNDYxL0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry
ZWFtDQpIiaSTTWvcMBCG7/4Vc7QPq9WHLVuwbGg2gbYQKFTQQwhBtbVrF8cyttz9+x3ZS9LQ3eaw
N2k080rzvBr9NbrX0f3DDqL1N9hs1g+7L3fAFGy3t3cYvNXResefKTDQ+2hFCaVUgS6Bgj4Co0QV
uKSnFaM5UUoyDrzIiJCZBP0SbSjNC6wTW/0rWmt9Epu18kUsLOWsSKRQIqhX0WOsawvNS1LEvSn9
CMkqi90ePEZb4+3oYbDj1OKJ66Bq9vtExnawnQfT921TGt+4Dg+XEtMnadwP7retoDZjDSF96so5
iUDypM+y4PRvFm+vvwihUMggSwvgOSc5zWQeIMSQYPfn9Nl5fUTC2Cscwf5/lcSsNMtFuOox/l67
wYO2Q2AHn5YWL3fIr3E7VRnwVBJJJRcf2S1fGwrGv7c7/uyOMA2H2b/Bzp6V0zD7WbqutEM3Bobn
yaT4AIyePg4cG1+fXF8sR+9Pri+W474bby4zEVczEYIwKfMPmbxNQPbvBPyoDXZfm+5gR/Du/cc2
XQX9gL/Y+dBPmfDYtSPCmtoKgvVNmBjfHHBYoHceSTaYbVqscj9bG1LGm2Sl4ssc0qs5MEVyHAUe
OMAfAQYApccWmg0KZW5kc3RyZWFtDWVuZG9iag0xNTcgMCBvYmo8PC9MZW5ndGggNTQ2L0ZpbHRl
ci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiaRT22rcMBB991fMowy1V/JNFixbyGahKaQUIuhDCEW1
tWuVjWUsOyZ/35H3kpRk04eCwYMkzsy5zJJSXlJK05X8HSykpMBAbgMaU8oolhX4kmYgJ2BxkYoU
KMg6uCc/GjXAbjS1aquwJBpcY8d9Dd9u7sKcSNiZJw2TGRrow4Jo1+lqgPBBfj2Ap2dsxmbwMuac
5uwEP1holGtgO7bVYGyYkdaBamsYGm16UF23N4hbKbxs3ecD8kYGm9s1BIvvsFwubtc315DksFpd
XePhlXxNcG4/N6axKLGkx6oUsRBZVkJCeUwLngiQjwGBEAV6D794H98z4+JMsviwFRNZnFGeFr7V
PVnbtjYzL9ha5NrCRvX75zDiBGSvUO02jBLi5jeXmfPXk62Tn8fRonkgcVEAhryFSEWBnrCYJpzN
Yy0vJ8WzO/L0lP9OCvliJ6iQw2s7kdkvDco5jV89s3S6Gnsv8oyTnBBZcopHwlMmTvEwA8pREuh6
2+l+MNqBG6sGISGMclLZ/d44r06vnXEDZlR/ekkffTEm9+jRGT5iMcvTQ4+u18aDPaLgKkzITs9o
/uiE6APZOT3WNuqxtv5pi5w+yGP5367kWSwSzpN/ufImfm/3tzokDRfWWzLNCzz5gPVIZwAFA/6P
OVOTer6oIBMxz7Pz9sLWL73fWq8I2FaD3frV9Yvb2yf0HOOAV40PMpo3+GkMmvcAfwQYAKkvK1IN
CmVuZHN0cmVhbQ1lbmRvYmoNMTU4IDAgb2JqPDwvTGVuZ3RoIDQ2OC9GaWx0ZXIvRmxhdGVEZWNv
ZGU+PnN0cmVhbQ0KSImkU81vmzAUv/NXvKM54Njmy9aiVGpSaasUrZos7ZBWkwtOYCOADOnU/362
m8JWNdthB9Djyfy+3rO8DSIqcJ4mFCKKaRqDLIMd0so0tTYwVqqF4mSMbscmzNBzGOUI+ka1YYJa
XV5B+CBvgxsZ3GzXECzuYLlcbNefNsAErFbXG9u8lsFCSgIU5D4gIAuwr59ACRbcluRccYGFiGOg
TOCM5DwFeQwQhPL7e/AxeR8eE0Jy4Ulcmf2ViWZYJLlgnumuG63JWjXwRVuDhT7aT/jcj3XXDhdl
0N9lrNm3s47Is4uLZinJrQaWuyrGKeGJF7G04rn9MV5ZureuJlO5R8RZLGKHXgbooxoq2J/a4kXs
68CeQT2pulGPjYZ9Z8BoZ8NhUEYnOObhMswoz17wdsgFULcH6FoNduzd3m6CBtX3prODf7KPDhkq
oZqI7SnH/eHiQsTsf6MS9mTGBf1XUvP407dJ7dDXSo3QK6PK+nAcoLO+zmvuHG61+dHoaKOOIUeH
+zhJvR0fGZkjSzwuxzlNOX1FNiUUXesuyGCzGc3JTwMcUn1w7SqMbB8e5yB71zEuOjVqGDuY2ZIp
kGgimm8oskxDXWpz9cdmwi8BBgCkGvH6DQplbmRzdHJlYW0NZW5kb2JqDTE1OSAwIG9iajw8L0xl
bmd0aCAyNTc1L0ZpbHRlci9GbGF0ZURlY29kZS9OIDMvQWx0ZXJuYXRlL0RldmljZVJHQj4+c3Ry
ZWFtDQpIiZyWeVRTdxbHf2/JnpCVsMNjDVuAsAaQNWxhkR0EUQhJCAESQkjYBUFEBRRFRISqlTLW
bXRGT0WdLq5jrQ7WferSA/Uw6ug4tBbXjp0XOEedTmem0+8f7/c593fv793fvfed8wCgJ6WqtdUw
CwCN1qDPSozFFhUUYqQJAAMKIAIRADJ5rS4tOyEH4JLGS7Ba3An8i55eB5BpvSJMysAw8P+JLdfp
DQBAGTgHKJS1cpw7ca6qN+hM9hmceaWVJoZRE+vxBHG2NLFqnr3nfOY52sQKjVaBsylnnUKjMPFp
nFfXGZU4I6k4d9WplfU4X8XZpcqoUeP83BSrUcpqAUDpJrtBKS/H2Q9nuj4nS4LzAgDIdNU7XPoO
G5QNBtOlJNW6Rr1aVW7A3OUemCg0VIwlKeurlAaDMEMmr5TpFZikWqOTaRsBmL/znDim2mJ4kYNF
ocHBQn8f0TuF+q+bv1Cm3s7Tk8y5nkH8C29tP+dXPQqAeBavzfq3ttItAIyvBMDy5luby/sAMPG+
Hb74zn34pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6/QO+8z8d03JvyYHHKMpmxyoCZ6iavrqo26rFa
nUyuxIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0ytVeHt1irUBnW1FlNr/1MTf2XYTzQ/17i4Y68Br9gH
sC7yAPK3CwDl0gBStA3fgd70LZWSBzLwNd/h3vzczwn691PhPtOjVq2ai5Nk5WByo75ufs/0WQIC
oAIm4AErYA+cgTsQAn8QAsJBNIgHySAd5IACsBTIQTnQAD2oBy2gHXSBHrAebALDYDsYA7vBfnAQ
jIOPwQnwR3AefAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5Q2IoEoqHUqEsqAAqgVSQFjJC
LdAKqAfqh4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02EebAe7wb6wGI6BU+AceAmsgmvgJrgT
XgcPwaPwPvgwfAI+D1+DJ+GH8CwCEBrCRxwRISJGJEg6UoiUIXqkFelGBpFRZD9yDDmLXEEmkUfI
C5SIclEMFaLhaBKai8rRGrQV7UWH0V3oYfQ0egWdQmfQ1wQGwZbgRQgjSAmLCCpCPaGLMEjYSfiI
cIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8TjxEvEu8RZEolkRfIiRZDSSTKSgdRF2kLaR/qM
dJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m3yO/orAorpQwSjpFQWmk9FHGKMcoFynTlFdUNlVA
jaDmUCuo7dQh6n7qGept6hMajeZEC6Vl0tS05bQh2u9on9OmaC/oHLonXUIvohvp6+gf0o/Tv6I/
YTAYboxoRiHDwFjH2M04xfia8dyMa+ZjJjVTmLWZjZgdNrts9phJYboyY5hLmU3MQeYh5kXmIxaF
5caSsGSsVtYI6yjrBmuWzWWL2OlsDbuXvYd9jn2fQ+K4ceI5Ck4n5wPOKc5dLsJ15kq4cu4K7hj3
DHeaR+QJeFJeBa+H91veBG/GnGMeaJ5n3mA+Yv6J+SQf4bvxpfwqfh//IP86/6WFnUWMhdJijcV+
i8sWzyxtLKMtlZbdlgcsr1m+tMKs4q0qrTZYjVvdsUatPa0zreutt1mfsX5kw7MJt5HbdNsctLlp
C9t62mbZNtt+YHvBdtbO3i7RTme3xe6U3SN7vn20fYX9gP2n9g8cuA6RDmqHAYfPHP6KmWMxWBU2
hJ3GZhxtHZMcjY47HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4OLikubS47HW56UpxFbuWu252
Pev6zE3glu+2ym3c7b7AUiAVNAn2Cm67M9yj3GvcR92vehA9xB6VHls9vvSEPYM8yz1HPC96wV7B
XmqvrV6XvAneod5a71HvG0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt9N3ge9b3tV+QX5XfmN8tEUeU
LOoQHRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4G/SM4JFgfvD/4QYhLSEnI
eyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79AsEC5YGzB3QinCFnEjojJSCyy
JPL9yMkoxyhZ1GjUN9HO0YrondH3YjxiKmL2xTyO9YvVx34U+0wSJlkmOR6HxCXGdcdNxHPic+OH
479OcEpQJexNmEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9OoadkpwynfJPqmapPPZYGpyWn
bUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ3Ozi7D3ZT3Nic/pybuW65xpz
T+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzCnYWzi+MXb1o8XRRU1FV0fYlgScOSc0ut
l1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWvlc6I5fIN8sfKqIVA4oHyghlv/JeWURZf9l9VYRq
o+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDyt/rMqvOqAha0o0R7UcbaX2dLV9dUP1JZ2Xrks3WRNW
s6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrIupG65/V59Yca2A3ahguNno1rGu81JTT9phltljef
bHFsaW+ZWhazbEcr1FraerLNua2zbXp54vJd7dT2yvY/dfh19Hd8vyJ/xbFOu87lnXdXJq7c22XW
pe+6sSp81fbV6Gr16ok1AWu2rHndrej+osevZ7Dnh1557xdrRWuH1v64rmzdRF9w37b1xPXa9dc3
RG3Y1c/ub+q/uzFt4+EBbKB74PtNxZvODQYObt9M3WzcPDmU+k8ApAFb/pi4mSSZkJn8mmia1ZtC
m6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n
4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSc
tRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePC
X8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA5
0LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLf
Kd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o
7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+
S/7c/23//wIMAPeE8/sKDQplbmRzdHJlYW0NZW5kb2JqDTE2MCAwIG9iajw8L0xlbmd0aCA2OTg5
L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDExMDQwPj5zdHJlYW0NCkiJ3FcLVBNnFp48gURe
Dajrov5AUYEkTMCgvKwhBBwXEkxCRGtdkzCQaF7MDCBFhURF0GqpIj6pqK2oSH0UH9uzdfHo+qBC
8VXR9bWybrU+qvUtoPsPVEFbd8/Zc3bPnp05/5m59//u/b//v/fmThAGgiD9kBKEhYxN0mApFwub
J0HNcQTx81NpIiLn3b9OwPcrUKcz5lMg7FDHfATxH40gHHa2I8f6ED2UiyCD4qHsnWMpzN46v/4A
goTQ+F0mXJ/15/opOIKEXYdytAkqvEUsJ4IMTYXyuyYrNbMgHRsDZQeCMDstdqN+YPxA6GtYJYIw
XFb9TAeTxamF9kchHtj0VtxthXowgowYCPFfOAjcMcf7APQfZEEQFuSBMLpv+okIuuDTD+m+BA9R
l+Ae1yOsdFzpY0+GG7PGJbgKVZeYDIbEC+3Hde+ZYXI4CDqNywvnMtgM1ygmg12jRtNRYR9NwIYh
JQFIfPetQgwIidgRC4IjFBxj6BsFr/tj+yytW3Ctmde5LP5cSt3zeNmhGpf3e6iL2QhHKNNPUN5w
YuH12kNfS4+sWVzWNLRJo/sE9XzFlcGGlJyfSoaig7msDDZP0F+HE2aNOccGtEQeSQElThXYiRmS
Aag/DeALvF4ChACzGcUSIRrWMxHca2m24kBD6a0Osy0HaHAi32zEgdpupyQj0cgedLhSBVIxWSKW
imknAZlcrkjXKpKEYIQxNGYUeH0NdMgAz5hRqFQSiY5C4TUZijGSyCjJz+L//gac6/qeOYODsJyL
4bmXM51O5JQY3DXNEorEzoCd3F21/L2+nhPPa9ry2o9Fhe06/cjj/ZH3b1Q89+jX+pffTv5D8/eP
ynZWNy4IuTk704ecPvObXP+uw5mPQusyp1axu0QG30xnQFNu5ZmgzIgzx/0486K/qtzakDb+xp24
oHrdqjmBay2ljeNTVkxv2BR9ptNDdKohZg2TBZP6jZRgQV6xvmvnc8acvFHSUXRmy4NthZ2czuUJ
ucFbwkdc/kiAlz8XLmB8PHm1ocm3tuTB3v1+e0/oVs1wNygOb/j8vLSYE3SJELFLObWzPPov85Pf
fdw/7Tu3JWt8LJnPedIVTeXrLrMda8Nm65ccuM7PXb35SLYhMWF5ZVDkyqDyhc+y3N99ePIZzN9m
OKKZ/sjXvqvPy28HdiRnzitvSi6rCLnjN+3/L4m3SYajIT2Oh/xzGi93yn/rTv8tii/Ph/eL8/FF
vekJN4E7ZqNwwoZTqLP6Fym9CEZhAZ3SdfrbDfWLK1IqLjT4TjVf4BUbKriS5pYXZZ8kn8ViK2+c
5r5XXb9h5uRbTzuNCtU+vg39cUN0ncjj8j378DrPCdM4UlVxi1bVuleY2MZvXbxv6os9Ja3tVQ3F
QViij+XUyh0M3caD34rXxT4o3py56WwQfu2juplr/3guJdH0vmh2124mg/UrCW2d1rHq95+ZvzxV
5Ag3BA9JAhO2B/sfoZhPsZ+GD5qyrTRX6h7+6ONLV3ZXXV9U+7t28ug4j+od5xed91/axLrmEaLj
fq/8LOXzExOTT4/WPQxsPjgsThQS2bLm6p/GpvzQZk3Jv9aIbvQuaSlui5tT83R5mCTc/9lRv9sX
d9zIkDmSRcI5qMtjExzeNSwmg8n0Kcyuss3d0bqH8Y6turEBz+3LmAkTWv8rp/72CEWhkp6Ah73K
CLndasUJo1lvARp7NlWgJ3CQnmewmEkTTpBALutOydHoSEk0ir5KSVqMjJLGSGMmoy7GB/9xEpJk
NKnHKKGgoECcDw1JaCg22q0RsAPbSTNlJwoj5Okaeg074RADQyFQ49liIZ3X4lRtEp3L0ZIxaHyP
H2mSOcdMwQWxJCC36EkSRAERSDMbCTsJKfTy0Okt5iw9ZbbbQH6khI960PZcATNDIxGgvrTgLuBN
1JMmWHqU3SbxQb16jsJNjWdZ7bYsyRA0gNaw/Px73cshRzvR7fblPP8t8/CAwZtV5GJ4IlDvznQx
GEhDxclhm7P+ftP/4AtrkUzFe2oPy20RD9Rsioy+ctr0V2kX9k5bVSf+rcYP7Gcf+/DhMYe18tbx
L7eHoasjM2ft2TIjJGdV49WCHzjXfmyvelzP/82mL+LnOa4+sU9RzbZ7qxUL/c/iF+IApz1hvWVF
rBc/RHA78BuwJOZDw1zOseBBnerqbdWpVWfjlZkJrqI7HlLdblNjomJDnGRjR9vyjowjws0bD4aq
Wh4su8saWnTPP3bLk63pczlWw91FgrLR59oDvMgD3LFfjTh4s3lp7pH92bvWa4O+4+fMerKgsHxb
Nm/rhGddRGBn6QeHH4z3upWpD05r3RmbdUXw6dSj862p/bcnuMFC3ujiXERdnHPd0RksYDNRBOXT
r95sNovJqUGdZbTEYDtL0DklPkVVfzsh7zKtvD/6uC3uJ75rvfG/UEguDrMBfhWigTQTNoPxgj0A
9UPpL7/eL7v+LKZbCQKjDSE8NheF5LljURc7ug+GR5u62MFQPbQmtGS4iaIcZGxExL8ojPUu1j6n
i9WgNZlJYMQJypxtNuopHJi7C4ZONpykq4bAs3ECtxlxIdDbsoCZIkEeCWEkICnCbKQshTwyzzAd
N1KAsgsBZcJB7yG88kvXSzqhN1J0Q4SticKtuI0CIyCTUB6kSdIAiRiFi+TrzRa9wUIzed1b7waA
norlvW2jcTRrhcgK3UAcgCuICDw3DycpcuzrODvBg9CXwNdjKgSR0pgoGEY97JCyfBwq0ux5NkoP
WenMeIEQhhDEjERHRvEyNDKIcxQS5hwTRTdJSUxM9BvuAJBZLEBNI0j4Q0TCnoxniYFcodbKMCVv
okytlim1mEIDkjCNPFWGpSmSgEyZ1KcPp2JpGGzDYh6NVmLKlFigHacAGRoFUCXDV0zT7Q5LxuQy
rQJAUaNVY3Jt6iSgyUgcr5BrgVZFm/B0CjUG/1gp++AxlRKkq2VyLSZXQDvoIE2h1ELa9BKYRpMB
1/sH81UeFsWRxV9Vdc/goKIgHmC0FRFQww4eeKBEjuGQU0ZQRF2GUxQY5QoImHFEF1A5PBNEEc8l
GIUkKJooQlbUFVdXjGuImogKLqt+JPE2TOcNCrjs7vftX/ttv+mZqep6Ve/3e0dVC06B8zz8AtAW
WZeRyi4EgqePv7fnW5sVC/wDFEql0IMKSfB18Q501c/S0ytDu30UAS4e2OxC6RcguHnO89Wru+F/
J8HfCW10CfR2ChD8AwP8/ZSKCZ2LzPf09hZ8/ebJnBWdJHkrOhVc/HyVirmBaLynk/cEVPH1nOcZ
9Fany1g/RBUguDr5OLkrlLaCUqGQ6XHq9wv9HK4KHOWtRKZd1Jj78egydVTvWIyOScSyEBkhxKvj
9WEVFRMZoXyTCE5JmBlhyZhAsshU1O8M7hRVbHKkkLhUhXEQr04SwiKFcDU+iuicRJUoqMLDkxPe
ZGCUOiGuM2dkKW+2GxyBkaq3wNPJVrbPXjP5v0nzrv5YdbTaNjomSr7mqL6SCNyaQ3KNXCMxDF3v
Qda/UBApIdhhLTHAqsLzWEEHD/+P8yNJ8rDukVQeJDcd3KseyvGwQsxmdXVaJXYyG9OzE3fXFCE2
RhVmK8QmYS788+kSOi/54HcqnTlnIJdgtcNPr3OP/qS2zXtvWmBT0qINlnUHhfbY6i/S3dJ3l6w6
uVLiYWoc2bDY5sVch5yVlU8GTUttyj9iqLEvWOyx4yxMkylrZk8Vc02s4sB98nMPb9uEn+sbV3e4
qkfn/3Vzyd2tj1pFuFD3OGH4d8Us/lhtePrEVFeH3etyX2etn2pt23pw2lTHk7/+orWw03KjsQaP
QOjy5P/B/vFvDoN9JQZvSKE8D3vWHJYP62apD7N7d2Ph8IzR0zK067XtyEf2KHJ2xtwA/g+JExt8
Kqovtj07HH+u3zG5/zvD+9o5y2fvGaoZDEpIgzgIAzXEggBR+BsPSaVjNKP10fQ2mOK6DjWd0ZSU
kByZlLYi8ne9jjSclsDCcybnlrXuylH9eHLEo4IKWVWxuePDUqchblGR9Xnn1x7XLnbOz31YcGnW
j3PWfb5q2NGfig+zV8Gni+PuJl1pbnL5KcK6JvWl37ItQ4779Lt0Lzds0/LPBuwavVT6w6BhaTlj
gh9ZZYVZDEtNpty0Eq/ZZjV/UwQ5WvsOlb4XbhW/cNy2vy96lb7ry4QRmWWHnikH7nzaslHbmFNS
O2qVUXPb7ZgFoZOKvOhpj08/3p+9/oHDbZ3fzqutTeeaY8ddOxX6Vf3Sa0VWKuvzmY2qe4VBl01j
jT1D75E4z0STT3aFmtw5YNG4qj5dqDZZdXCoCCk5DS2Fdy4G5zVrZ17IP5Stu3gy/f6kG+OtS7Xk
Cp7qGnp8IbHTklPYdUIfZGuq/+/fX6kpnBpY1OTyaNRrtwVZOX92yy6wfDwotFegBsuHvhunht0N
KcEw7X7C2xnpXz3s5PiuIbebMmnywn8J07bCgn7X9soqV28Rn5tsM/LqHVRrNIr01XEhcVOc01O+
u39jxUvTgV6FwdcbMmvFaD/HxKcZN6OmSJdHKgb1N4ePxFenispsilNaqtLEIzMzv1+07cljTWLJ
wLI+ZpkbLozKmrhmUO3l+0JWU9vE7JC0OzdE87KthY7a3BDLzbf2PZUbO5euHu2X1cfj15P2Ox2+
/rTRt2VjeaK+qBHuEikAHoAv4idh0/LNL9sDUdS4L+N5QolUQnkp9Lp81PFqmN0utIv8Rp0bmWRg
SOo03U/5xWDHe8NIvIezrWAOIN55e9/TBYuP+OVgoVsm3rQywsFfvr3fXCqwhCVgA3OgDtrhNBkH
/nBGvALhsIB+CO9jfz4chzNwG1whAiiYkQwQxGLYCGNhLeyB6ZyZWAXe8MDACAbDGJhB1CABU4iG
3eQmeIIXzuEA7pADCfg9F/ufk2n4hIAMFuPqW2EnnIa/wA8wDGe0hevo+ufiV+CCFSUc0uEE3Oad
+Q1gAoVwCMqgFu4TW7KftLHHYpXYIP4DtWzADuwhBKtPGGyGUhx3CC5SC7ZPNBPTxT+K52E4Wl+O
qGvhLK71jAgkiITTgyxN90qMF8uRh75oM1qP4oRofCEJDuDI6/Ca9EHRUoF+QMN1A8UhIIWRWOHG
o32BWPFWQzZsQhRFUAJH4QH5gCwll8hj2o9qaA3vL/WV+vap6fhWdBef4Rp9YRRaOx+WQypqboYt
sB01S3GtP6G0QwexJw7EkXiSAJJP1pMD5AUdT7+nr1l/ZsQmsGAWyjJYM3tpwHf46Xboroj+Yipy
SZBzGXrSBXHOg0WwAhLhQ8gADVqXh1KA7JWjVCCfNSjfwC24i9ICD+AhxhyPGGVkHIocxYHMJnNI
IPk9iSaJZAc5RqrJaXKWtJEndDK1p9OpHw2g0XQFTaIFtIJW0hp6j/6CVs5gCpbIPmLlrI6dZ1dZ
EwfcHE7FxXDJ3FaugvuWa+eecDoeeAsUW17F7+nYq/PShYhjRQcxTNwkFqA8QI5HIJqxYIV4/NGr
4bijRCOqFbASJQ25W4eItsNu5E7P3jGohq8xSuvQv/VwBZoQ3y1ohufwEsnR4zMlo8j7xA75nUXc
URain1JIBtGQPFKEPFeSKpQz5Cai1CHCIBpMl9AUmkE30R10Jz1Bz9Dr6AmRSdATQ5k782LzWQhb
wpLYdvYx+4TtZiWsmp1h9RzlZnD+XAK3livg9nJHuXNcI3eTl/MOfC5KBV/Fn+JbJMYSc8lkiVJS
LZUYpBm0GujgCzgHlVDVO/dJNhlAKuEz0so4pqENdAE1pNeJlrtMrNADMwnwebjb/owWvkeu0qlk
PgsnC5E/LYkiIbCLDWd72Rxo4OOJkvmTCFByO+BX/htQ8bn0c0b5XNZBXtJyWAp5dHlHmRhM+oOS
7KcHMWIyYSbYcGZwnU7nThBLakNrpEdINThKJWw6m2FghK397C6aqTQwIm2gYr+RX23BTVxn+D+7
q921fEEWxpYtjFYskmPLsrG5+KbakiUZgrBjW4ZqgbS6WNRmKPYkQMelpLQMJRXBo0xmINPLNNNh
0sTJtEcGOnImpX5rX/LEjNspfYBwaR9KyWQInaYY9T8r2dgp0/axM13pO//9/P+ey57dj3H/3MK9
Ncy9jc+Ee+SP0gtY3SL/C/Q5Cd3k0pNyeNegcVGynrtEdi+eXvw9/8PcT0g19zHAYvmij/PjituT
m+GuwQO4+OTvwk24xt2APfjUSOg751Pce9/AJ81eeMyV4n4K43Nk0tvT0/0lT1dnR3vbtq1bWls2
Nze5G10N9c/VOR2b1I12xbahdr21ptpSVbmuYq253LSmrLSk2FgkS6JBwLdWaAyqfVGFOqNUcKo7
d7qZrMZQEVuhiFIFVX2rfagS1d2U1Z5e9Dz4BU9v3tO77ElMigc87kYlqCr0o4CqZMm+oQjy5wOq
ptD7Ot+v84JTF0pRsNsxQglaxgIKJVElSPuOj6WC0QD2lyk2+lV/0uhuhIyxGNli5GiVOpkhVd1E
Z7iqYGeGA7kUq6I1aiBIq9UAK4HyjmBslA4ORYIBq92uuRsp8SfUOAW1l65x6S7g19NQ0U8lPY0y
zm4HzimZxvnUa1kTxKOuklF1NHYgQvmYxnKUuzBvgFZ9847lqYidm/2RsyutVj4VtIwrTEylzir0
raHISqudtZqGfWAs5+iLpvow9Ws4iqGwgtm4M1qEkjOYUmF3wu4qf39JNcg00UMKLVJ71bHUoSjO
TU2KwvCUfbamxjuXuwk1QSU1ElHttMeqarHA+kwFpIanLld7lerVFndjxlSeH9hM2ZoCU1K6kkku
23ROd2dcaHh5ZAmrSH0eVwRVEgpWElHxntpZk2yHVKId3fDSCEbRUZyRcVrkj6ZMnUzP4qnBYVKV
1GeAK0C9/5fVmlhBIzpMnwFj2TpZXmtoX+Kpy0UbGtgSkfw4p1hjty5vczcez3I+ddKkIMHhg0Ec
25jW2YzDb7ezCT6X9UIcBXpqKJKXFYhbZ8Hb7NIoF2WW+SXLuj3McmrJshweVXElX8HzC2AdlZ3L
/zWmyrXBsU5KKv+NOZm3h8JqaGhfRAmmooWxDY2skvL29mVbgaNr/RHeyhU4zsrrVlyUB5admRAp
oYID/6K+qEezkoyrUtcQpY+aojvzrWa02//LoGzuExalk6dhhTJpp2u13LVKXlVeSYrHggUnFxrZ
l0oZV9qADZpc/KQb271P3nvcJB/Vh3HldU34CE9Vdn0O+GqHmIE7hisQEwAcwigMiTOwQ+yAnfxp
6ETbCMKNttfR5kD/IwX6OteRy6F+F+ITRCMijFAQcYSG2I34FmKI64D3Eecw1sPiGeXPQ4Txht9A
hWEvbERqFu5CjXAb6kQr7BSug4o6J+bfYiiBAeQdhpNQIdWymNyfUd4tOtDnr1jDy+AUPoR2jO0y
nIFKrH0H2toN9dArHsB8t6ES+/mZ+CdyCOkuQwB1kHsgAP8H7HsE65hC9PEPIYixzwsu2MHvwvu7
Dm7up+BHGkT7OkSL8CO8Jxc8hzyrvw15Dek4+gxgrAvtO3A8fVjrIP8p7EfajP3u538H18kP4BLS
BfTfKjyCteRzPa+H4GxhzHYcKxBFmBNFshnp3xCP5L1QL92FEPb/4hLlt8BBNnZ4wo8XxnQK4w9i
Hh//czhUGGOGTSyXDHBPuM51yJA7j/euiBdwzk+CG8fmK9Jd8l0cqwEdFyCGtJ8B+2tHtCG6Cug0
XCFGRDHawyjvEochwSDZoBVjmzDXCFsbaNuMdeoo1L+7UL9Osc5mHFffUry4CxowxsWbIbwCsIyH
+L7xEL9zdEouYcwxjO/mWvA76CT3dh7g5825N3gz92Kegor8d3SKseQSrPetAzNXhz8n54QJUom7
46t6+4Le9uhtM2u55tlmmy3LNc2+xUjjbG09kk3e4ls1tpY6s81Tx+Qqb9fhetvNmWrbLcR7da22
Vz2tttOIZsRxlJlf3Uy9baJu4usT35s4K7RBZSXOsrlc9mbJ7V/uqSiqKGpLZ8mvvR1S+ldS+rKU
/pqUHpXSX5bSfVJ6u5RuktIuKe2Q0pukCtksm+QyuUQ2yrIsyoLMySBXZHM3vS62+StEEyOiwFpB
500ca9lGxycBR2QOv+7oWj7EhcK9tN0Vykq5YdrmClFpcH8kQ8i0hlrKvZolMBLJkhxTnbGyU3sO
CMmdOW8tUE0jITqfgFBcoY/CapYY8UFlUHsJNYcgNNJrgcrjPZYec3d5R1/gGU200LqeXhbXyis0
OPUh2Mgx9vFFjl6WbG9ITBtGbVrXppk2rWsttfRCKByhM7UabWVMrlYjl31XvSfYe0BUDSYRUXru
+JiFnoorSsZ7tfCC4IzGE2OMxpL0qpoMUK8aUDK+E88wn2BmnxrIwIngSCRzwpsMzPq8vqAaC2hz
MEDimYbpVem+v5RuDhpI/F97zJI467KBZRyYfkbGaWYeYBmnWcZplnHAO6BnDI6He0loMJKRoVfD
w0enl7liI05V1GrXeitNk936vHXZLa9YPxCAvAPFeBaX4HtdKYKZ3D63j5lwwTBTGXvlK5gsr3TZ
rR+QdwomE6rL1V5wHXN94XqZXWAJjgcYsJK53Dx3atZsa3Vp7Jzh2BGEX3+4jXHSurwbRCmBOoOQ
4MEoGhI8z9UUSUKCQLVc325xDZgeevoXPQOmR55+06IHejyLHoaWzfZye7kDG1zb8Fjh5x97DfAP
PHHm9VPuOncDn33FYJ8DnlzxlhVJUFMqVpeUPrCzbl0Dd0z3oKf/fstmUiGqG53btm7f0lrJ3Vi4
+ObCwpsXFzhfni7op2Pr/9lP+x/7scsIryy/v3w7/wQDtorWoJTnBeSnC7yI/I/RCkIRSk/g/QJP
YAOZKfAclJHfFnge9QsFXkD+YYEXYQNnHpmaTB6MJZLKu8rIWFLpnzgycRRVin/ipcmJl2JHxyeO
KJOHE01KIHY09h+cmllnSnji8DGm+WepVM+aMBRFD4IQcLB/oPB20apbaCkNrVIxAYnZS6xpFJ4f
5EUhW/9Lp66dHaS/oIX+gU6dOnatPblax3aQcL/OPfedG7hGdaaca9h2vUrXrClHa+WP41FqlB+Z
KFlGQ7fbdnqtSj+bDGbaC/4uESDDHBHuEOKWUeGRFmAkuYcZprR0x1K4ZJUwz31IfCwMRURzvsbs
SvDwwJdO9psp9NnRWOw5hliHcavXgM2vjuouawrqcEIz+pyJuUMqUz7fM7QES/ohXHTRJreHFirU
yTDBQNQ86ufsmLqa+yX/cA/pbq9zTa2iXGMBR/z/C2afxbIgeb9wj9eX8PmmfPZlHVsCP1yvTvP4
5L69bzbf59aHVWJZ+r38H5+PMswKDQplbmRzdHJlYW0NZW5kb2JqDTE2MSAwIG9iajw8L1R5cGUv
Rm9udERlc2NyaXB0b3IvRm9udEZpbGUyIDE2MCAwIFIvRm9udEJCb3hbMCAtMjIwIDExMTMgMTAw
NV0vRm9udE5hbWUvTEtGQVBFK1N5bWJvbE1UL0ZsYWdzIDQvU3RlbVYgMC9DYXBIZWlnaHQgMC9B
c2NlbnQgMTAwNS9EZXNjZW50IC0yMTkvSXRhbGljQW5nbGUgMC9Gb250RmFtaWx5KFN5bWJvbCkv
Rm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwPj4NZW5kb2JqDTE2MiAwIG9iajw8L1db
M1syNTBdMTIwWzQ1OV1dL1R5cGUvRm9udC9CYXNlRm9udC9MS0ZBUEUrU3ltYm9sTVQvU3VidHlw
ZS9DSURGb250VHlwZTIvQ0lEU3lzdGVtSW5mbzw8L09yZGVyaW5nKElkZW50aXR5KS9SZWdpc3Ry
eShBZG9iZSkvU3VwcGxlbWVudCAwPj4vRm9udERlc2NyaXB0b3IgMTYxIDAgUi9EVyAxMDAwPj4N
ZW5kb2JqDTEgMCBvYmo8PC9Bbm5vdHMgMiAwIFIvQ29udGVudHMgMyAwIFIvVHlwZS9QYWdlL1Bh
cmVudCAxMCAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Nyb3BCb3hbMCAwIDYx
MiA3OTJdL1Jlc291cmNlczw8L0NvbG9yU3BhY2U8PC9DUzAgMTQ1IDAgUj4+L0ZvbnQ8PC9UVDAg
MTQzIDAgUi9UVDEgMTQ0IDAgUi9DMl8wIDE1MCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0
R1N0YXRlPDwvR1MwIDE0OCAwIFI+Pj4+L1N0cnVjdFBhcmVudHMgMT4+DWVuZG9iag0yIDAgb2Jq
WzUgMCBSXQ1lbmRvYmoNMyAwIG9iajw8L0xlbmd0aCAyMDQ5L0ZpbHRlci9GbGF0ZURlY29kZT4+
c3RyZWFtDQpIiaRX227bSBJ911c09olaWDSbdyZBsJk4mQswA2OteUoGizbZknpDkVxerMx8/Z7q
JiVKFqWBnTyYolpVXadOnaq6vWfv3t3++vHnO+aw9+9/uPvIZrcfHxyWNnhB/1mTFjPOFN7/iPfr
ZvbDEkfc/ziMs+VqtnBsx3EStkxxeLmjXywbxh36+xe9qvHBTmJtzDxxJ2aRk9hOlCQhW25n7xwn
imHFe7/87+x2uexNa8uRMU2PIdnnduglHhnOZl+s5UayQsqMrcqazUNLFKysZMHSclvJVrWqLG6Y
yMtizdrN/I/lL8ZosLeZaJuR7cF6b1OyXBWyYeWKLLbw8OHTAyzOF7E1srrCl3jnWjXLZKPWhYKT
g4to7yIiF4vex4LbPPDIkSVw8x3biGbDVl2RklWbzYHAp+Xs06+UiENy+JAcAv8A0B71U4jjxE6S
xPNZGHt2FOo4tzNryrx73jxuz719HJxf9hQhNJzSGf1i/Vv+r1O13M4TS849q2gbnaPfi29yHlt/
zheRfp8Rxh9r/bmaL7jVEqzrWlQbhaeU/UT4fO7xaQzAZyLwxhFMs/M5FSNcP449FgaRHfG/QchT
7hzx8Q5MqMVjLtlXixi5CKyuyIaXX+dsLQtZi5xVNXhat0rzbJI1X6xjfhgMmzmwS7tatRq2G4IQ
xvAV+dsCXlGk8uZARu6PynNg4B2uK4qMKUpRlcutLFrxqHJFGdCG3865NQm4fxXwC1h7QI0nXnAN
a3+Agzv8BWAfgUwoGTBHcJ+KS2z7YRIng4ce9rlvNXPX0uBXAgbTLhc1E1WVq1ToxNywpks3TDQj
1OnOvXXfaMBg/qACX6xMrVULRpCECMK+06IiYfKb1Hmgm2eyVk/CKA9lWOI+TSPWkokOElW0/UWg
dkWG+7La/C3pMCs6skOPj2Rc1iOhOhTH8p8zy/CTLL2dEovgFZkPEteOgzjmVzLP3QN27vPM/5xR
xKuBqFBeCpnYLIu07GqxJvHQoi/BApKUSuoG0TVSc+Ek/L6wNQNC7g5++uKD8XH9VQJAnmWBPVku
4UsEPOYRC2LH5sAuuijg0WAeh73IDRARIAwi/TfwE9PGjW9ufE97DCPbj+LQvegxPg6Ij6rW3Vet
O90ytKfAtxMv9rhpGXdSZKb1apXrHreqmS9Qexp5UUsN7olEjLTdhYCj0nTurDdTF09eQ1+f2z4u
7J6j7xiCEx0/Zu+9ABlR3vcocoqPhLcXEaLwPVSrbETesLtOvmG/dPmfjAc3zCWKTvGLO69tgIE7
PF2OjR8q0zsjyh8gR2XdsN9KFKiS2Rv2oVt3Tcs8rhsVokA5XQjkRaOOZhMPbC9JLtOWXxh1nmnO
pCcHVPMSNzK8fQBT0UNVY4jabMou13PNI4lPiXCfaLJRGeZUmcu0rcsCipHnh/atCjbdlVzHdtEr
B/bcof1/vjE10oIwos7Y7w8sl20r60Wj/oJXYhi6YmwH7LuxvOitjFsPsFZFupHN17nNNCup6oZW
QfFQT6WY6LPuS0hkUbZMfk9p6ubB6NrhgfNJf23PI6nvL16hWzW4VAO5Rs9uKkFDSrsrMVvnHXko
yAPbzzGeJVq2wx1oCh/11dORdLH3dBTcPxhlRcBMvVaIoSPHTCCZ1CyqlpXUGAh9yPgasa/KosXU
QDW4EU9yFJprhjEaBEpKJdvQECvQlGEEvyuBPGvl9xbhSXtt37DDURrOqE8XHV3nEZUPtI3pw4J1
oLeXYIr2on4EMTy+KOpIa8D94+Nn9g/Y9YKAm9nDjwLes2kvNv0GVUGU9oLEdLcrZL5nNShdlGxy
k6JMhOE+5bR4ETIb7GUrRZAaMJq3xqye0Iz7oWqmGvNiMD3OMdibdxn4XhJXUXC5NIZVg32DEgnH
qshQbcgXhUTNf7e5MHCrdAPGmIsOhjQb0rJYnZuoXSyyiZvsY1b1sPNk/bCoKmGWu2nR86ZF77wK
YeHykVI/uSp4/qTgPZt9Jj25oR1DWmOjd/e5FBijqEipSZNUtPRBT1urMs/LHVWaKkApvY1o4NuB
NgfWjxqL9o+5w3UGwdDD12LYfP5VIBP2uny6Wg/P4TN0HxXIOZheOtVGScJ87tk+hvz42j5zcSz4
TWyhh2K1wg6GRQCqp+d5qSFU+Q2rNmWBEyA77QsiO+4YMBfaoROGg70MlWzK2kzBaitqdBysA6By
K9BFUiwRrV4gynqam+FrJguCB8yxk9BJomtD/+XJ4rOqqfuIYf25Ybk4eaErvgewL3YUshTYzNJy
cS3Q6NWBxqEduKDbNR6cqOZxnEuqIgW+b2RmdAiNGWkfCfMN68X6SERRcez+7jOlfIvOKUgBmWhb
hE9p3+LXlzQofsngFXke8yLPjkMe+JeFKJkWotOJZ9pVyG035EbzMGzmORskiKYvGl30ENFgbsB3
6FYi/VaUu1xma5lNr2eu8+LgfWyMDkf2LwXvTky150Rh0pMX2AkEMjCx/ygLWeukm3wT38Vj2bVE
DKr4XVl/Q1etcOJ0toTSevg3MI6aKCl2q8caVss1xLbuTVJJpamGdktA66eMQDYHpgfAxeDmuGUf
dQUFkj5B3QS1bpCW+sjR5XfysVEt9qDj1D2A+gd090O9hm287D6Xl3MYe06CJOII81zPdvs+t2nb
6s3t7W63s4fuc3toSnOtz0e3GpvhdqA7Jg/wBE3uP9Zytjoixr7zX2xq18eCxMGG5djhmWng/wIM
AMJz9/sNCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iajw8L1VSSShodHRwOi8vd3d3Lm5pc3QuZ292
L2hhc2hfZnVuY3Rpb24pL1MvVVJJPj4NZW5kb2JqDTUgMCBvYmo8PC9IL0kvVHlwZS9Bbm5vdC9S
ZWN0WzMwOS42MDAwMDYgMzE5LjkwOTA1OCA0NjEuMjE1Njk4IDMzNC4zMzY5MTRdL0JvcmRlclsw
IDAgMF0vQlM8PC9XIDAvVHlwZS9Cb3JkZXIvUy9TPj4vU3VidHlwZS9MaW5rL0EgNCAwIFIvU3Ry
dWN0UGFyZW50IDI+Pg1lbmRvYmoNNiAwIG9iajw8L0xlbmd0aCAxNTk2L0ZpbHRlci9GbGF0ZURl
Y29kZS9UeXBlL09ialN0bS9GaXJzdCA4MDQvTiAxMDA+PnN0cmVhbQ0KeNrMWE1vGzcQ/SsEek6W
w28CgYHEqVHXaSxY7knwQbG3qRpZK8jrNu6vzxuSkiVrtcIWTdGDzSU5fJyZ9zhLLWkhBRlBUgmy
QhsS5IR2GPRCRy8oCM9zUUQjhcI4ySgUzMgroTCjlBVKo/UkFJA0bDFEOhqhHMAt5gFkIsYDdjFa
qIg2YiPgOROFBp7nHYHnHQkNvCDZH7Q8D7wINzTwojNCe7gCP3RAa9EHtAQ+u0jGCIShKAZh2EWr
BG+pESamlLawg0tGou/QAt8Az8BfAzyL4AyH4JSwwLMhCgs8h8QASjmnhQWeJymwtfLWixRiMMIC
LyBlGFIBm1jghQgc4EU4ibyq6JzgEKX0AltoiSABqSUGOTSSQTiETgCFqVaI23FqkDQX0HopHEJX
YAePWiPpnlMWpAAl2iDZHngmaOGBZ5FkDzzrMc7cgiw8agcQDzwP3j3wOO+AAIwXAXgBQQbgBeQV
UDoiOIRoJGHcosXmwSHVIDV4tMhf4JQj+UiZUehEidSDvIiUaoAhFcaApKjRgh9OuQVuBJ6DmCAJ
w34hNOORb6bQIwimNrA4JADZIZJMEuhj4UJZ0IsELRJEEXi1BBIIArLk2IaZI7YBVcowDjgCY4LF
jAR5ljUewCcRgVbJAgdvBkl/86a6flrW1bhdPd6216u6vmqatrrgcyPFVXU6nz48/DJd8gHi/mi6
qhfJjs/S7sjH+mt7UT8JXV018zot8mxycoJdLiY+ITBNqfG5CbmJqQFFqaHUcPJTtzTZJmYbotJ1
patyK8ta6Uubd3W5q3LjMobWqbHZROc5nXfTGd7knjG5yZYq72HS1jfVCPUgpWJcjevbNoX7sVnd
T+eYCJsMfHy8f5hILjrJMVECUFx4GCcZXT6289kCfCyni+rXxV29eu5mzGpUXSPR75qv1fvZn9XZ
anpf5ycQt2jaGnb49+Pi7rkz/n0Kjs9mnx9XdXW+YMidoevLt/g75facH/jfWRk5KyPjx2W9erhd
zZZtdmf8+Gmn265mX+rmsXTfr5rl6XS53uG0ub+HTH5Q8qr+rYZibktQZ8183vxV3/0EFXKsX/Lw
i+598/er9mv76nbW1u3080MaPTkZrqmQZRIy8yHTGjJKyCjBH1ZdzCgxo8SMEjNKtNuCjBklZpQY
ixrlC5WuVatLa3ZU6/O0zwKZqCI/t63lckhU3kEXZWd8rbZ1rjO4LnJ3ParPKKboPKMYffgoKL19
ItJxV2nVur5cvvv5qrr89IcoZeSzoHww+PhkEByfDyC8VAuMlXNRnW6Uv65K483IBocXFTew4Fk+
owKDNZvBtbWq3vJbPTkksr8wez51O+iX1YfpE8ubT9/7+rZZTdtZs0jRPS/ZnTxt5s1qIl/Dg/x3
U6KThcSb6u3Em70wnVsn5F1z9/QySto2zZo4nJEB2dNwxtl9Z6jPGcOLOiJQPYsmdlegnAWn9zBs
7NvYbZtq2RuZH2AbBmQswnEb9h3vo2+Cl7HekG/9/mrTS/4O+7qffRpCP+khxmaIseVI9wk2vQST
41VqPz+yN7u+FKqUXdrf0/fuucO+Uf1hxSGlSQ6qYwOMi5ejclfh0M5LMnKCS8ZK6DfbiB/WGPIQ
RnkJdExtCuK4na7ac5TARQtlv5apCJb+Kwqv5X9gfrE+CqNyndtOQz6P5WB1xq/NgcXf3et14p18
6XWuu6WSlmLY6Xy+AXRhlFtBx9T/jDy1Js/5vTTkm4nLUnbuYBq8OoRRLlCdU1rxK3i/Trj92pQP
2j/kmXib/RLowr+4zWCvjtakLV9e3DuOWqtB1nqQtRlkbQdZu0HWHrSS3n+Jk+rVD18zeKHbX6hl
/8KYFtqOhdS/kGRaaTpWqt6VE6Lyo+gmIeiOaP2RvXfUENwxpQ2TAw3TAw0TRLqHkOqgSh2hipI6
VAdX6hhXSR6qgyt1jKtYfogmrlQHVxT69969qcSj53xgWeB6S9RxYjYfUQ75pdPKDh7I9OeEv9xK
uUkKdRBCRwhRO5qJ8ViUw6qISkKhjt+7MhwJLaw/GqTQZOyAcEdC273GSn2sVA98axTA0fqb3PbL
vcS3drLzvV4+knQBfO/3Y1xfn8rnxR3XqXyzofLNhqgrhG8CDABo8BZWDQplbmRzdHJlYW0NZW5k
b2JqDTcgMCBvYmo8PC9MZW5ndGggMzQxL0ZpbHRlci9GbGF0ZURlY29kZS9UeXBlL09ialN0bS9G
aXJzdCAyMDQvTiAyNi9FeHRlbmRzIDYgMCBSPj5zdHJlYW0NCnja1FHbSsNAEP2V+QG7OzN7BQlU
8KFYUWzBB/Gh2m0pSCohgv69s5um3khBH0QfwsnkXJg5QWTQgGiAgoAF6wTk0SzoAW1mhYryjhGI
LCBpIC8zIbDOMwGz6ImBHQoaMFo8ojU28w6sJkEP1kTBALb4IzgWZA3OiY4RXJQcJvCSjZLps54N
+Cg7sYVgMu8gRNlLvLH4A8Rg4PhYnYHsqeFKXcq2VN5majqpqo4LQ9yFmi5etk+tmrWLpp3Uy1S3
cstIq3l67ucjDCP9C3JZ1OwXjZ+OuMnty6fSfofUIZbrbrPL9KY+DwfzINIBjoe4P1XYt/sNrr+L
wtd+Y9cn73rmXc+865n8YM+BBnMh8AHOHODsEPef/8FP5dfNpt3U6/PtMqlpM7/74NdiP62X76Yc
Nn7YrOtOp2aPi/t0klbbJhW+zONVm5q9/M1dVa8CDADR7FnODQplbmRzdHJlYW0NZW5kb2JqDTgg
MCBvYmo8PC9OdW1zWzAgOSAwIFJdPj4NZW5kb2JqDTkgMCBvYmo8PC9TL0Q+Pg1lbmRvYmoNMTAg
MCBvYmo8PC9Db3VudCAyL0tpZHNbMTQyIDAgUiAxIDAgUl0vVHlwZS9QYWdlcz4+DWVuZG9iag0x
MSAwIG9iajw8L0xlbmd0aCAzOTg5L1R5cGUvTWV0YWRhdGEvU3VidHlwZS9YTUw+PnN0cmVhbQ0K
PD94cGFja2V0IGJlZ2luPSfvu78nIGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9h
ZG9iZS14YXAtZmlsdGVycyBlc2M9IkNSTEYiPz4NCjx4OnhtcG1ldGEgeG1sbnM6eD0nYWRvYmU6
bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0IDIuOS4xLTEzLCBmcmFtZXdvcmsgMS42Jz4N
CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3lu
dGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+DQo8cmRmOkRl
c2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDowNjkzNzZjMi0yOTU5LTQ4NzYtOWUyNy1hNDAxZDc4
NzY4ZjAnIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgcGRmOlByb2R1
Y2VyPSdBY3JvYmF0IERpc3RpbGxlciA2LjAgKFdpbmRvd3MpJz48L3JkZjpEZXNjcmlwdGlvbj4N
CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjA2OTM3NmMyLTI5NTktNDg3Ni05ZTI3
LWE0MDFkNzg3NjhmMCcgeG1sbnM6cGRmeD0naHR0cDovL25zLmFkb2JlLmNvbS9wZGZ4LzEuMy8n
IHBkZng6Q29tcGFueT0nTklTVCcgcGRmeDpTb3VyY2VNb2RpZmllZD0nRDoyMDA1MDQyODE1MTUx
MicvPg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6MDY5Mzc2YzItMjk1OS00ODc2
LTllMjctYTQwMWQ3ODc2OGYwJyB4bWxuczpwaG90b3Nob3A9J2h0dHA6Ly9ucy5hZG9iZS5jb20v
cGhvdG9zaG9wLzEuMC8nPjxwaG90b3Nob3A6aGVhZGxpbmU+PHJkZjpTZXE+PHJkZjpsaT48L3Jk
ZjpsaT48L3JkZjpTZXE+PC9waG90b3Nob3A6aGVhZGxpbmU+PC9yZGY6RGVzY3JpcHRpb24+DQo8
cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDowNjkzNzZjMi0yOTU5LTQ4NzYtOWUyNy1h
NDAxZDc4NzY4ZjAnIHhtbG5zOnhhcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycgeGFw
OkNyZWF0b3JUb29sPSdBY3JvYmF0IFBERk1ha2VyIDYuMCBmb3IgV29yZCcgeGFwOk1vZGlmeURh
dGU9JzIwMDUtMDQtMjhUMTE6MTU6NTMtMDQ6MDAnIHhhcDpDcmVhdGVEYXRlPScyMDA1LTA0LTI4
VDExOjE1OjI0LTA0OjAwJyB4YXA6TWV0YWRhdGFEYXRlPScyMDA1LTA0LTI4VDExOjE1OjUzLTA0
OjAwJz48L3JkZjpEZXNjcmlwdGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlk
OjA2OTM3NmMyLTI5NTktNDg3Ni05ZTI3LWE0MDFkNzg3NjhmMCcgeG1sbnM6eGFwTU09J2h0dHA6
Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J3V1aWQ6OGQwODRj
OTgtMjY4ZC00ZGQ3LWIwOTAtZWI0MTM0NzNkOGYxJz48eGFwTU06VmVyc2lvbklEPjxyZGY6U2Vx
PjxyZGY6bGk+MjwvcmRmOmxpPjwvcmRmOlNlcT48L3hhcE1NOlZlcnNpb25JRD48L3JkZjpEZXNj
cmlwdGlvbj4NCjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjA2OTM3NmMyLTI5NTkt
NDg3Ni05ZTI3LWE0MDFkNzg3NjhmMCcgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVt
ZW50cy8xLjEvJyBkYzpmb3JtYXQ9J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxyZGY6QWx0
PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVmYXVsdCc+VGhpcyB3b3Jrc2hvcCBjb25zaWRlcnMgdGhl
IGZ1bGwgcmFuZ2Ugb2YgcHVibGljIGtleSB0ZWNobm9sb2d5IHVzZWQgZm9yIHNlY3VyaXR5IGRl
Y2lzaW9uczwvcmRmOmxpPjwvcmRmOkFsdD48L2RjOnRpdGxlPjxkYzpjcmVhdG9yPjxyZGY6U2Vx
PjxyZGY6bGk+Y2Fzd2VsbDwvcmRmOmxpPjwvcmRmOlNlcT48L2RjOmNyZWF0b3I+PGRjOnN1Ympl
Y3Q+PHJkZjpTZXE+PHJkZjpsaT48L3JkZjpsaT48L3JkZjpTZXE+PC9kYzpzdWJqZWN0PjwvcmRm
OkRlc2NyaXB0aW9uPg0KPC9yZGY6UkRGPg0KPC94OnhtcG1ldGE+DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9J3cnPz4N
CmVuZHN0cmVhbQ1lbmRvYmoNMTIgMCBvYmo8PC9Nb2REYXRlKEQ6MjAwNTA0MjgxMTE1NTMtMDQn
MDAnKS9DcmVhdGlvbkRhdGUoRDoyMDA1MDQyODExMTUyNC0wNCcwMCcpL1RpdGxlKFRoaXMgd29y
a3Nob3AgY29uc2lkZXJzIHRoZSBmdWxsIHJhbmdlIG9mIHB1YmxpYyBrZXkgdGVjaG5vbG9neSB1
c2VkIGZvciBzZWN1cml0eSBkZWNpc2lvbnMpL0NyZWF0b3IoQWNyb2JhdCBQREZNYWtlciA2LjAg
Zm9yIFdvcmQpL1Byb2R1Y2VyKEFjcm9iYXQgRGlzdGlsbGVyIDYuMCBcKFdpbmRvd3NcKSkvQXV0
aG9yKGNhc3dlbGwpL0NvbXBhbnkoTklTVCkvU291cmNlTW9kaWZpZWQoRDoyMDA1MDQyODE1MTUx
Mik+Pg1lbmRvYmoNeHJlZg0KMCAxMzkNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAxODg3NCAw
MDAwMCBuDQowMDAwMDE5MTQ1IDAwMDAwIG4NCjAwMDAwMTkxNjcgMDAwMDAgbg0KMDAwMDAyMTI4
NSAwMDAwMCBuDQowMDAwMDIxMzQ5IDAwMDAwIG4NCjAwMDAwMjE1MTAgMDAwMDAgbg0KMDAwMDAy
MzIwMyAwMDAwMCBuDQowMDAwMDIzNjUzIDAwMDAwIG4NCjAwMDAwMjM2ODYgMDAwMDAgbg0KMDAw
MDAyMzcwOSAwMDAwMCBuDQowMDAwMDIzNzY4IDAwMDAwIG4NCjAwMDAwMjc4MzQgMDAwMDAgbg0K
MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg
Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1
MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw
MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw
MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw
MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN
CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1
IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1
NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw
IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw
MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw
MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm
DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz
NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2
NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw
MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw
MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K
MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg
Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1
MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw
MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw
MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw
MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN
CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1
IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1
NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw
IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw
MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw
MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow
MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm
DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz
NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2
NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw
MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw
MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw
MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K
MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg
Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1
MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg
NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw
MDAgNjU1MzUgZg0KdHJhaWxlcg0KPDwvU2l6ZSAxMzk+Pg0Kc3RhcnR4cmVmDQoxMTYNCiUlRU9G
DQo=
--=====================_14969562==_--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SIBkwY077111; Thu, 28 Apr 2005 11:11:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SIBk5w077110; Thu, 28 Apr 2005 11:11:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [200.53.113.210] (mail.seguridata.com [200.53.113.210]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3SIAsPZ076947 for <[e-mail]>; Thu, 28 Apr 2005 11:11:19 -0700 (PDT) (envelope-from [e-mail])
Received: from no.name.available by [200.53.113.210] via smtpd (for [208.184.76.42] [208.184.76.42]) with SMTP; Thu, 28 Apr 2005 13:09:32 -0600
Received: from miguel2 ([192.168.0.214]) by mail.seguridata.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Apr 2005 13:12:26 -0500
From: "Miguel A Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: RE: TimeStampToken mime type?
Date: Thu, 28 Apr 2005 13:08:17 -0500
Message-ID: <000001c54c1d$41033920$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-OriginalArrivalTime: 28 Apr 2005 18:12:26.0606 (UTC) FILETIME=[D54998E0:01C54C1D]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

The entire TSP response is

TimeStampResp ::= SEQUENCE  {
     status                  PKIStatusInfo,
     timeStampToken          TimeStampToken     OPTIONAL  }

In think you're supposed to send the whole thing (the token plus the
status info) and hence the MIME type, when using the TSP protocol. When
it comes to using or storing an already acquired time stamp, some specs
(like RFC 3126) refer to the time stamp token as part of a bigger
CMS-type structure. Maybe you can find some info in the LTANS group
(also in IETF).

Regards,

Miguel Rodriguez
SeguriData
Mexico  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Alicia da Conceicao
Sent: Thursday, April 28, 2005 10:58 AM
To: [e-mail]
Subject: TimeStampToken mime type?



Greetings:

RFC-3161 provides the following MIME types and associated
extensions:

	application/timestamp-query            .tsq
	application/timestamp-reply            .tsr

But it does not appear to provide anything for the actual time stamp
token, which is a CMS signed-data structure extracted from the time
stamp response.  I have done some searching online and did not find any
mime standards for the time stamp token.  Does anyone know of any?

If not, then I propose that we use the following:

	application/timestamp-token            .tst

as the offical standard.  Comments???

Alicia.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SHCmb8066763; Thu, 28 Apr 2005 10:12:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SHClCr066762; Thu, 28 Apr 2005 10:12:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SHChIK066650 for <[e-mail]>; Thu, 28 Apr 2005 10:12:45 -0700 (PDT) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA16698; Thu, 28 Apr 2005 19:27:15 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005042819122938:2194 ; Thu, 28 Apr 2005 19:12:29 +0200 
Message-ID: <[e-mail]>
Date: Thu, 28 Apr 2005 19:12:25 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>, Russ Housley <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/04/2005 19:12:29, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/04/2005 19:12:31, Serialize complete at 28/04/2005 19:12:31
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan and Russ,

> Denis,

> Russ and I have taken a thorough look at your text proposal and we have
> edited a counter proposal where we try to meet your needs as much as
> possible without compromising what we think is the core purpose of the
> draft (to enable certificate discovery bottom-up).

> The conclusion is that we suggest changes to the introduction section
> but we keep the old security considerations intact. 

I would suggest that a merge would need to be done between the "old" 
security considerations section and the "new" one.

The "old" security considerations section is mentionning a solution which 
does NOT suppress the problem, but minimize the risk only in case the CAs 
are really "honest".

The old" security considerations section does not provide a solution in case 
the name collsion between two CRL issuer name is deliberate, whereas the 
"new" security considerations section provides a secure solution in one case 
and clearly mentions that all other cases are dependant about "zillions" of 
*local* trust conditions which cannot all be standardized.

The main purpose of a security considerations section is to provide the 
adequate warnings and solutions when they exist and not to hide the problems.

> That is not because
> we necessarily disagree with all of the statements in your proposal, but
> in the cases we don't, we still think it is out of scope for this work.

This is clearly within the scope of a security considerations section.

> The new introduction proposal based on your input is:
> --------------------------------------------------------------
> 
> RFC 3280 [PKIX1] specifies the validation of certification paths.  One
> aspect involves the determination that a certificate has not been
> revoked, and one revocation checking mechanism is the Certificate
> Revocation List (CRL).  CRL validation is also specified in RFC 3280,

I would love this last sentence to be true but the reality is that:
"CRL validation is NOT specified in RFC 3280". :-(

> which involves the constructions of a valid certification path for the
> CRL issuer.  

There is no such a statement in RFC 3280.

> Building a CRL issuer certification path from the signer of

There is no notion of "CRL issuer certification path" in RFC 3280.
The primary requirement is to make sure that the CRL issuer designated by 
the CA is indeed the right one. In some (but not all) cases, I mean among 
the zillion of cases, there MAY be a need to construct a CRL issuer 
certification path.

> the CRL to a trust anchor is straightforward when the certificate of the
> CRL issuer is present in the certification path associated with the
> target certificate, but it can be complex in other situations.

 From the comments above, you can see that I cannot agree with the above 
revised text. The remaining of the text is acceptable in general, but could 
possibly be slightly revised to be more in continuation with the changes 
there are needed above (i.e. it is not cast in concrete).

Denis

> There are several legitimate scenarios where the certificate of the CRL
> issuer is not present, or easily discovered, from the target
> certification path.  This can be the case when indirect CRLs are used,
> when the certification Authority (CA) that issued the target certificate
> changes its certificate signing key, or when the CA employs separate
> keys for certificate signing and CRL signing.
> 
> Methods of finding the certificate of the CRL issuer are currently
> available, such as though an accessible directory location or through
> use of the Subject Information Access extension in intermediary CA
> certificates.
> 
> Directory lookup requires existence and access to a directory that has
> been populated with all of the necessary certificates.  The Subject
> Information Access extension, which supports building the CRL issuer
> certification path top-down (in the direction from the trust anchor to
> the CRL issuer), requires that some certificates in the CRL issuer
> certification path includes an appropriate Subject Information Access
> extension.
> 
> RFC 3280 [PKIX1] provides for bottom-up discovery of certification paths
> through the Authority Information Access extension, where the
> id-ad-caIssuers access method may specify one or more accessLocation
> fields that reference CA certificates associated with the certificate
> containing this extension.
> 
> This document enables the use of the Authority Information Access
> extension in CRLs, enabling a CRL checking application to use the access
> method (id-ad-caIssuers) to locate certificates that may be useful in
> the construction of a valid CRL issuer certification path to an
> appropriate trust anchor.
> 
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>  
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: den 18 april 2005 13:41
>>To: Stefan Santesson
>>Cc: Russ Housley; pkix
>>Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
>>
>>Stefan,
>>
>>
>>>Denis,
>>
>>>I will come back and comment on your text proposals, but before
>>
> that,
> 
>> > a few questions/comments:
>>
>>
>>><snip>
>>
>>>>>You point out some well known issues related to the lack of
>>>>
> absolute
> 
>>>>>cryptographic binding between CRL and certificates where the
>>>>>certificate and CRL is not signed by the same key.
>>>>
>>>>Not really. It is indeed possible to have an absolute cryptographic
>>>>binding between CRL and certificates where the certificate and CRL
>>>
> is
> 
>>not
>>
>>>>signed by the same key, but the key point is that proposed
>>>
> extension
> 
>> >> is *not* the means to provide such a binding (and you agree with
> 
> this
> 
>> >> further down in this e-mail).
>>
>>
>>>We agree that this extension does not add to the concept of
>>>cryptographic binding. But how do you mean it can be done?
>>
>>Would this mean that you believed this could not be done ? :-)
>>
>>I already provided the information, but since at that time you were
>>focussing on another issue, you probably missed the point.
>>
>>I would encourage you to read again that thread, but I will provide a
>>short
>>reply here to your question.
>>
>>This can be done using cRLIssuer from the CRL DP. cRLIssuer contains
> 
> the
> 
>>DN
>>of the CRL Issuer and we all know that CAs are free to assign the DNs
> 
> they
> 
>>wish. The next point is for a verifier to make sure that the DN which
>>identifies the CRL Issuer (in the CRL DP) is indeed the one that was
> 
> meant
> 
>>by the CA. The CRL must be issued by a CRL Issuer that has the same
> 
> DN.
> 
>>The
>>CRL Issuer will have a certificate issued by a CA.
>>
>>Case a): the CA that has issued that certificate is the same as the CA
>>that
>>has issued the target certificate (which contains the hereabove
> 
> mentionned
> 
>>CRL DP). This is easy to check for a verifier since the verifier must
>>first
>>build the certification path and then test the revocation status of
> 
> every
> 
>>element of the path. So the verifier knows the validated sequence of
> 
> DNs
> 
>>starting from a self-signed certificate. It must then use the same
>>sequence
>>of DNs to validate the CRL Issuer certificate.
>>
>>This is a general rule which does not require any extra local trust
>>information.
>>
>>Case b) : the CA that has issued that certificate is NOT the same as
> 
> the
> 
>>CA
>>that has issued the target certificate. This case requires extra
> 
> *0local*
> 
>>trust information. There are many such trust conditions possible and
> 
> thus
> 
>>this cannot be defined in general. Cases a) and b) are thus not
> 
> equivalent
> 
>>and have to be distinguished.
>>
>>
>>><snip>
>>
>>>>>This draft only introduces a new way to locate certificates
>>>>>that can be helpful in building this path.
>>>>
>>>>At least one sentence of which we both agree !
>>>>It should be copied and pasted in the abstract.
>>>
>>>Good, then I suggest that we leave unrelated topics out of this
>>
> draft
> 
>>>and focus on the issues that are related to this limited scope.
>>
>>This is what I did in my proposal, except that we need to have a
> 
> security
> 
>>considerations section and the goal of that section is not to hide
>>problems
>>but to correctly warn users. Thus why an informatiove annex on the
> 
> topics
> 
>>mentionned in the security considerations section would be quite
> 
> useful.
> 
>>In fact, its content would be along the lines of the explanations
> 
> which
> 
>>are
>>just above.
>>
>>I hope this e-mail will help us to progress.
>>
>>Denis
>>
>>
>>>Stefan Santesson
>>>Program Manager - Standards Liaison
>>>Windows Security
>>
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SFwKOI055645; Thu, 28 Apr 2005 08:58:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SFwKTL055644; Thu, 28 Apr 2005 08:58:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eevee.engine.ca (gate1.engine.ca [207.188.86.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SFwJlC055636 for <[e-mail]>; Thu, 28 Apr 2005 08:58:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from alicia@localhost) by eevee.engine.ca (8.11.3nb1/8.6.12) id j3SFwTc22369 for [e-mail]; Thu, 28 Apr 2005 11:58:29 -0400 (EDT)
From: Alicia da Conceicao <[e-mail]>
Message-Id: <[e-mail]>
Subject: TimeStampToken mime type?
To: [e-mail]
Date: Thu, 28 Apr 2005 11:58:29 -0400 (EDT)
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings:

RFC-3161 provides the following MIME types and associated
extensions:

	application/timestamp-query            .tsq
	application/timestamp-reply            .tsr

But it does not appear to provide anything for the actual time
stamp token, which is a CMS signed-data structure extracted from
the time stamp response.  I have done some searching online and
did not find any mime standards for the time stamp token.  Does
anyone know of any?

If not, then I propose that we use the following:

	application/timestamp-token            .tst

as the offical standard.  Comments???

Alicia.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PKVFgs079597; Mon, 25 Apr 2005 13:31:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PKVFkS079596; Mon, 25 Apr 2005 13:31:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PKVEgU079555 for <[e-mail]>; Mon, 25 Apr 2005 13:31:14 -0700 (PDT) (envelope-from [e-mail])
Received: from arport2v (213.64.26.90) by pne-smtpout1-sn1.fre.skanova.net (7.1.026.7) id 42650A3B00195E58 for [e-mail]; Mon, 25 Apr 2005 22:31:08 +0200
Message-ID: <00ba01c549d6$22d8f500$8217a8c0@arport2v>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: US e-Gov dep. turns to gateway PKI
Date: Mon, 25 Apr 2005 22:34:09 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01C549E6.E569D070"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

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

US e-Gov dep. turns to gateway PKI

Page 11-13 of the following document which was presented at PKI Workshop =
2005, shows that the gateway security model is alive and well also in =
the US (in the northern Europe it is already a de-facto standard):
http://middleware.internet2.edu/pki05/proceedings/10-kailar-phinms.ppt


Why the DOH have come to the conclusion to use this model rather than =
end-to-end security model supported by the US Federal PKI, I don't know =
as I did not attend the workshop. However, recent studies in this space =
point to numerous reasons for taking this route, including cost and =
migration issues. But probably the major reason for abandoning the =
end-to-end security model is due to its inability to support =
collaborative inter-organizational business processes and information =
systems as the following papers outline:
http://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-1.pdf
http://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-2.pdf

Long (winding) paper describing more of the rationale behind the =
gateway/domain PKI model:
http://web.telia.com/~u18116613/pki4org.pdf

An extensible sustainable solution

Although not entirely obvious unless you dig deep, the gateway security =
architecture is not an "interim" solution waiting for the real thing =
(client-side PKI), but rather a very flexible scheme that can "host" =
arbitrary other PKI trough "PKI tunneling".

Smart cards - A fading proposition

Furthermore, this scheme will long-term also likely affect client-side =
security by utilizing smart devices rather than smart cards in order to =
make full use of the power of server-level ("virtual") resources like =
VISA's 3D Secure. This will enable the public sector to replace their =
current quite expensive and hard-to-administer purchasing cards, with =
in-house server-based administration facilities not requiring any kind =
of end-user distribution as well as offering much better control of =
purchases.

Anders Rundgren
Located in the EU, working for a US company, but here expressing my =
personal opinion 
------=_NextPart_000_00B7_01C549E6.E569D070
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:st1 =3D "urn:schemas-microsoft-com:office:smarttags" xmlns:o =
=3D=20
"urn:schemas-microsoft-com:office:office"><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><STRONG>US e-Gov dep. turns to gateway=20
PKI</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Page 11-13 of the following document =
which was=20
presented at PKI Workshop 2005, shows that the gateway security model is =
alive=20
and well also in the US (in the northern Europe it is already a de-facto =

standard):</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://middleware.internet2.edu/pki05/proceedings/10-kailar-phinm=
s.ppt">http://middleware.internet2.edu/pki05/proceedings/10-kailar-phinms=
.ppt</A></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>Why the DOH have come to the conclusion =
to use this=20
model rather than end-to-end security model supported by the US Federal =
PKI, I=20
don=92t know as I did not attend the workshop. However, recent studies =
in this=20
space point to numerous reasons for taking this route, including cost =
and=20
migration issues. But probably the major reason for abandoning the =
end-to-end=20
security model is due to its inability to support collaborative=20
inter-organizational business processes and information systems as the =
following=20
papers outline:</FONT></DIV>
<DIV><A=20
href=3D"http://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-1.pdf">h=
ttp://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-1.pdf</A><BR><A=20
href=3D"http://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-2.pdf">h=
ttp://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-2.pdf</A></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Long (winding) paper describing more =
of&nbsp;the=20
rationale behind the gateway/domain PKI model:</FONT></DIV>
<DIV><A=20
href=3D"http://web.telia.com/~u18116613/pki4org.pdf">http://web.telia.com=
/~u18116613/pki4org.pdf</A></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>An extensible sustainable=20
solution</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Although not entirely obvious unless =
you dig deep,=20
the gateway security architecture is not an =93interim=94 solution =
waiting for the=20
real thing (client-side PKI), but rather a very flexible scheme that can =
=93host=94=20
arbitrary other PKI trough =93PKI tunneling=94.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>Smart cards =96 A fading=20
proposition</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Furthermore, this scheme will long-term =
also likely=20
affect client-side security by utilizing smart devices rather than smart =
cards=20
in order to make full use of the power of server-level (=93virtual=94) =
resources=20
like VISA=92s 3D Secure. This will enable the public sector to replace =
their=20
current quite expensive and hard-to-administer purchasing cards, with =
in-house=20
server-based administration facilities not requiring any kind of =
end-user=20
distribution as well as offering much better control of =
purchases.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anders Rundgren</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Located in the EU, working for a US =
company, but=20
here&nbsp;expressing my&nbsp;personal =
opinion</FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00B7_01C549E6.E569D070--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PKTY6V079253; Mon, 25 Apr 2005 13:29:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PKTY9Z079252; Mon, 25 Apr 2005 13:29:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PKTXHg079245 for <[e-mail]>; Mon, 25 Apr 2005 13:29:34 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19927; Mon, 25 Apr 2005 16:29:29 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-crlaia-01.txt
Date: Mon, 25 Apr 2005 16:29:28 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Authority 
			  Information Access CRL Extension
	Author(s)	: S. Santesson, R. Housley
	Filename	: draft-ietf-pkix-crlaia-01.txt
	Pages		: 8
	Date		: 2005-4-25
	
This document updates RFC 3280 by defining the Authority Information
   Access Certificate Revocation Lists (CRL) extension.  RFC 3280
   defines the Authority Information Access certificate extension using
   the same syntax.  The CRL extension provides a means of discovering
   and retrieving CRL issuer certificates.

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

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


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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-crlaia-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from 80.178.74.103.adsl.012.net.il (80.178.74.103.adsl.012.net.il [80.178.74.103]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3O3TLck092781; Sat, 23 Apr 2005 20:30:26 -0700 (PDT) (envelope-from [e-mail])
X-Message-Info: QTSPruR3zuqDFFzdqWGAwf074t010CEJ87YFFdZZBzh
Received: from jpqdvkbt42.cableinet.co.uk (234.70.194.16) by z45-bj.cableinet.co.uk with Microsoft SMTPSVC(5.0.2195.6824); Sun, 24 Apr 2005 05:27:19 +0100
Received: from precludeo64 (eugene244.234.214.76) by cableinet.co.uk (kc852) with SMTP id <50816gm30v> (Authid: ChangSilver); Sat, 23 Apr 2005 22:22:19 -0600
From: "Nicole Mccabe" <[e-mail]>
To: "'Ietf-smtp-request'" <[e-mail]>
Subject: Posses viaggra, propesia and more... now! julio
Date: Sun, 24 Apr 2005 03:28:19 -0100
Message-ID: <217w102k866$099hol495od50$5dw5hbt@conspicuousdieticianprincetonne433>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--RQAVBLQ0699374JJEOP"

----RQAVBLQ0699374JJEOP
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit

neew and improoved drags on our website!
try us, you wont be dissappointed...
for sure :)

our main page:
http://downtown.a8k.net/ph/erika/starkey.htm

and also directly:

loosing hair? stop it now! look good again with Proppesia, recomended! :
http://downtown.a8k.net/ph/erika/12/dibble.htm

bed problems? solve it now! you wont stop scrrewing with viaggra, enjoy!:
http://downtown.a8k.net/ph/erika/20/aspect.htm


also:
men's haelth
mucsle relexers
pajn reliev

woo hoo got the jeep home today oo the fun stuff i have to fix on this one custom bodywork by immovable objects inc just to name a few.
re koortslipcreme zovirax vectavir of kruidvat eigen merk koortslipcreme tijdens de zwangerschap.
i am soooooooo going to get a lawsuit going on this before tort reform kicks in i feel cheap and used!
a friend took this one because unfortunately jjb slept in and wasn t out of his tent on this fine morning i only got to see the pic too mad.
kezman? great player but will he fit in with barcelona? he knows how to score a goal that s for sure!!!!
i am sure i hear them say sha mon which makes me think of bo selecta and avid merrion doing michael jackson!
the stock alarm doesnt have any kind of shock sensor or anything it just goes off if the door is opened without the alarm being turned off.
qoute quot if life gives ya lemons throw them behind you and say ok bud what else ya got? quot.
when we were working on the movie adaptation many changes were taking place at the same moment in the picture some scenes changed characters and stuff like that.
anyway sorry i looked up his name don t know if anyone else has ever heard of a clifton archuleta i haven t.
i can t see riquelme agreeing to a deal that would take him to a swiss club furthermore i don t see many swiss clubs affording his salary.
good luck it s probably one of the rarest and most sought after aftermarket parts for watercooled vw s.
fottral com is by far the best site on the internet i recommend it to all of my friends.
what did you think of the website so far?

----RQAVBLQ0699374JJEOP--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MN2pVM025979; Fri, 22 Apr 2005 16:02:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MN2pt7025978; Fri, 22 Apr 2005 16:02:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MN2lNn025959 for <[e-mail]>; Fri, 22 Apr 2005 16:02:47 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Sat, 23 Apr 2005 00:02:43 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Sat, 23 Apr 2005 00:02:35 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on <draft-ietf-pkix-crlaia-00.txt>
Thread-Index: AcVEC4eLEdCIS+w6TdCnRyIMzkeQUwDgpirA
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 22 Apr 2005 23:02:43.0330 (UTC) FILETIME=[63FC4620:01C5478F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3MN2lNn025970
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Russ and I have taken a thorough look at your text proposal and we have
edited a counter proposal where we try to meet your needs as much as
possible without compromising what we think is the core purpose of the
draft (to enable certificate discovery bottom-up).

The conclusion is that we suggest changes to the introduction section
but we keep the old security considerations intact. That is not because
we necessarily disagree with all of the statements in your proposal, but
in the cases we don't, we still think it is out of scope for this work.

The new introduction proposal based on your input is:
--------------------------------------------------------------

RFC 3280 [PKIX1] specifies the validation of certification paths.  One
aspect involves the determination that a certificate has not been
revoked, and one revocation checking mechanism is the Certificate
Revocation List (CRL).  CRL validation is also specified in RFC 3280,
which involves the constructions of a valid certification path for the
CRL issuer.  Building a CRL issuer certification path from the signer of
the CRL to a trust anchor is straightforward when the certificate of the
CRL issuer is present in the certification path associated with the
target certificate, but it can be complex in other situations.

There are several legitimate scenarios where the certificate of the CRL
issuer is not present, or easily discovered, from the target
certification path.  This can be the case when indirect CRLs are used,
when the certification Authority (CA) that issued the target certificate
changes its certificate signing key, or when the CA employs separate
keys for certificate signing and CRL signing.

Methods of finding the certificate of the CRL issuer are currently
available, such as though an accessible directory location or through
use of the Subject Information Access extension in intermediary CA
certificates.

Directory lookup requires existence and access to a directory that has
been populated with all of the necessary certificates.  The Subject
Information Access extension, which supports building the CRL issuer
certification path top-down (in the direction from the trust anchor to
the CRL issuer), requires that some certificates in the CRL issuer
certification path includes an appropriate Subject Information Access
extension.

RFC 3280 [PKIX1] provides for bottom-up discovery of certification paths
through the Authority Information Access extension, where the
id-ad-caIssuers access method may specify one or more accessLocation
fields that reference CA certificates associated with the certificate
containing this extension.

This document enables the use of the Authority Information Access
extension in CRLs, enabling a CRL checking application to use the access
method (id-ad-caIssuers) to locate certificates that may be useful in
the construction of a valid CRL issuer certification path to an
appropriate trust anchor.



Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 18 april 2005 13:41
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> Stefan,
> 
> > Denis,
> 
> > I will come back and comment on your text proposals, but before
that,
>  > a few questions/comments:
> 
> > <snip>
> 
> >>> You point out some well known issues related to the lack of
absolute
> >>> cryptographic binding between CRL and certificates where the
> >>> certificate and CRL is not signed by the same key.
> 
> >> Not really. It is indeed possible to have an absolute cryptographic
> >> binding between CRL and certificates where the certificate and CRL
is
> not
> >> signed by the same key, but the key point is that proposed
extension
>  >> is *not* the means to provide such a binding (and you agree with
this
>  >> further down in this e-mail).
> 
> > We agree that this extension does not add to the concept of
> > cryptographic binding. But how do you mean it can be done?
> 
> Would this mean that you believed this could not be done ? :-)
> 
> I already provided the information, but since at that time you were
> focussing on another issue, you probably missed the point.
> 
> I would encourage you to read again that thread, but I will provide a
> short
> reply here to your question.
> 
> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains
the
> DN
> of the CRL Issuer and we all know that CAs are free to assign the DNs
they
> wish. The next point is for a verifier to make sure that the DN which
> identifies the CRL Issuer (in the CRL DP) is indeed the one that was
meant
> by the CA. The CRL must be issued by a CRL Issuer that has the same
DN.
> The
> CRL Issuer will have a certificate issued by a CA.
> 
> Case a): the CA that has issued that certificate is the same as the CA
> that
> has issued the target certificate (which contains the hereabove
mentionned
> CRL DP). This is easy to check for a verifier since the verifier must
> first
> build the certification path and then test the revocation status of
every
> element of the path. So the verifier knows the validated sequence of
DNs
> starting from a self-signed certificate. It must then use the same
> sequence
> of DNs to validate the CRL Issuer certificate.
> 
> This is a general rule which does not require any extra local trust
> information.
> 
> Case b) : the CA that has issued that certificate is NOT the same as
the
> CA
> that has issued the target certificate. This case requires extra
*0local*
> trust information. There are many such trust conditions possible and
thus
> this cannot be defined in general. Cases a) and b) are thus not
equivalent
> and have to be distinguished.
> 
> > <snip>
> 
> >>>This draft only introduces a new way to locate certificates
> >>>that can be helpful in building this path.
> 
> >>At least one sentence of which we both agree !
> >>It should be copied and pasted in the abstract.
> 
> > Good, then I suggest that we leave unrelated topics out of this
draft
> > and focus on the issues that are related to this limited scope.
> 
> This is what I did in my proposal, except that we need to have a
security
> considerations section and the goal of that section is not to hide
> problems
> but to correctly warn users. Thus why an informatiove annex on the
topics
> mentionned in the security considerations section would be quite
useful.
> 
> In fact, its content would be along the lines of the explanations
which
> are
> just above.
> 
> I hope this e-mail will help us to progress.
> 
> Denis
> 
> > Stefan Santesson
> > Program Manager - Standards Liaison
> > Windows Security




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KFZwth073357; Wed, 20 Apr 2005 08:35:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KFZwEZ073356; Wed, 20 Apr 2005 08:35:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KFZt6V073343 for <[e-mail]>; Wed, 20 Apr 2005 08:35:56 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft6.fr.colt.net with ESMTP id j3KFZop02255 for <[e-mail]>; Wed, 20 Apr 2005 17:35:51 +0200
Message-ID: <[e-mail]>
Date: Wed, 20 Apr 2005 17:35:47 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050404
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate Policy OID registration
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Olivier Dubuisson wrote:

> If the explanations are not clear enough, I'll be happy to improve them.

They are probably clear enough, even if the UID method is present two 
times, but maybe it would be useful to add some more methods, for 
exemple national ones like in the AFNOR arc for french companies ?
http://asn1.elibel.tm.fr/cgi-bin/oid/display?oid=1.2.250.1&action=display




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KBuWE3009923; Wed, 20 Apr 2005 04:56:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KBuW5Q009922; Wed, 20 Apr 2005 04:56:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ncsusraimge05.jnj.com (ncsusraimge05.jnj.com [148.177.2.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KBuVON009853 for <[e-mail]>; Wed, 20 Apr 2005 04:56:32 -0700 (PDT) (envelope-from [e-mail])
Received: from ncsusrawsa6.na.jnj.com ([10.4.21.6]) by ncsusraimge05.jnj.com (Switch-3.1.7/Switch-3.1.7) with SMTP id j3KBuFcH008667; Wed, 20 Apr 2005 07:56:18 -0400 (EDT)
Received: from (10.4.20.170) by ncsusrawsa6.na.jnj.com via smtp id 53d2_0e0f02e2_b194_11d9_9857_0002b3ebca10; Wed, 20 Apr 2005 08:02:23 -0400 (EDT)
Received: by ncsusraexims2.na.jnj.com with Internet Mail Service (5.5.2658.3) id <24VVY41L>; Wed, 20 Apr 2005 07:56:14 -0400
Message-ID: <[e-mail]>
From: "Guida, Richard [JJCUS]" <[e-mail]>
To: Arshad Noor <[e-mail]>, [e-mail]
Subject: RE: Certificate Policy OID registration
Date: Wed, 20 Apr 2005 07:56:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2658.3)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5459F.F099BEEC"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This 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_01C5459F.F099BEEC
Content-Type: text/plain;
	charset="iso-8859-1"

Just FYI, Robert, the other alternative is to register your OID with ANSI
rather than IANA.  Each source has its advantages and disadvantages.  For
larger companies, ANSI may be better; for smaller ones, IANA should work
just fine.  But it is entirely your call.  We (J&J) used ANSI for our PKI.


Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  [phone]


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Arshad Noor
Sent: Tuesday, April 19, 2005 7:52 PM
To: [e-mail]
Subject: Re: Certificate Policy OID registration



http://www.iana.org/cgi-bin/enterprise.pl

Arshad Noor
StrongAuth, Inc.

Legendre, Robert wrote:
> Hi,
> 
>  
> 
> I have a quick question.  I am looking for more precise information for 
> registering Certificate Policy OID for companies.  I found this 
> mail-link while searching but it is a little old and the links in it no 
> longer function: 
> http://www.imc.org/ietf-pkix/old-archive-01/msg00613.html.   
> 
>  
> 
> It is not obvious to me where at www.ansi.org <http://www.ansi.org/> and 
> www.iana.org <http://www.iana.org/> this registration can be made.  Are 
> these still the two main authorities or has this changed in the last 
> couple of years?  Can someone provide me with more specific pointers?
> 
>  
> 
> Thanks,
> 
>  
> 
> Robert
> 
>  
> 
>  
> 
> ______________________________________________________________
> 
> Robert Legendre, P.Eng., CISSP
> 
> Principal Architect / Project Manager, RSA Professional Services
> 
>  
> 
>  
> 


------_=_NextPart_001_01C5459F.F099BEEC
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.88">
<TITLE>RE: Certificate Policy OID registration</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Just FYI, Robert, the other alternative is to =
register your OID with ANSI rather than IANA.&nbsp; Each source has its =
advantages and disadvantages.&nbsp; For larger companies, ANSI may be =
better; for smaller ones, IANA should work just fine.&nbsp; But it is =
entirely your call.&nbsp; We (J&amp;J) used ANSI for our =
PKI.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Richard A. Guida</FONT>
<BR><FONT SIZE=3D2>Director, Information Security</FONT>
</P>

<P><FONT SIZE=3D2>Johnson &amp; Johnson</FONT>
<BR><FONT SIZE=3D2>Room GS8217</FONT>
<BR><FONT SIZE=3D2>410 George Street</FONT>
<BR><FONT SIZE=3D2>New Brunswick, New Jersey&nbsp; 08901</FONT>
<BR><FONT SIZE=3D2>Phone:&nbsp; 732 524 3785</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail]</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail=
.imc.org</A>]On Behalf Of Arshad Noor</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 19, 2005 7:52 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Certificate Policy OID =
registration</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2><A HREF=3D"http://www.iana.org/cgi-bin/enterprise.pl" =
TARGET=3D"_blank">http://www.iana.org/cgi-bin/enterprise.pl</A></FONT>
</P>

<P><FONT SIZE=3D2>Arshad Noor</FONT>
<BR><FONT SIZE=3D2>StrongAuth, Inc.</FONT>
</P>

<P><FONT SIZE=3D2>Legendre, Robert wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</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 a quick question.&nbsp; I am looking for =
more precise information for </FONT>
<BR><FONT SIZE=3D2>&gt; registering Certificate Policy OID for =
companies.&nbsp; I found this </FONT>
<BR><FONT SIZE=3D2>&gt; mail-link while searching but it is a little =
old and the links in it no </FONT>
<BR><FONT SIZE=3D2>&gt; longer function: </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.imc.org/ietf-pkix/old-archive-01/msg00613.html" =
TARGET=3D"_blank">http://www.imc.org/ietf-pkix/old-archive-01/msg00613.h=
tml</A>.&nbsp;&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; It is not obvious to me where at www.ansi.org =
&lt;<A HREF=3D"http://www.ansi.org/" =
TARGET=3D"_blank">http://www.ansi.org/</A>&gt; and </FONT>
<BR><FONT SIZE=3D2>&gt; www.iana.org &lt;<A =
HREF=3D"http://www.iana.org/" =
TARGET=3D"_blank">http://www.iana.org/</A>&gt; this registration can be =
made.&nbsp; Are </FONT>
<BR><FONT SIZE=3D2>&gt; these still the two main authorities or has =
this changed in the last </FONT>
<BR><FONT SIZE=3D2>&gt; couple of years?&nbsp; Can someone provide me =
with more specific pointers?</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; Thanks,</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; Robert</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; =
______________________________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Robert Legendre, P.Eng., CISSP</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Principal Architect / Project Manager, RSA =
Professional Services</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>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5459F.F099BEEC--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K9rn4X043935; Wed, 20 Apr 2005 02:53:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K9rnqx043934; Wed, 20 Apr 2005 02:53:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from xenon1.telemat.um.es (mail.um.es [155.54.212.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K9rlfj043893 for <[e-mail]>; Wed, 20 Apr 2005 02:53:48 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by xenon1.telemat.um.es (Postfix) with ESMTP id 842011FA2E7 for <[e-mail]>; Wed, 20 Apr 2005 11:53:41 +0200 (CEST)
Received: from xenon1.telemat.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25554-01-72 for <[e-mail]>; Wed, 20 Apr 2005 11:53:41 +0200 (CEST)
Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by xenon1.telemat.um.es (Postfix) with SMTP id 576331FA2E4 for <[e-mail]>; Wed, 20 Apr 2005 11:53:41 +0200 (CEST)
Received: (qmail 5062 invoked from network); 20 Apr 2005 09:55:10 -0000
Received: from ycaro.dif.um.es (HELO ycaro) (155.54.210.68) by aries.dif.um.es with SMTP; 20 Apr 2005 09:55:10 -0000
Message-ID: <002a01c5458e$d8976440$[e-mail]>
Reply-To: "Manuel Gil Perez" <[e-mail]>
From: "Manuel Gil Perez" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Location of a CMC server
Date: Wed, 20 Apr 2005 11:53:45 +0200
Organization: ANTS Research Group
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear PKIX members,

I have configured my own Key Manager through CMC protocol. Now, I would like 
include the location of this server as a X.509 extension, but it is no set 
OID about this extension yet. I guess that this extension should be include 
like extension "Authority Information Access".

Is there any way of setting this server location inside one X.509 
certificate??

Best Regards,

------
Manuel Gil Pérez
http://pki.umu.euro6ix.org 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K8WvCA012880; Wed, 20 Apr 2005 01:32:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K8WvAo012879; Wed, 20 Apr 2005 01:32:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K8WsUp012831 for <[e-mail]>; Wed, 20 Apr 2005 01:32:55 -0700 (PDT) (envelope-from [e-mail])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 10:32:51 +0200
Received: from [10.193.106.115] ([10.193.106.115]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 10:32:51 +0200
Message-ID: <[e-mail]>
Date: Wed, 20 Apr 2005 10:32:50 +0200
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom - Research & Development
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Legendre, Robert" <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate Policy OID registration
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Apr 2005 08:32:51.0564 (UTC) FILETIME=[8A714AC0:01C54583]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Legendre, Robert wrote:
> 
> I have a quick question.  I am looking for more precise information for 
> registering Certificate Policy OID for companies.  I found this 
> mail-link while searching but it is a little old and the links in it no 
> longer function: 
> http://www.imc.org/ietf-pkix/old-archive-01/msg00613.html.   
> 
> It is not obvious to me where at www.ansi.org <http://www.ansi.org/> and 
> www.iana.org <http://www.iana.org/> this registration can be made.  Are 
> these still the two main authorities or has this changed in the last 
> couple of years?  Can someone provide me with more specific pointers?

Please have a look at Question 8 "How to get an OID assigned?" at:
http://asn1.elibel.tm.fr/oid/faq.htm#8

If the explanations are not clear enough, I'll be happy to improve them.
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K7puNi092933; Wed, 20 Apr 2005 00:51:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K7puPl092932; Wed, 20 Apr 2005 00:51:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtagate1.uk.ibm.com (mtagate1.uk.ibm.com [195.212.29.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K7ptaI092871 for <[e-mail]>; Wed, 20 Apr 2005 00:51:56 -0700 (PDT) (envelope-from [e-mail])
Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j3K7pbXJ160548 for <[e-mail]>; Wed, 20 Apr 2005 07:51:42 GMT
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3K7pbP6261934 for <[e-mail]>; Wed, 20 Apr 2005 08:51:37 +0100
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j3K7patm030956 for <[e-mail]>; Wed, 20 Apr 2005 08:51:37 +0100
Received: from d06ml721.portsmouth.uk.ibm.com (d06ml721.portsmouth.uk.ibm.com [9.149.36.162]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j3K7pav9030940; Wed, 20 Apr 2005 08:51:36 +0100
In-Reply-To: <[e-mail]>
To: Bob Wheeler <[e-mail]>
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Subject: Re: XML schema or dtd for X.509?
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
From: Martin Clausen <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 20 Apr 2005 09:51:35 +0200
X-MIMETrack: Serialize by Router on D06ML721/06/M/IBM(Release 6.53HF247 | January 6, 2005) at 20/04/2005 09:51:36, Serialize complete at 20/04/2005 09:51:36
Content-Type: multipart/alternative; boundary="=_alternative 002B2D1CC1256FE9_="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 002B2D1CC1256FE9_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Take a look at the following project.

http://www.trl.ibm.com/projects/xml/xss4j/docs/axt-readme.html

Med venlig hilsen / Kind regards

Martin Clausen <[e-mail]>
IBM Research GmbH, Zurich Research Laboratory
S=E4umerstrasse 4 / Postfach, CH-8803 R=FCschlikon
Phone: [phone]=20

[e-mail] wrote on 20-04-2005 06:26:58:

> Without starting a religious war, does anyone know of existing XML=20
> XSD or DTD specifications for X.509 certificates. Ideally, I'm=20
> looking for something that tracks closely to X.509 including the=20
> standard extensions and their contents. I'd appreciate any=20
> references or links to such specifications. I have seen some "toy"=20
> descriptions that barely describe basic certificates without any=20
> consideration of the standard extensions. Thanks.
>=20
> Bob
> Do you Yahoo!?
> Make Yahoo! your home page=20
--=_alternative 002B2D1CC1256FE9_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D2 face=3D"sans-serif">Take a look at the following project=
.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">http://www.trl.ibm.com/projects/xml/=
xss4j/docs/axt-readme.html</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Med venlig hilsen / Kind regards<br>
<br>
Martin Clausen &lt;[e-mail]&gt;<br>
IBM Research GmbH, Zurich Research Laboratory<br>
S=E4umerstrasse 4 / Postfach, CH-8803 R=FCschlikon<br>
Phone: [phone] </font>
<br>
<br><font size=3D2><tt>[e-mail] wrote on 20-04-2005 06:=
26:58:<br>
<br>
&gt; Without starting a religious war, does anyone know of existing XML
<br>
&gt; XSD or DTD specifications for X.509 certificates. Ideally, I'm <br>
&gt; looking for something that tracks closely to X.509 including the <br>
&gt; standard extensions and their contents. I'd appreciate any <br>
&gt; references or links to such specifications. I have seen some &quot;toy=
&quot;
<br>
&gt; descriptions that barely describe basic certificates without any <br>
&gt; consideration of the standard extensions. Thanks.</tt></font>
<br><font size=3D2><tt>&gt; &nbsp;</tt></font>
<br><font size=3D2><tt>&gt; Bob</tt></font>
<br><font size=3D2><tt>&gt; Do you Yahoo!?<br>
&gt; Make Yahoo! your home page </tt></font>
--=_alternative 002B2D1CC1256FE9_=--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K7TDdP081271; Wed, 20 Apr 2005 00:29:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K7TDKL081270; Wed, 20 Apr 2005 00:29:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from amos.eb2bcom.com (cust3103.vic01.dataco.com.au [202.63.62.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K7TBL1081190 for <[e-mail]>; Wed, 20 Apr 2005 00:29:12 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.1.156] (10.1.2.225) by amos.eb2bcom.com (7.1.016.1) (authenticated as steven.legg) id 4236430A00003225; Wed, 20 Apr 2005 17:39:22 +1000
Message-ID: <[e-mail]>
Date: Wed, 20 Apr 2005 17:29:01 +1000
From: Steven Legg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bob Wheeler <[e-mail]>
CC: [e-mail]
Subject: Re: XML schema or dtd for X.509?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

Bob Wheeler wrote:
> Without starting a religious war, does anyone know of existing XML XSD 
> or DTD specifications for X.509 certificates. Ideally, I'm looking for 
> something that tracks closely to X.509 including the standard extensions 
> and their contents. I'd appreciate any references or links to such 
> specifications. I have seen some "toy" descriptions that barely describe 
> basic certificates without any consideration of the standard extensions. 
> Thanks.

I've been working on a set of specifications for XML-enabling LDAP and
X.500 directories:

http://www.ietf.org/internet-drafts/draft-legg-xed-roadmap-03.txt

One aspect of this is a set of XML encoding rules for ASN.1 (RXER),
which allow me to encode any X.500 directory data in XML. This of
course encompasses X.509. Another aspect of more interest to you
is an algorithmic procedure for generating XML Schemas from ASN.1
modules. The XML Schemas validate the RXER encodings. I haven't yet
got around to writing up that procedure but I do have an implementation
of an ASN.1 to XML Schema translator. In time I will be publishing
the XML Schema translations for all the X.500 ASN.1 modules on-line,
but in the meantime I can wrap up my current set of XML Schemas and
send them to you if you are interested.

Bear in mind that this is still a work in progress. The translator
skimps on constraints, though it does handle occurrence constraints.

Regards,
Steven

>  
> Bob
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Make Yahoo! your home page 
> <http://us.rd.yahoo.com/my/navbar/sethp/*http://www.yahoo.com/r/hs>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K4R40b091905; Tue, 19 Apr 2005 21:27:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K4R4He091904; Tue, 19 Apr 2005 21:27:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from web60125.mail.yahoo.com (web60125.mail.yahoo.com [209.73.178.93]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3K4R3cZ091897 for <[e-mail]>; Tue, 19 Apr 2005 21:27:03 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 68769 invoked by uid 60001); 20 Apr 2005 04:26:58 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=bDy4IlfcKX1JXti67ggxZoES1ZdjNnqmWsyrJtfHjTXpMWquJpQSw53p8RWiROHUOe/JDN4GLryrTxmWvJc5uDhl6d/VXZkpE9l0Gpi/DjB45VKexV6e15TYlhOz3MDYWvGxmuR8ufeDSZmO+nN1YdB/t/+o2v4yLAjb7aPmc0E=  ;
Message-ID: <[e-mail]>
Received: from [68.100.84.178] by web60125.mail.yahoo.com via HTTP; Tue, 19 Apr 2005 21:26:58 PDT
Date: Tue, 19 Apr 2005 21:26:58 -0700 (PDT)
From: Bob Wheeler <[e-mail]>
Subject: XML schema or dtd for X.509?
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1168782551-1113971218=:68384"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0-1168782551-1113971218=:68384
Content-Type: text/plain; charset=us-ascii

Without starting a religious war, does anyone know of existing XML XSD or DTD specifications for X.509 certificates. Ideally, I'm looking for something that tracks closely to X.509 including the standard extensions and their contents. I'd appreciate any references or links to such specifications. I have seen some "toy" descriptions that barely describe basic certificates without any consideration of the standard extensions. Thanks.
 
Bob

		
---------------------------------
Do you Yahoo!?
 Make Yahoo! your home page   
--0-1168782551-1113971218=:68384
Content-Type: text/html; charset=us-ascii

<DIV>Without starting a religious war, does anyone know of existing XML XSD or DTD specifications for X.509 certificates. Ideally, I'm looking for something that tracks closely to X.509 including the standard extensions and their contents. I'd appreciate any references or links to such specifications. I have seen some "toy" descriptions that barely describe basic certificates without any consideration of the standard extensions. Thanks.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Bob</DIV><p>
		<hr size=1>Do you Yahoo!?<br> 
<a href="http://us.rd.yahoo.com/my/navbar/sethp/*http://www.yahoo.com/r/hs">Make Yahoo! your home page</a> 
 
 

--0-1168782551-1113971218=:68384--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JNqW8j004999; Tue, 19 Apr 2005 16:52:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JNqWRG004998; Tue, 19 Apr 2005 16:52:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JNqVCc004953 for <[e-mail]>; Tue, 19 Apr 2005 16:52:32 -0700 (PDT) (envelope-from [e-mail])
Received: from strongauth.com (adsl-63-197-11-13.dsl.snfc21.pacbell.net [63.197.11.13]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 19 Apr 2005 16:25:42 -0700 (PDT)
Date: Tue, 19 Apr 2005 16:52:17 -0700
From: Arshad Noor <[e-mail]>
Subject: Re: Certificate Policy OID registration
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
Organization: StrongAuth, Inc.
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

http://www.iana.org/cgi-bin/enterprise.pl

Arshad Noor
StrongAuth, Inc.

Legendre, Robert wrote:
> Hi,
> 
>  
> 
> I have a quick question.  I am looking for more precise information for 
> registering Certificate Policy OID for companies.  I found this 
> mail-link while searching but it is a little old and the links in it no 
> longer function: 
> http://www.imc.org/ietf-pkix/old-archive-01/msg00613.html.   
> 
>  
> 
> It is not obvious to me where at www.ansi.org <http://www.ansi.org/> and 
> www.iana.org <http://www.iana.org/> this registration can be made.  Are 
> these still the two main authorities or has this changed in the last 
> couple of years?  Can someone provide me with more specific pointers?
> 
>  
> 
> Thanks,
> 
>  
> 
> Robert
> 
>  
> 
>  
> 
> ______________________________________________________________
> 
> Robert Legendre, P.Eng., CISSP
> 
> Principal Architect / Project Manager, RSA Professional Services
> 
>  
> 
>  
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JMYqkn078863; Tue, 19 Apr 2005 15:34:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JMYqcg078862; Tue, 19 Apr 2005 15:34:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from tholian.rsasecurity.com (tholian.rsasecurity.com [216.162.240.129]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JMYp8g078847 for <[e-mail]>; Tue, 19 Apr 2005 15:34:51 -0700 (PDT) (envelope-from [e-mail])
Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with ESMTP; Tue, 19 Apr 2005 18:34:49 -0400
Received: from sdtihq24.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.12.10/NULL) with ESMTP id j3JMWoJX020125 for <[e-mail]>; Tue, 19 Apr 2005 18:32:50 -0400 (EDT)
Received: from rsana-ex-hq2.NA.RSA.NET (rsana-ex-hq2.securitydynamics.com [10.100.8.51]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id j3JMYnV5011538 for <[e-mail]>; Tue, 19 Apr 2005 18:34:49 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5452F.FEEB2014"
Subject: Certificate Policy OID registration
Date: Tue, 19 Apr 2005 18:34:47 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Certificate Policy OID registration
Thread-Index: AcVFL/2iNSgivvkLSEyiACDOPMB9Xw==
From: "Legendre, Robert" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5452F.FEEB2014
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

I have a quick question.  I am looking for more precise information for
registering Certificate Policy OID for companies.  I found this
mail-link while searching but it is a little old and the links in it no
longer function:
http://www.imc.org/ietf-pkix/old-archive-01/msg00613.html.  =20

=20

It is not obvious to me where at www.ansi.org <http://www.ansi.org/>
and www.iana.org <http://www.iana.org/>  this registration can be made.
Are these still the two main authorities or has this changed in the last
couple of years?  Can someone provide me with more specific pointers?

=20

Thanks,

=20

Robert

=20

=20

______________________________________________________________

Robert Legendre, P.Eng., CISSP

Principal Architect / Project Manager, RSA Professional Services

=20

=20


------_=_NextPart_001_01C5452F.FEEB2014
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (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";}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle17
	{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;}
-->
</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;
font-family:Arial'>Hi,</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I have a quick question. &nbsp;I am looking for more =
precise
information for registering Certificate Policy OID for companies. =
&nbsp;I found
this mail-link while searching but it is a little old and the links in =
it no
longer function: <a
href=3D"http://www.imc.org/ietf-pkix/old-archive-01/msg00613.html">http:/=
/www.imc.org/ietf-pkix/old-archive-01/msg00613.html</a>.&nbsp;
&nbsp;</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>It is not obvious to me where at <a
href=3D"http://www.ansi.org/">www.ansi.org</a> and <a =
href=3D"http://www.iana.org/">www.iana.org</a>
this registration can be made. &nbsp;Are these still the two main =
authorities
or has this changed in the last couple of years? &nbsp;Can someone =
provide me
with more specific pointers?</span></font></p>

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

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

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

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

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

<p class=3DMsoAutoSig style=3D'margin-left:.5in'><i><font size=3D1 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:7.0pt;font-family:Arial;color:black;
font-style:italic'>&nbsp;</span></font></i></p>

<p class=3DMsoAutoSig style=3D'margin-left:.5in'><i><font size=3D1 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:7.0pt;font-family:Arial;color:black;
font-style:italic'>______________________________________________________=
________</span></font></i></p>

<p class=3DMsoAutoSig style=3D'margin-left:.5in'><i><font size=3D1 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:7.0pt;font-family:Arial;color:black;
font-style:italic'>Robert Legendre, P.Eng., CISSP</span></font></i></p>

<p class=3DMsoAutoSig style=3D'margin-left:.5in'><i><font size=3D1 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:7.0pt;font-family:Arial;color:black;
font-style:italic'>Principal Architect / Project Manager, RSA =
Professional
Services</span></font></i></p>

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

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

</div>

</body>

</html>

------_=_NextPart_001_01C5452F.FEEB2014--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JITEiZ033584; Tue, 19 Apr 2005 11:29:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JITEvi033583; Tue, 19 Apr 2005 11:29:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from decibel.pvv.ntnu.no (decibel.pvv.ntnu.no [129.241.210.179]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3JITCC6033558 for <[e-mail]>; Tue, 19 Apr 2005 11:29:13 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 15210 invoked by uid 32454); 19 Apr 2005 18:29:10 -0000
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-00.txt
References: <[e-mail]>
From: Jostein Tveit <[e-mail]>
Organization: Norwegian University of Science and Technology
Date: Tue, 19 Apr 2005 20:29:10 +0200
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Fri, 15 Apr 2005 15:36:30 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some editorial comments to the draft.

Section 4.2.1.13
   include revocation information for all reasons.  This profile
   RECOMMENDS aginst segmenting CRLs by reason code.  When a conforming

Replace "aginst" with "against".

Section 5.1.2
   has issued.  The profile requires conforming CRL issuers include the
   nextUpdate field and the CRL number and authority key identifier CRL
   extensions in all CRLs issued.

missing "to".

Appendix C.  Examples

I think the "(xx as hex)" comments should be removed.
It is confusing, especially in C.4 where the serial number in hex
happens to be the same as the CRL number in decimal.

Regards,
-- 
Jostein Tveit <[e-mail]>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IJrUEd020522; Mon, 18 Apr 2005 12:53:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IJrUgG020521; Mon, 18 Apr 2005 12:53:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IJrTaQ020513 for <[e-mail]>; Mon, 18 Apr 2005 12:53:30 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24906; Mon, 18 Apr 2005 15:53:25 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc3770bis-02.txt
Date: Mon, 18 Apr 2005 15:53:25 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Certificate Extensions and Attributes Supporting 
			  Authentication in Point-to-Point Protocol (PPP) and 
			  Wireless Local Area Networks (WLAN)
	Author(s)	: R. Housley, T. Moore
	Filename	: draft-ietf-pkix-rfc3770bis-02.txt
	Pages		: 10
	Date		: 2005-4-18
	
This document defines two EAP extended key usage values and a public
   key certificate extension to carry Wireless LAN (WLAN) System Service
   identifiers (SSIDs).  This document obsoletes RFC 3770.

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

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


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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-rfc3770bis-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IDpQbM058017; Mon, 18 Apr 2005 06:51:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IDpQdH058016; Mon, 18 Apr 2005 06:51:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IDpMTG057984 for <[e-mail]>; Mon, 18 Apr 2005 06:51:24 -0700 (PDT) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA21776; Mon, 18 Apr 2005 16:05:39 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005041815510443:2814 ; Mon, 18 Apr 2005 15:51:04 +0200 
Message-ID: <[e-mail]>
Date: Mon, 18 Apr 2005 15:51:01 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Dave Engberg <[e-mail]>, [e-mail]
Subject: Re: CoreStreet IPR disclosure
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/04/2005 15:51:04, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/04/2005 15:51:06, Serialize complete at 18/04/2005 15:51:06
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I took a look and the full text of the patents is available at:

http://www.corestreet.com/patents.html

It would be interresting that CoreStreet indicates what kind of changes 
would be required to the draft so that no patent from CoreStreet is infringed.

Denis

> The IETF has posted CoreStreet's formal IPR disclosure regarding 
> implementations of the SCVP protocol and three of CoreStreet's 
> patents.  This includes an offer for reasonable and non-discriminatory 
> licensing if required by the final standard.  We fully support the 
> standardization and adoption of SCVP.  The full disclosure is 
> available here:

> http://www.ietf.org/ietf/IPR/corestreet-ipr-draft-ietf-pkix-scvp-18.txt

> Unlike some other PKI vendors, CoreStreet has never served a lawsuit 
> (patent or non) to any other party.  Our company's success stems from 
> our innovative implementations of open standards, which attempt to 
> address the security and scalability problems inherent in large PKIs.  
> We believe our SCVP products will be similarly competitive.

> Thanks,
> Dave Engberg
> Chief Technical Officer
> CoreStreet, Ltd.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IDgfrh056160; Mon, 18 Apr 2005 06:42:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IDgfKM056159; Mon, 18 Apr 2005 06:42:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IDgew8056136 for <[e-mail]>; Mon, 18 Apr 2005 06:42:40 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 14:42:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Mon, 18 Apr 2005 14:42:30 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on <draft-ietf-pkix-crlaia-00.txt>
Thread-Index: AcVEC4eLEdCIS+w6TdCnRyIMzkeQUwACaOSg
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 18 Apr 2005 13:42:36.0156 (UTC) FILETIME=[7AE57BC0:01C5441C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3IDgfw8056154
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Thanks for your effort to explain.

Yes I remember when you posted this a while back. I'll try to explain
what I mean.

We agree that IF you mandate that the CRL issuer has a certificate
issued by the CA which issued the target certificate (the certificate
being checked for validation), which is your case a), then you have a
strong binding between the cert and the CRL. It's not a direct
cryptographic binding between the certificate and the CRL object, but a
cryptographically secured attestation of the relation ship between the
CA and the CRL Issuer (which is good enough).

What I mean though, and we seem to agree on, is that you loose that
level cryptographic binding when you don't enforce strong path
relationship between the CRL path and the cert path.

But that problem lies with X.509 (and possibly with RFC 3280), and not
this draft. 

I will shortly get back on comments on your text proposals based on that
view.

>Stefan Santesson
>Program Manager - Standards Liaison
>Windows Security
 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 18 april 2005 13:41
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> Stefan,
> 
> > Denis,
> 
> > I will come back and comment on your text proposals, but before
that,
>  > a few questions/comments:
> 
> > <snip>
> 
> >>> You point out some well known issues related to the lack of
absolute
> >>> cryptographic binding between CRL and certificates where the
> >>> certificate and CRL is not signed by the same key.
> 
> >> Not really. It is indeed possible to have an absolute cryptographic
> >> binding between CRL and certificates where the certificate and CRL
is
> not
> >> signed by the same key, but the key point is that proposed
extension
>  >> is *not* the means to provide such a binding (and you agree with
this
>  >> further down in this e-mail).
> 
> > We agree that this extension does not add to the concept of
> > cryptographic binding. But how do you mean it can be done?
> 
> Would this mean that you believed this could not be done ? :-)
> 
> I already provided the information, but since at that time you were
> focussing on another issue, you probably missed the point.
> 
> I would encourage you to read again that thread, but I will provide a
> short
> reply here to your question.
> 
> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains
the
> DN
> of the CRL Issuer and we all know that CAs are free to assign the DNs
they
> wish. The next point is for a verifier to make sure that the DN which
> identifies the CRL Issuer (in the CRL DP) is indeed the one that was
meant
> by the CA. The CRL must be issued by a CRL Issuer that has the same
DN.
> The
> CRL Issuer will have a certificate issued by a CA.
> 
> Case a): the CA that has issued that certificate is the same as the CA
> that
> has issued the target certificate (which contains the hereabove
mentionned
> CRL DP). This is easy to check for a verifier since the verifier must
> first
> build the certification path and then test the revocation status of
every
> element of the path. So the verifier knows the validated sequence of
DNs
> starting from a self-signed certificate. It must then use the same
> sequence
> of DNs to validate the CRL Issuer certificate.
> 
> This is a general rule which does not require any extra local trust
> information.
> 
> Case b) : the CA that has issued that certificate is NOT the same as
the
> CA
> that has issued the target certificate. This case requires extra
*0local*
> trust information. There are many such trust conditions possible and
thus
> this cannot be defined in general. Cases a) and b) are thus not
equivalent
> and have to be distinguished.
> 
> > <snip>
> 
> >>>This draft only introduces a new way to locate certificates
> >>>that can be helpful in building this path.
> 
> >>At least one sentence of which we both agree !
> >>It should be copied and pasted in the abstract.
> 
> > Good, then I suggest that we leave unrelated topics out of this
draft
> > and focus on the issues that are related to this limited scope.
> 
> This is what I did in my proposal, except that we need to have a
security
> considerations section and the goal of that section is not to hide
> problems
> but to correctly warn users. Thus why an informatiove annex on the
topics
> mentionned in the security considerations section would be quite
useful.
> 
> In fact, its content would be along the lines of the explanations
which
> are
> just above.
> 
> I hope this e-mail will help us to progress.
> 
> Denis
> 
> > Stefan Santesson
> > Program Manager - Standards Liaison
> > Windows Security




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IBgE8e022295; Mon, 18 Apr 2005 04:42:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IBgEMu022294; Mon, 18 Apr 2005 04:42:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IBg65r022176 for <[e-mail]>; Mon, 18 Apr 2005 04:42:11 -0700 (PDT) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA18014; Mon, 18 Apr 2005 13:55:57 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005041813412375:2689 ; Mon, 18 Apr 2005 13:41:23 +0200 
Message-ID: <[e-mail]>
Date: Mon, 18 Apr 2005 13:41:22 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Russ Housley <[e-mail]>, pkix <[e-mail]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/04/2005 13:41:23, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/04/2005 13:41:25, Serialize complete at 18/04/2005 13:41:25
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

> Denis,

> I will come back and comment on your text proposals, but before that, 
 > a few questions/comments:

> <snip>

>>> You point out some well known issues related to the lack of absolute
>>> cryptographic binding between CRL and certificates where the
>>> certificate and CRL is not signed by the same key.

>> Not really. It is indeed possible to have an absolute cryptographic
>> binding between CRL and certificates where the certificate and CRL is not
>> signed by the same key, but the key point is that proposed extension 
 >> is *not* the means to provide such a binding (and you agree with this
 >> further down in this e-mail).

> We agree that this extension does not add to the concept of
> cryptographic binding. But how do you mean it can be done?

Would this mean that you believed this could not be done ? :-)

I already provided the information, but since at that time you were 
focussing on another issue, you probably missed the point.

I would encourage you to read again that thread, but I will provide a short 
reply here to your question.

This can be done using cRLIssuer from the CRL DP. cRLIssuer contains the DN 
of the CRL Issuer and we all know that CAs are free to assign the DNs they 
wish. The next point is for a verifier to make sure that the DN which 
identifies the CRL Issuer (in the CRL DP) is indeed the one that was meant 
by the CA. The CRL must be issued by a CRL Issuer that has the same DN. The 
CRL Issuer will have a certificate issued by a CA.

Case a): the CA that has issued that certificate is the same as the CA that 
has issued the target certificate (which contains the hereabove mentionned 
CRL DP). This is easy to check for a verifier since the verifier must first 
build the certification path and then test the revocation status of every 
element of the path. So the verifier knows the validated sequence of DNs 
starting from a self-signed certificate. It must then use the same sequence 
of DNs to validate the CRL Issuer certificate.

This is a general rule which does not require any extra local trust information.

Case b) : the CA that has issued that certificate is NOT the same as the CA 
that has issued the target certificate. This case requires extra *0local* 
trust information. There are many such trust conditions possible and thus 
this cannot be defined in general. Cases a) and b) are thus not equivalent 
and have to be distinguished.

> <snip>

>>>This draft only introduces a new way to locate certificates
>>>that can be helpful in building this path.

>>At least one sentence of which we both agree !
>>It should be copied and pasted in the abstract.

> Good, then I suggest that we leave unrelated topics out of this draft
> and focus on the issues that are related to this limited scope.

This is what I did in my proposal, except that we need to have a security 
considerations section and the goal of that section is not to hide problems 
but to correctly warn users. Thus why an informatiove annex on the topics 
mentionned in the security considerations section would be quite useful.

In fact, its content would be along the lines of the explanations which are 
just above.

I hope this e-mail will help us to progress.

Denis

> Stefan Santesson
> Program Manager - Standards Liaison
> Windows Security



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FJaYVC001364; Fri, 15 Apr 2005 12:36:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FJaYGD001363; Fri, 15 Apr 2005 12:36:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FJaWoO001356 for <[e-mail]>; Fri, 15 Apr 2005 12:36:33 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09042; Fri, 15 Apr 2005 15:36:30 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-00.txt
Date: Fri, 15 Apr 2005 15:36:30 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Certificate 
			  and Certificate Revocation List (CRL) Profile
	Author(s)	: D. Cooper, et al.
	Filename	: draft-ietf-pkix-rfc3280bis-00.txt
	Pages		: 138
	Date		: 2005-4-15
	
This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
   Revocation List (CRL) for use in the Internet.  An overview of this
   approach and model are provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.  A set of required
   certificate extensions is specified.  The X.509 v2 CRL format is
   described in detail, and required extensions are defined.  An
   algorithm for X.509 certification path validation is described.  An
   ASN.1 module and examples are provided in the appendices.

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

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


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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FGf5kQ089929; Fri, 15 Apr 2005 09:41:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FGf4Vv089875; Fri, 15 Apr 2005 09:41:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FGeqWZ089764 for <[e-mail]>; Fri, 15 Apr 2005 09:40:57 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3FGeln16749; Fri, 15 Apr 2005 18:40:48 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Fri, 15 Apr 2005 18:40:48 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3FGek004324; Fri, 15 Apr 2005 18:40:46 +0200 (MEST)
Date: Fri, 15 Apr 2005 18:40:46 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Recommendation: create a module containing only PKIX
> constant definitions (OIDs, bounds, etc).  Start importing
> it into other modules as they are revised for other reasons.

I think that is a good idea for an update of 3280.

And then this means that we will have an update of 3370bis :-)

I think I'll get a beer now. :-) 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FGUZf9087742; Fri, 15 Apr 2005 09:30:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FGUZ9x087741; Fri, 15 Apr 2005 09:30:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FGUXit087735 for <[e-mail]>; Fri, 15 Apr 2005 09:30:34 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3FGUMn16599; Fri, 15 Apr 2005 18:30:22 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Fri, 15 Apr 2005 18:30:22 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3FGUMw04316; Fri, 15 Apr 2005 18:30:22 +0200 (MEST)
Date: Fri, 15 Apr 2005 18:30:22 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

in addition to what I just said.
It seems that some mail from me got lost somewhere.


> 
> Peter:
> 
> You are the one that complained that there was not discussion of the key 
> usage extension.  I am happy to delete the whole paragraph ... you are the 
> one who asked for the topic to be covered.
> 
> How about this:
> 
>     If a certificate contains a key usage extension, the KeyUsage bits
>     that are needed depends on the EAP method that is employed.
> 
> Russ
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FGLKQF086689; Fri, 15 Apr 2005 09:21:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FGLKPF086688; Fri, 15 Apr 2005 09:21:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FGLIfD086681 for <[e-mail]>; Fri, 15 Apr 2005 09:21:19 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3FGKnn16212; Fri, 15 Apr 2005 18:20:49 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Fri, 15 Apr 2005 18:20:49 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3FGKm004293; Fri, 15 Apr 2005 18:20:48 +0200 (MEST)
Date: Fri, 15 Apr 2005 18:20:48 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Peter:
> 
> You are the one that complained that there was not discussion of the key 
> usage extension.  I am happy to delete the whole paragraph ... you are the 
> one who asked for the topic to be covered.

Your name is not Bismarck, and this is not the Emser Depesche. :-)

  I have 'remarked' that there was no discussion of keyUsage in your text.

  You have introduced a restriction that was not in 3370. 

  Since both versions of your proposals seem wrong to me I had already
proposed to delete the second half of the sentence that talks about
keyusages of crlsign or keyCertSign.  

I also had asked whether it is true that 'Currently no EAP methods require
keyCertSign or crlSign'. I have the feeling that this is what you wanted
to express. 

> How about this:
> 
>     If a certificate contains a key usage extension, the KeyUsage bits
>     that are needed depends on the EAP method that is employed.
> 
> Russ

This text is what I had proposed to you yesterday in a reponse that 
didn't went to the list since you did not answered the question above
(unless I have missed it). 

I can live with an with that.

Peter



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FFkpuj084050; Fri, 15 Apr 2005 08:46:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FFkp2r084049; Fri, 15 Apr 2005 08:46:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3FFko7w084043 for <[e-mail]>; Fri, 15 Apr 2005 08:46:50 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 25367 invoked by uid 0); 15 Apr 2005 15:06:13 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.4.116) by woodstock.binhost.com with SMTP; 15 Apr 2005 15:06:13 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Fri, 15 Apr 2005 11:03:46 -0400
To: "Dave Engberg" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: CoreStreet IPR disclosure
In-Reply-To: <[e-mail] treet.com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
Dave:<br><br>
I am confused by the IPR disclosure.&nbsp; SCVP includes two major
feature sets: DPD and DPV.&nbsp; A quick skim of the patents indicate
that they are related to DPV.&nbsp; (I am not a lawyer, and I am not
trying to play one here.)&nbsp; If this is correct, then I am not sure
what CoreStreet is promising.<br><br>
Russ<br><br>
<br>
At 03:08 PM 4/11/2005, Dave Engberg wrote:<br>
<blockquote type=cite class=cite cite="">&nbsp;<br>
<font face="arial" size=2>The IETF has posted CoreStreet's formal IPR
disclosure regarding implementations of the SCVP protocol and three of
CoreStreet's patents.&nbsp; This includes an offer for reasonable and
non-discriminatory licensing if required by the final standard.&nbsp; We
fully support the standardization and adoption of SCVP.&nbsp; The full
disclosure is available here:<br>
</font>&nbsp;<br>
<font face="arial" size=2>&nbsp;&nbsp;&nbsp;
<a href="http://www.ietf.org/ietf/IPR/corestreet-ipr-draft-ietf-pkix-scvp-18.txt">
http://www.ietf.org/ietf/IPR/corestreet-ipr-draft-ietf-pkix-scvp-18.txt</a>
<br>
</font>&nbsp;<br>
<font face="arial" size=2>Unlike some other PKI vendors, CoreStreet has
never served a lawsuit (patent or non) to any other party.&nbsp; Our
company's success stems from our innovative implementations of open
standards, which attempt to address the security and scalability problems
inherent in large PKIs.&nbsp; We believe our SCVP products will be
similarly competitive.<br>
</font>&nbsp;<br>
<font face="arial" size=2>Thanks,<br>
Dave Engberg<br>
Chief Technical Officer<br>
CoreStreet, Ltd.<br>
</font>&nbsp;</blockquote></body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FFINJP081842; Fri, 15 Apr 2005 08:18:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FFINoK081841; Fri, 15 Apr 2005 08:18:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3FFIMhb081834 for <[e-mail]>; Fri, 15 Apr 2005 08:18:22 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 16797 invoked by uid 0); 15 Apr 2005 14:38:56 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.14.33) by woodstock.binhost.com with SMTP; 15 Apr 2005 14:38:56 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Fri, 15 Apr 2005 10:38:24 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

You are the one that complained that there was not discussion of the key 
usage extension.  I am happy to delete the whole paragraph ... you are the 
one who asked for the topic to be covered.

How about this:

    If a certificate contains a key usage extension, the KeyUsage bits
    that are needed depends on the EAP method that is employed.

Russ

At 04:10 AM 4/15/2005, Peter Sylvester wrote:

> > >
> > >take a cert with all bit on. This is equivalent to having no keyUsage 
> at all
> > >as far as I remember. in this case the keyCertSign bit and the cRLSign 
> are
> > >set,
> > >and the above 'MUST NOT' prohibits use of this cert. is this what you 
> intend?
> > >I don't think so.
> > >
> > >Isn't the right wording: no known EAP usage requires keyCertSign or 
> cRLSign?
> >
> > How about: ... however, EAP methods MUST NOT require the keyCertSign bit or
> > the cRLSign to be set in end entity certificates.
>
>
>- the initial text had no keyUsage restriction.
>
>- the current has a restriction that technically doesn't make any
>   sense and is incompatible with the standard.
>
>- Above you propose something that is a restriction for EAP methods
>   which was not in 3770. Can you justify this change, please.
>
>
>Peter
>PS: Would it be possible to instruct your mail user agent not to send
>me two copies just because I am twice in the To list, or else. Thanks



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FEF28D077624; Fri, 15 Apr 2005 07:15:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FEF21D077623; Fri, 15 Apr 2005 07:15:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FEF2dA077603 for <[e-mail]>; Fri, 15 Apr 2005 07:15:02 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 15 Apr 2005 10:14:47 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Apr 2005 14:14:55.0768 (UTC) FILETIME=[7FC18980:01C541C5]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester wrote:

>We are not etalking about pains created by difficulties of correct
>organisation of ASN.1 modules or using current and non-obsolete syntax
>versions.
>  
>

This gets to the real problem.  If the entire pkix OID registry
(http://www.imc.org/ietf-pkix/pkix-oid.asn) were maintained
as an ASN.1 module and always IMPORTed, this would
eliminate problems caused by importing modules containing both
structures and OIDs when only the OIDs are needed.

Given that there is not yet a "pkix-useful-definitions" module, Russ'
strategy of local definitions is a reasonable workaround:

1) an OID, once assigned, can never change so there is no danger
of an initially-correct copy getting out of sync with the original.
(An OID can be deprecated, but its meaning cannot be modified.)

2) the name assigned to an OID has only local scope, and
many names can be assigned to the same OID without causing
problems (other than confusing readers).   One module can
locally define "id-bogus-aca"  and use that name within the module
and still interoperate successfully with a different module
that IMPORTs "id-aca" from PKIXAttributeCertificate.

Recommendation: create a module containing only PKIX
constant definitions (OIDs, bounds, etc).  Start importing
it into other modules as they are revised for other reasons.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FAs7bk031946; Fri, 15 Apr 2005 03:54:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FAs7Lh031945; Fri, 15 Apr 2005 03:54:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FAs3f7031895 for <[e-mail]>; Fri, 15 Apr 2005 03:54:04 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 11:54:27 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Fri, 15 Apr 2005 11:53:55 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on <draft-ietf-pkix-crlaia-00.txt>
Thread-Index: AcVAyX3Ui4Yj/r7gTGS3E8JSSTn8EwA3bvgQ
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 15 Apr 2005 10:54:27.0126 (UTC) FILETIME=[7E206D60:01C541A9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3FAs4f7031926
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I will come back and comment on your text proposals, but before that, a
few questions/comments:

<snip>
> > You point out some well known issues related to the lack of absolute
> > cryptographic binding between CRL and certificates where the
certificate
> > and CRL is not signed by the same key.
> 
> Not really. It is indeed possible to have an absolute cryptographic
> binding
> between CRL and certificates where the certificate and CRL is not
signed
> by
> the same key, but the key point is that proposed extension is *not*
the
> means to provide such a binding (and you agree with this further down
in
> this e-mail).

We agree that this extension does not add to the concept of
cryptographic binding. But how do you mean it can be done?

<snip>
> > This draft only introduces a new way to locate certificates
> > that can be helpful in building this path.
> 
> At least one sentence of which we both agree !
> It should be copied and pasted in the abstract.

Good, then I suggest that we leave unrelated topics out of this draft
and focus on the issues that are related to this limited scope.


Stefan Santesson
Program Manager - Standards Liaison
Windows Security
 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 14 april 2005 10:10
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> Stefan,
> 
> > Denis,
> 
> > Thanks for spending considerable time to comment on this draft.
> 
> > The typo is noted and will be fixed.
> 
> Thank you so much, for accepting to correct the typo. :-|
> 
> > Some generic comments before we go into the specific text proposals:
> 
> > You point out some well known issues related to the lack of absolute
> > cryptographic binding between CRL and certificates where the
certificate
> > and CRL is not signed by the same key.
> 
> Not really. It is indeed possible to have an absolute cryptographic
> binding
> between CRL and certificates where the certificate and CRL is not
signed
> by
> the same key, but the key point is that proposed extension is *not*
the
> means to provide such a binding (and you agree with this further down
in
> this e-mail).
> 
> The proposed extension is simply a means to find a possible
certificate
> candidates, but not a means to make sure that the candidate is
acceptable.
> 
> > A certificate is always authoritative to identify the correct CRL
for
> > its validation.
> 
> While this is true in general, this is not always true. When indirect
CRLs
> are used, a directly trusted CRL Issuer may be used. For other cases,
your
> statement is correct.
> 
>  > But since the certificate is signed before the latest
> > CRL that validates it, the certificate can't cryptographically bind
> > (e.g. hash) the CRL but needs to identify it by verifiable
attributes
> > such as issuer name and storage location.
> 
> As you say, only issuer name or location may be used. Location cannot
be
> used as this has been demonstrated in the previous e-mail, since a
network
> attack could be performed. So only the issuer name can be used. Let us
> look,
> how:
> 
> The CRL DP extension is defined as:
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     DistributionPointName
OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
> Secure binding may be obtained using cRLIssuer where
> 
> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
> 
> with
> 
> GeneralName ::= CHOICE {
>       otherName                       [0]     AnotherName,
>       rfc822Name                      [1]     IA5String,
>       dNSName                         [2]     IA5String,
>       x400Address                     [3]     ORAddress,
>       directoryName                   [4]     Name,
>       ediPartyName                    [5]     EDIPartyName,
>       uniformResourceIdentifier       [6]     IA5String,
>       iPAddress                       [7]     OCTET STRING,
>       registeredID                    [8]     OBJECT IDENTIFIER }
> 
> where    Name ::= CHOICE {
>       RDNSequence }
> 
> RFC 3280 states:
> 
>    " If the certificate issuer is not the CRL Issuer, then the
cRLIssuer
>      field MUST be present and contain the Name of the CRL issuer".
> 
> A name is uniquely assigned to an entity, only if the name of the CA
which
> has allocated it is known. Recursively, the DN of that CA is uniquely
> assigned to an entity, only if the DN of the CA which has allocated
that
> DN
> it is known. This process ends up until the trust anchor that has
issued
> the
> first CA certificate of the certification path is known.
> 
> > This issue is however NOT introduced by this draft. It is simply a
> > generic issue with RFC 3280/X.509, especially for indirect CRLs
> 
> > In this context I really can't see the difference between scenario A
and
> > scenario B. It seems to me that the same validation principles apply
to
> > both scenarios.
> 
> Not exactly. From what is said above, it can be said that cRLIssuer DN
has
> been uniquely assigned to that entity, if it is known that this DN has
> been
> issued by the CA that has issued the target certificate. This is
scenario
> A
> which means that the trust conditions from the relying party are
simple
> and
> well known.
> 
> The problem is that with scenario B, no document provides the trust
> conditions to be used by the relying party and that there can be many
> different trust conditions, some of them may be secure, while some of
them
> may be insecure depending upon the context.
> 
> This is why it is important to make a difference between scenario A
and B.
> 
> > Section 6.3 of RFC 3280 is dealing with CRL validation and the
> > requirement to validate the CRL through a valid certificate path.
> 
>   ... but that section is lacking of further details that would allow
two
> different imlplementations to end up with the same result.
> 
> > This draft only introduces a new way to point to locate certificates
> > that can be helpful in building this path.
> 
> At least one sentence of which we both agree !
> It should be copied and pasted in the abstract.
> 
>  > It seems to me from that
> > perspective that specific requirements on CRL path building are
outside
> > the scope of this draft.
> 
> Since scenario B has so many possible options, it is not possible to
cover
> all of them and the intent is not to describe and prescribe all of
them.
> However, scenarion A is much simpler and may be described.
> 
> I have many problems with the current introduction. I am restating my
> previous proposal for a revised introduction along the lines that
"this
> draft only introduces a new way to point to locate certificates that
can
> be
> helpful in building this path". If you have problems with that text,
> please
> propose revisions to it. If you can live with it, then we are solved
with
> the introduction.
> 
> 
>     RFC 3280 [PKIX1] specifies the validation of certification paths.
>     One aspect involves the determination that a certificate has not
been
>     revoked, and one revocation checking mechanism is the Certificate
>     Revocation List (CRL). Checking a CRL when the CRL is signed by
the
>     key of the Issuing CA is straightforward, but not necessarily
>     otherwise.
> 
>     There are several legitimate scenarios where the certificate of
the
>     CRL issuer is not present, or easily discovered.
> 
>     Standardized methods of finding the certificate of the CRL issuer
are
>     currently available either though an accessible directory location
or
>     through use of the Subject Information Access extension in
>     intermediary CA certificates.
> 
>     Directory lookup requires presence and access to a directory.  The
>     Subject Information Access extension supports building
certification
>     paths top-down (in the direction from the trust anchor to the CRL
>     issuer), which will succeed if certificates include an appropriate
>     Subject Information Access extension. Additional methods allowing
>     the building of certification paths bottom-up to validate CRLs
>     may be useful as well. This is the topic of this document.
> 
>     RFC 3280 [PKIX1] has provided for bottom-up discovery of
>     certification paths through the Authority Information Access
>     extension, where the id-ad-caIssuers access method may specify one
or
>     more accessLocation fields that contain references to CA
certificates
>     superior to the certificate containing this extension.
> 
>     This document permits use of the Authority Information Access
>     extension in CRLs, enabling a CRL checking application to use the
>     same access method (id-ad-caIssuers) to locate the certificate of
>     the CRL issuer and complete the certification path building to an
>     appropriate trust anchor.
> 
>     This extension may be used in the case when indirect CRLs are
used,
>     when the certification Authority (CA) that issued the CRL
certificate
>     changes its certificate signing key, or when the CA employs
separate
>     keys for certificate signing and CRL signing.
> 
> 
> Now the security considerations section still contains incorrect text.
> I have revised my previous proposal. If you have problems with that
text,
> please propose revisions to it. If you can live with it, then we are
> solved with section 3.
> 
> 3  Security Considerations
> 
>       Implementers should take into account the possible existence of
>       multiple unrelated CAs and CRL issuers with the same DN, as well
>       as the possibility for some trusted CAs (i.e. trusted to issue
>       their own certificates and associated revocation status
information
>       but not trusted not handle revocation information from other
CAs)
>       to purposely use URLs or CRL DPs identical to some CRL DPs from
>       other CAs and at the same time mounting a re-routing attack.
> 
>       This means that finding a CA certificate at the location
indicated
>       by this new extension is insufficient to make sure that it is
the
>       right one, and by consequence that the CRL where this extension
>       has been found is also the right one.
> 
>       When the CRL is a direct CRL, relying parties shall make sure
>       that the certificate of the CRL issuer has been issued by the
same
>       CA that has issued the target certificate.
> 
>       When the CRL contains the indirectCRL boolean set to TRUE,
>       relying parties should locally know the URL of the CRL issuer(s)
>       that they directly trust and use local trust conditions to make
>       sure that the CRL that has been retrieved has indeed be issued
>       by a directly trusted CRL Issuer. In particular, care should be
> taken
>       in case two CAs would be using the same DN for two different
CAs.
> 
>       Implementers should always take the steps of validating the
>       retrieved data to ensure that the data is properly formed.
> 
> 
> Indeed, more could be said about indirect CRLs, so if you want to add
some
> more text, please do it.
> 
> Denis
> 
> >>Stefan Santesson
> >>Program Manager - Standards Liaison
> >>Windows Security
> >
> >
> >
> >>-----Original Message-----
> >>From: [e-mail]
> >
> > [mailto:[e-mail]]
> >
> >>On Behalf Of Denis Pinkas
> >>Sent: den 11 april 2005 00:59
> >>To: Stefan Santesson; Russ Housley
> >>Cc: pkix
> >>Subject: Comments on <draft-ietf-pkix-crlaia-00.txt>
> >>
> >>
> >>Stefan and Russ,
> >>
> >>It took me several hours to write this long e-mail, hence for the
> >
> > delay
> >
> >>(in addition to the time for shooting a few "big five" with my
> >
> > camera).
> >
> >>This e-mail identifies several security issues, which are not
> >
> > currently
> >
> >>mentionned in the security considerations section. It finally
proposes
> >
> > a
> >
> >>rewritting of the introduction and provides a strawman for a new
> >
> > security
> >
> >>considerations section (see the proposal at the end of this e-mail).
> >>
> >>Let us consider two different scenarios where this new extension
would
> >
> > be
> >
> >>considered.
> >>
> >>Scenario A: The relying party does not trust any CRL issuer in
> >
> > particular
> >
> >>and will simply use the CRL Issuer designated by the Certificate
> >
> > Issuer by
> >
> >>means of the CRL DP extension.
> >>
> >>Scenario B: The relying party trusts at least a specific CRL issuer
> >
> > and
> >
> >>will
> >>get the CRLs from that CRL Issuer and then will make sure that the
> >>information contained in them matches with the designation of the
> >>Certificate Issuer.
> >>
> >>SCENARIO A
> >>
> >>In scenario A, the relying party will use the CRL DP from the target
> >>certificate to get the CRL and then will make sure that the CRL that
> >
> > has
> >
> >>been retrieved from that location is signed by the right CRL Issuer.
> >>
> >>The CRL DP extension is defined as:
> >>
> >>    DistributionPoint ::= SEQUENCE {
> >>         distributionPoint       [0]     DistributionPointName
> >
> > OPTIONAL,
> >
> >>         reasons                 [1]     ReasonFlags OPTIONAL,
> >>         cRLIssuer               [2]     GeneralNames OPTIONAL }
> >>
> >>At least the distributionPoint field shall be present. It is
supposed
> >
> > it
> >
> >>contains a general name of type URI, which is a pointer to the
current
> >
> > CRL
> >
> >>for the associated reasons and will be issued by the associated
> >
> > cRLIssuer.
> >
> >>The CRL itself shall contain an IDP (Issuing Distribution Point).
> >>
> >>The IDP extension is defined as:
> >>
> >>    issuingDistributionPoint ::= SEQUENCE {
> >>         distributionPoint          [0] DistributionPointName
> >
> > OPTIONAL,
> >
> >>         onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
> >>         onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
> >>         onlySomeReasons            [3] ReasonFlags OPTIONAL,
> >>         indirectCRL                [4] BOOLEAN DEFAULT FALSE,
> >>         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
> >>
> >>A necessary but insufficient condition is that the distributionPoint
> >
> > field
> >
> >>from the IDP extension shall be equal to the distributionPoint field
> >
> > from
> >
> >>the CRL DP extension.
> >>
> >>This is insufficient since a URL like
> >
> > URL=http://corppki/crl/extranet.crl
> >
> >>could be used by accident by two different CAs, or a CA under the
same
> >>root
> >>key could maliciously use that URL or a different and re-route all
> >
> > packets
> >
> >>to an address where that CRL is made available.
> >>
> >>This means that the tupple CRL DP extension from certificates and
the
> >
> > IDP
> >
> >>extension from CRLs even if then match are insufficient to make sure
> >
> > that
> >
> >>it
> >>is the right CRL that has been retrieved. This is "normal" until
some
> >>cryptographic checksums are used to make sure that this is the right
> >>information.
> >>
> >>Any CA, trusted under a root key, could use an IDP extension in a
CRL
> >>matching the IDP extension from another true CRL and unless other
> >
> > tests
> >
> >>are
> >>performed, would fool relying parties.
> >>
> >>This is the major reason why the current document in its current
form
> >
> > is
> >
> >>dangerous to be published. It incorporates verification concepts
which
> >
> > are
> >
> >>missing major security issues. The security consideration section
> >
> > attempts
> >
> >>to tackle the issue but it misses the point.
> >>
> >>The major problem is not the definition of this new extension that
> >
> > could
> >
> >>provide untrusted but "useful" information, but the concepts behind
> >
> > path
> >
> >>construction.
> >>
> >>SCENARIO B
> >>
> >>In scenario B, the relying party contacts the location of a trusted
> >
> > CRL
> >
> >>Issuer and wants to verify that the retrieved CRL is correctly
signed.
> >>
> >>Suppose that the retrieved CRL contains the newly defined extension
> >
> > which
> >
> >>specifies one or more accessLocation fields that contains references
> >
> > to CA
> >
> >>certificates superior to the CRL containing this extension.
> >>
> >>Let us consider that one accessLocation field contains the following
> >
> > URL:
> >
> >>http://corppki/aia/certificates.crt
> >>
> >>The relying party will access this URL to retrieve some CA
> >
> > certificates.
> >
> >>Nothing at this point would prevent a network attack so that access
to
> >>this
> >>URL is re-routed to another location. The question is how the
relying
> >>party
> >>can figure out and what kind of tests it should make. The draft is
> >
> > silent
> >
> >>about this.
> >>
> >>It does not help the end-user to define new extensions if at the
same
> >
> > time
> >
> >>there are no explanations or guidance to tell how are they should be
> >
> > used
> >
> >>in
> >>order to build a secure system.
> >>
> >>Let us suppose that the information retrieved is just "useful"
> >>certificates
> >>at this time (i.e. untrusted).
> >>
> >>In order to build a path, a relying party needs to make sure of the
> >
> > name
> >
> >>of
> >>the CRL Issuer, which means not simply knowing the DN of the CRL
> >
> > issuer
> >
> >>but
> >>also all the other DNs from the upper CAs up to a root key. This
kind
> >
> > of
> >
> >>assumption or explanations is currently missing in the draft.
> >>
> >>Scenario B would be correctly supported if the text would mention
two
> >>points:
> >>
> >>    1) the location of the "trusted CRL Issuer" must be locally
known,
> >>    2) the name of the "trusted CRL Issuer" must be locally known,
> >>       which means not simply knowing the DN of the CRL issuer,
> >>       but also all the other DNs from the upper CAs up to a root
key.
> >>
> >>Using the "useful" certificates that would be retrieved using that
new
> >>extension, the relying party would then build a certification path
to
> >>validate the retrieved CRL. Additional details, described nowhere,
> >
> > should
> >
> >>be
> >>given so that it can be sure that it is a CRL Issuer and not a CA,
etc
> >
> > ...
> >
> >>Then the relying party knows that he got a correct indirect CRL and
> >
> > has to
> >
> >>make sure that the name of the CA is present. Additional details
would
> >
> > be
> >
> >>needed to explain name matching taking into account that two CAs
could
> >
> > be
> >
> >>given the same DN by two different CAs.
> >>
> >>
> >>CONCLUSION:
> >>
> >>I see two ways to progress:
> >>
> >>    a) "avoid" the problem *now* and leave it for later. This means
> >>       saying that this extension may provide useful information
that
> >>       still needs to be verified to be trusted. The security
> >>       considerations section would tackle the issue but not provide
> >>       the full answer.
> >>
> >>    b) address the issue and say how to handle CRLs when they are
not
> >>signed
> >>       by the CA.
> >>
> >>In case of a), that is the easiest *temporary* solution, I would
> >
> > propose
> >
> >>to
> >>rewrite the introduction in the following way :
> >>
> >>    RFC 3280 [PKIX1] specifies the validation of certification
paths.
> >>    One aspect involves the determination that a certificate has not
> >
> > been
> >
> >>    revoked, and one revocation checking mechanism is the
Certificate
> >>    Revocation List (CRL). Checking a CRL when the CRL is signed by
> >
> > the
> >
> >>    key of the Issuing CA is straightforward, but not necessarily
> >>    otherwise.
> >>
> >>    There are several legitimate scenarios where the certificate of
> >
> > the
> >
> >>    CRL issuer is not present, or easily discovered.
> >>
> >>    Standardized methods of finding the certificate of the CRL
issuer
> >
> > are
> >
> >>    currently available either though an accessible directory
location
> >
> > or
> >
> >>    through use of the Subject Information Access extension in
> >>    intermediary CA certificates.
> >>
> >>    Directory lookup requires presence and access to a directory.
The
> >>    Subject Information Access extension supports building
> >
> > certification
> >
> >>    paths top-down (in the direction from the trust anchor to the
CRL
> >>    issuer), which will succeed if certificates include an
appropriate
> >>    Subject Information Access extension. Additional methods
allowing
> >>    the building of certification paths bottom-up to validate CRLs
> >>    may be useful as well. This is the topic of this document.
> >>
> >>    RFC 3280 [PKIX1] has provided for bottom-up discovery of
> >>    certification paths through the Authority Information Access
> >>    extension, where the id-ad-caIssuers access method may specify
one
> >
> > or
> >
> >>    more accessLocation fields that contain references to CA
> >
> > certificates
> >
> >>    superior to the certificate containing this extension.
> >>
> >>    This document permits use of the Authority Information Access
> >>    extension in CRLs, enabling a CRL checking application to use
the
> >>    same access method (id-ad-caIssuers) to locate the certificate
of
> >>    the CRL issuer and complete the certification path building to
an
> >>    appropriate trust anchor.
> >>
> >>    This extension may be used in the case when indirect CRLs are
> >
> > used,
> >
> >>    when the certification Authority (CA) that issued the CRL
> >
> > certificate
> >
> >>    changes its certificate signing key, or when the CA employs
> >
> > separate
> >
> >>    keys for certificate signing and CRL signing.
> >>
> >>A typo would need to be corrected in section 2: change
> >>AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax.
> >>
> >>Section 3 about Security Considerations would need to be changed.
> >>Hereafter is a proposal:
> >>
> >>3  Security Considerations
> >>
> >>      Implementers should take into account the possible existence
of
> >>      multiple unrelated CAs and CRL issuers with the same DN, as
well
> >>      as the possibility for some trusted CAs (i.e. trusted to issue
> >>      their own certificates and associated revocation status
> >
> > information
> >
> >>      but not trusted not handle revocation information from other
> >
> > CAs)
> >
> >>      to purposely use URLs or CRL DPs identical to some CRL DPs
from
> >>      other CAs and at the same time mounting a re-routing attack.
> >>
> >>      This means that finding a CA certificate at the location
> >
> > indicated
> >
> >>      by this new extension is insufficient to make sure that it is
> >
> > the
> >
> >>      right one, and by consequence that the CRL where this
extension
> >>      has been found is also the right one.
> >>
> >>      When the CRL contains the indirectCRL boolean set to TRUE,
then
> >
> > the
> >
> >>      relying party should locally know the URL of the CRL issuer(s)
> >
> > that
> >
> >>      it directly trusts and also the associated name of the trusted
> >
> > CRL
> >
> >>      issuer, which means not simply knowing the DN of the CRL
issuer,
> >>      but also all the other DNs of the upper CAs up to a root key
> >
> > (since
> >
> >>      two CAs might be given the same DN by two different CAs).
> >>
> >>      When the CRL is a direct CRL, then relying parties shall make
> >
> > sure
> >
> >>      that the certificate of the CRL issuer has been issued by the
> >
> > same
> >
> >>      CA that has issued the target certificate.
> >>
> >>      Implementers should always take the steps of validating the
> >>      retrieved data to ensure that the data is properly formed.
> >>
> >>Of course, much more could be said and an informative annex would be
> >
> > quite
> >
> >>useful.
> >>
> >>In case of b), more work would need to be done.
> >>
> >>Denis
> >>
> >
> >
> >
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8bZss087994; Fri, 15 Apr 2005 01:37:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3F8bZNA087993; Fri, 15 Apr 2005 01:37:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8bXvT087975 for <[e-mail]>; Fri, 15 Apr 2005 01:37:34 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3F8bWn08105 for <[e-mail]>; Fri, 15 Apr 2005 10:37:32 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Fri, 15 Apr 2005 10:37:32 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3F8bWD03468 for [e-mail]; Fri, 15 Apr 2005 10:37:32 +0200 (MEST)
Date: Fri, 15 Apr 2005 10:37:32 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: Section 2
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I realized that the following did not get to the list.


> >Also, 3280 is under revision, if it happens that the corresponding text
> >gets clarified in some way, one would have something considered
> >unprecise elsewhere.
>
> I do not understand the harm that you believe is being caused.

The same type as with the text in 3370 can be definetely avoided
by not copying text which may be subject to clarifications.

If clarifications (not changes!!) are made in rfc3280bis in
order to address common misunderstandings or unprecise
wording in the majority of non-native english speaking world,
then these updates don't get into the other text.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8PKp1083822; Fri, 15 Apr 2005 01:25:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3F8PKqo083821; Fri, 15 Apr 2005 01:25:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8PIMf083805 for <[e-mail]>; Fri, 15 Apr 2005 01:25:18 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3F8PHn07998; Fri, 15 Apr 2005 10:25:17 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Fri, 15 Apr 2005 10:25:17 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3F8PGB03451; Fri, 15 Apr 2005 10:25:16 +0200 (MEST)
Date: Fri, 15 Apr 2005 10:25:16 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >
> >Now you say that it is not a matter of taste.
> 
> No.  I shared the reason that I prefer to include the OIDs rather than 
> IMPORTing them.  They both work.

I say that what you give as a reason is not a matter of taste.

And your reasoning tries to just justify technical hack.

What you are technically doing is to define a new element in the
pkix kp arc in this module. I have not see that you have obtained
authorisation to do this from the owner of the pkix kp arc. 

> >By the way, further down the example is an import of something that is NOT 
> >SIMPLE.
> >
> >Using this technique requires to keep track of all copies, and IF a
> >copied definitions changes slightly in the main definition module
> >THEN you get inconsistencies.
> 
> True.  Neither of the alternatives is perfect.  They have different kinds 
> of pain.

There is nothing wrong in IMPORT in this particular case.
IMO it is PERFECTLY in line with all (what I know) of ASN1 etc. 

We are not etalking about pains created by difficulties of correct
organisation of ASN.1 modules or using current and non-obsolete syntax
versions. 
 
> > > I have had to make edits to old ASN.1 modules to avoid errors that are
> > > introduced when one modules imports stuff from another that imports stuff
> > > from another that imports stuff from another.  The changes are almost
> > > always in parts that are not needed for the part that is needed.  I'll 
> > give
> > > a recent example.
> > >
> > > RFC 2634 imports from CMS.  The ASN.1 module says:
> > >
> > > -- RFC 2630: Cryptographic Message Syntax (CMS)
> > >      ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
> > >      FROM CryptographicMessageSyntax
> > >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> > >           pkcs-9(9) smime(16) modules(0) cms(1) }
> > >
> > > I needed to change this to:
> > >
> > > -- RFC 3852: Cryptographic Message Syntax (CMS)
> > >      ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
> > >      FROM CryptographicMessageSyntax2004
> > >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> > >           pkcs-9(9) smime(16) modules(0) cms-2004(24) }
> > >
> > > Why?  It did not have anything to do with ContentType,
> > > IssuerAndSerialNumber, or SubjectKeyIdentifier.  It had to do with
> > > something else in the RFC 2630 module.
> >
> >Do you mean the usage of 'Name' which is used in IssuerAndSerialNumber?
> >You don't change the definition of a module. You make a new one.
> >I don't see the point.
> 
> This module also had in import from RFC 3280, and the RFC 2634 imported 
> from RFC 2630, which had an import from RFC 2459, there was some 
> conflict.  I do not recall more detail than that.  By shifting the import 
> to RFC 3852, the subordinate import shifted to RFC 3280, resolving the 
> conflict.

Sorry, arguments that are not explained have no meaning to me. 
Anyway, if there was a problem and a REAL conflict, i.e. a different
definition, then duplication of the elements using same name
would have created more problems because you don't keep track.
if in your case the definitions do not change, I don't see why
you need to import then from a different place. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8An5C078823; Fri, 15 Apr 2005 01:10:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3F8AnEv078822; Fri, 15 Apr 2005 01:10:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8AlkP078774 for <[e-mail]>; Fri, 15 Apr 2005 01:10:48 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3F8Ajn07800; Fri, 15 Apr 2005 10:10:45 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Fri, 15 Apr 2005 10:10:45 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3F8Aja03429; Fri, 15 Apr 2005 10:10:45 +0200 (MEST)
Date: Fri, 15 Apr 2005 10:10:45 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >
> >take a cert with all bit on. This is equivalent to having no keyUsage at all
> >as far as I remember. in this case the keyCertSign bit and the cRLSign are 
> >set,
> >and the above 'MUST NOT' prohibits use of this cert. is this what you intend?
> >I don't think so.
> >
> >Isn't the right wording: no known EAP usage requires keyCertSign or cRLSign?
> 
> How about: ... however, EAP methods MUST NOT require the keyCertSign bit or
> the cRLSign to be set in end entity certificates.


- the initial text had no keyUsage restriction.

- the current has a restriction that technically doesn't make any
  sense and is incompatible with the standard.

- Above you propose something that is a restriction for EAP methods
  which was not in 3770. Can you justify this change, please.


Peter
PS: Would it be possible to instruct your mail user agent not to send
me two copies just because I am twice in the To list, or else. Thanks



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F7CZa8057733; Fri, 15 Apr 2005 00:12:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3F7CZkm057732; Fri, 15 Apr 2005 00:12:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F7CVSf057651 for <[e-mail]>; Fri, 15 Apr 2005 00:12:32 -0700 (PDT) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA31896; Fri, 15 Apr 2005 09:26:37 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005041509120448:1885 ; Fri, 15 Apr 2005 09:12:04 +0200 
Message-ID: <[e-mail]>
Date: Fri, 15 Apr 2005 09:12:03 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Stefan Santesson <[e-mail]>, pkix <[e-mail]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/04/2005 09:12:04, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/04/2005 09:12:06, Serialize complete at 15/04/2005 09:12:06
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3F7CYSf057722
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

> Denis:

> When a certificate issuer is using Indirect CRLs, the CRLDP identifies 
> the CRL issuer.  

To correct the language, "a certificate issuer is not using Indirect CRLs" 
but "a certificate issuer may nominate a CRL Issuer which issues Indirect CRLs".

This sentence also depends upon the content of the CRL DP.

 > In this situation, the cRLIssuer field in the CRLDP
> identifies the signer of the forthcoming CRLs.  So, in your Scenario A, 
> the CRL Issuer is explicitly identified in the CRLDP.  However, the CRL 
> Issuer's certificate is not necessarily available from the information 
> in the CRLDP.  Thus, the CRL AIA allows the certificate user to obtain 
> it.  

Not exactly, but "the CRL AIA allows the certificate user to obtain an 
address that the certificate user can query to obtain information that may 
or may not be the right one".

> In this situation the verification must make sure that the 
> cRLIssuer in the CRLDP must match the subject/subjectAltName in the 
> certificate that is fetched via the CRL AIA.

This is exactly the kind of information that is currently lacking in the 
document, with in addition how this assurance can be obtained.

> In my view, this scenario validates the need for this document.

I am not challening the usefulness (I would not use the term "need") of this 
document, since I am proposing text changes to the document.

Please take a look at my text proposals.

Denis

> Russ
> 
>> Stefan and Russ,
>>
>> It took me several hours to write this long e-mail, hence for the delay
>> (in addition to the time for shooting a few “big five” with my 
>> camera).
>>
>> This e-mail identifies several security issues, which are not 
>> currently mentionned in the security considerations section. It 
>> finally proposes a rewritting of the introduction and provides a 
>> strawman for a new security considerations section (see the proposal 
>> at the end of this e-mail).
>>
>> Let us consider two different scenarios where this new extension would 
>> be considered.
>>
>> Scenario A: The relying party does not trust any CRL issuer in 
>> particular and will simply use the CRL Issuer designated by the 
>> Certificate Issuer by means of the CRL DP extension.
>>
>> Scenario B: The relying party trusts at least a specific CRL issuer 
>> and will get the CRLs from that CRL Issuer and then will make sure 
>> that the information contained in them matches with the designation of 
>> the Certificate Issuer.
>>
>> SCENARIO A
>>
>> In scenario A, the relying party will use the CRL DP from the target 
>> certificate to get the CRL and then will make sure that the CRL that 
>> has been retrieved from that location is signed by the right CRL Issuer.
>>
>> The CRL DP extension is defined as:
>>
>>    DistributionPoint ::= SEQUENCE {
>>         distributionPoint       [0]     DistributionPointName OPTIONAL,
>>         reasons                 [1]     ReasonFlags OPTIONAL,
>>         cRLIssuer               [2]     GeneralNames OPTIONAL }
>>
>> At least the distributionPoint field shall be present. It is supposed 
>> it contains a general name of type URI, which is a pointer to the 
>> current CRL for the associated reasons and will be issued by the 
>> associated cRLIssuer.
>>
>> The CRL itself shall contain an IDP (Issuing Distribution Point).
>>
>> The IDP extension is defined as:
>>
>>    issuingDistributionPoint ::= SEQUENCE {
>>         distributionPoint          [0] DistributionPointName OPTIONAL,
>>         onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
>>         onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
>>         onlySomeReasons            [3] ReasonFlags OPTIONAL,
>>         indirectCRL                [4] BOOLEAN DEFAULT FALSE,
>>         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
>>
>> A necessary but insufficient condition is that the distributionPoint 
>> field from the IDP extension shall be equal to the distributionPoint 
>> field from the CRL DP extension.
>>
>> This is insufficient since a URL like 
>> URL=http://corppki/crl/extranet.crl could be used by accident by two 
>> different CAs, or a CA under the same root key could maliciously use 
>> that URL or a different and re-route all packets to an address where 
>> that CRL is made available.
>>
>> This means that the tupple CRL DP extension from certificates and the 
>> IDP extension from CRLs even if then match are insufficient to make 
>> sure that it is the right CRL that has been retrieved. This is 
>> “normal” until some cryptographic checksums are used to make sure 
>> that this is the right information.
>>
>> Any CA, trusted under a root key, could use an IDP extension in a CRL 
>> matching the IDP extension from another true CRL and unless other 
>> tests are performed, would fool relying parties.
>>
>> This is the major reason why the current document in its current form 
>> is dangerous to be published. It incorporates verification concepts 
>> which are missing major security issues. The security consideration 
>> section attempts to tackle the issue but it misses the point.
>>
>> The major problem is not the definition of this new extension that 
>> could provide untrusted but “useful” information, but the concepts 
>> behind path construction.
>>
>> SCENARIO B
>>
>> In scenario B, the relying party contacts the location of a trusted 
>> CRL Issuer and wants to verify that the retrieved CRL is correctly 
>> signed.
>>
>> Suppose that the retrieved CRL contains the newly defined extension 
>> which specifies one or more accessLocation fields that contains 
>> references to CA certificates superior to the CRL containing this 
>> extension.
>>
>> Let us consider that one accessLocation field contains the following 
>> URL: http://corppki/aia/certificates.crt
>>
>> The relying party will access this URL to retrieve some CA certificates.
>> Nothing at this point would prevent a network attack so that access to 
>> this URL is re-routed to another location. The question is how the 
>> relying party can figure out and what kind of tests it should make. 
>> The draft is silent about this.
>>
>> It does not help the end-user to define new extensions if at the same 
>> time there are no explanations or guidance to tell how are they should 
>> be used in order to build a secure system.
>>
>> Let us suppose that the information retrieved is just “useful” 
>> certificates at this time (i.e. untrusted).
>>
>> In order to build a path, a relying party needs to make sure of the 
>> name of the CRL Issuer, which means not simply knowing the DN of the 
>> CRL issuer but also all the other DNs from the upper CAs up to a root 
>> key. This kind of assumption or explanations is currently missing in 
>> the draft.
>>
>> Scenario B would be correctly supported if the text would mention two 
>> points:
>>
>>    1) the location of the “trusted CRL Issuer” must be locally known,
>>    2) the name of the “trusted CRL Issuer” must be locally known,
>>       which means not simply knowing the DN of the CRL issuer,
>>       but also all the other DNs from the upper CAs up to a root key.
>>
>> Using the “useful” certificates that would be retrieved using that 
>> new extension, the relying party would then build a certification path 
>> to validate the retrieved CRL. Additional details, described nowhere, 
>> should be given so that it can be sure that it is a CRL Issuer and not 
>> a CA, etc ...
>>
>> Then the relying party knows that he got a correct indirect CRL and 
>> has to make sure that the name of the CA is present. Additional 
>> details would be needed to explain name matching taking into account 
>> that two CAs could be given the same DN by two different CAs.
>>
>>
>> CONCLUSION:
>>
>> I see two ways to progress:
>>
>>    a) “avoid” the problem *now* and leave it for later. This means
>>       saying that this extension may provide useful information that
>>       still needs to be verified to be trusted. The security
>>       considerations section would tackle the issue but not provide
>>       the full answer.
>>
>>    b) address the issue and say how to handle CRLs when they are not 
>> signed
>>       by the CA.
>>
>> In case of a), that is the easiest *temporary* solution, I would 
>> propose to rewrite the introduction in the following way :
>>
>>    RFC 3280 [PKIX1] specifies the validation of certification paths.
>>    One aspect involves the determination that a certificate has not been
>>    revoked, and one revocation checking mechanism is the Certificate
>>    Revocation List (CRL). Checking a CRL when the CRL is signed by the
>>    key of the Issuing CA is straightforward, but not necessarily
>>    otherwise.
>>
>>    There are several legitimate scenarios where the certificate of the
>>    CRL issuer is not present, or easily discovered.
>>
>>    Standardized methods of finding the certificate of the CRL issuer are
>>    currently available either though an accessible directory location or
>>    through use of the Subject Information Access extension in
>>    intermediary CA certificates.
>>
>>    Directory lookup requires presence and access to a directory.  The
>>    Subject Information Access extension supports building certification
>>    paths top-down (in the direction from the trust anchor to the CRL
>>    issuer), which will succeed if certificates include an appropriate
>>    Subject Information Access extension. Additional methods allowing
>>    the building of certification paths bottom-up to validate CRLs
>>    may be useful as well. This is the topic of this document.
>>
>>    RFC 3280 [PKIX1] has provided for bottom-up discovery of
>>    certification paths through the Authority Information Access
>>    extension, where the id-ad-caIssuers access method may specify one or
>>    more accessLocation fields that contain references to CA certificates
>>    superior to the certificate containing this extension.
>>
>>    This document permits use of the Authority Information Access
>>    extension in CRLs, enabling a CRL checking application to use the
>>    same access method (id-ad-caIssuers) to locate the certificate of
>>    the CRL issuer and complete the certification path building to an
>>    appropriate trust anchor.
>>
>>    This extension may be used in the case when indirect CRLs are used,
>>    when the certification Authority (CA) that issued the CRL certificate
>>    changes its certificate signing key, or when the CA employs separate
>>    keys for certificate signing and CRL signing.
>>
>> A typo would need to be corrected in section 2: change 
>> AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax.
>>
>> Section 3 about Security Considerations would need to be changed.
>> Hereafter is a proposal:
>>
>> 3  Security Considerations
>>
>>      Implementers should take into account the possible existence of
>>      multiple unrelated CAs and CRL issuers with the same DN, as well
>>      as the possibility for some trusted CAs (i.e. trusted to issue
>>      their own certificates and associated revocation status information
>>      but not trusted not handle revocation information from other CAs)
>>      to purposely use URLs or CRL DPs identical to some CRL DPs from
>>      other CAs and at the same time mounting a re-routing attack.
>>
>>      This means that finding a CA certificate at the location indicated
>>      by this new extension is insufficient to make sure that it is the
>>      right one, and by consequence that the CRL where this extension
>>      has been found is also the right one.
>>
>>      When the CRL contains the indirectCRL boolean set to TRUE, then the
>>      relying party should locally know the URL of the CRL issuer(s) that
>>      it directly trusts and also the associated name of the trusted CRL
>>      issuer, which means not simply knowing the DN of the CRL issuer,
>>      but also all the other DNs of the upper CAs up to a root key (since
>>      two CAs might be given the same DN by two different CAs).
>>
>>      When the CRL is a direct CRL, then relying parties shall make sure
>>      that the certificate of the CRL issuer has been issued by the same
>>      CA that has issued the target certificate.
>>
>>      Implementers should always take the steps of validating the
>>      retrieved data to ensure that the data is properly formed.
>>
>> Of course, much more could be said and an informative annex would be 
>> quite useful.
>>
>> In case of b), more work would need to be done.
>>
>> Denis
>>
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EIEa9b046528; Thu, 14 Apr 2005 11:14:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EIEa7S046527; Thu, 14 Apr 2005 11:14:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EIEZDT046520 for <[e-mail]>; Thu, 14 Apr 2005 11:14:35 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 17835 invoked by uid 0); 14 Apr 2005 17:47:29 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.36.30) by woodstock.binhost.com with SMTP; 14 Apr 2005 17:47:29 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Thu, 14 Apr 2005 13:45:59 -0400
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

> > Note:  I am starting a separate thread for each of the unresolved
> > issues.  I hope this draws more people into the discussion.
> >
> > Peter:
> >
> > > > >4 *** The OID arcs should be imported from
> > > > >
> > > > >
> > > > >IMPORTS
> > > > >
> > > > >    id-pe, id-kp
> > > > >    FROM PKIX1Explicit88 { iso(1) identified-organization(3)
> > > > >             dod(6) internet(1) security(5) mechanisms(5) pkix(7)
> > > > >             id-mod(0) id-pkix1-explicit(18) }
> > > > >
> > > > >    id-aca FROM
> > > > >    PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
> > > > >                 internet(1) security(5) mechanisms(5) pkix(7) 
> id-mod(0)
> > > > >                 id-mod-attribute-cert(12)}
> > > >
> > > > This is a matter of taste.  Neither approach leads to implementation
> > > issues.
> > >
> > >Since, as you say, there are no implmentation issues. but this is not
> > >a matter of taste. Importing the correct definition is something else
> > >that making the 'hopefully' identical one.
> > >
> > >There is ONE authoritive place to have 'this' id-aca defined.
> > >(and another id-aca elsewhere)
> >
> > I do not know about other people, but would rather avoid IMPORT statements
> > for simple things.  IMPORT is a great tool for complex structures, but for
> > a simple constant, it is not worth the effort.
>
>Now you say that it is not a matter of taste.

No.  I shared the reason that I prefer to include the OIDs rather than 
IMPORTing them.  They both work.

>By the way, further down the example is an import of something that is NOT 
>SIMPLE.
>
>Using this technique requires to keep track of all copies, and IF a
>copied definitions changes slightly in the main definition module
>THEN you get inconsistencies.

True.  Neither of the alternatives is perfect.  They have different kinds 
of pain.

> > I have had to make edits to old ASN.1 modules to avoid errors that are
> > introduced when one modules imports stuff from another that imports stuff
> > from another that imports stuff from another.  The changes are almost
> > always in parts that are not needed for the part that is needed.  I'll 
> give
> > a recent example.
> >
> > RFC 2634 imports from CMS.  The ASN.1 module says:
> >
> > -- RFC 2630: Cryptographic Message Syntax (CMS)
> >      ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
> >      FROM CryptographicMessageSyntax
> >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> >           pkcs-9(9) smime(16) modules(0) cms(1) }
> >
> > I needed to change this to:
> >
> > -- RFC 3852: Cryptographic Message Syntax (CMS)
> >      ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
> >      FROM CryptographicMessageSyntax2004
> >         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
> >           pkcs-9(9) smime(16) modules(0) cms-2004(24) }
> >
> > Why?  It did not have anything to do with ContentType,
> > IssuerAndSerialNumber, or SubjectKeyIdentifier.  It had to do with
> > something else in the RFC 2630 module.
>
>Do you mean the usage of 'Name' which is used in IssuerAndSerialNumber?
>You don't change the definition of a module. You make a new one.
>I don't see the point.

This module also had in import from RFC 3280, and the RFC 2634 imported 
from RFC 2630, which had an import from RFC 2459, there was some 
conflict.  I do not recall more detail than that.  By shifting the import 
to RFC 3852, the subordinate import shifted to RFC 3280, resolving the 
conflict.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EHlGLo044223; Thu, 14 Apr 2005 10:47:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EHlGp8044222; Thu, 14 Apr 2005 10:47:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EHlFTJ044213 for <[e-mail]>; Thu, 14 Apr 2005 10:47:15 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 17861 invoked by uid 0); 14 Apr 2005 17:24:49 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.97.235) by woodstock.binhost.com with SMTP; 14 Apr 2005 17:24:49 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Thu, 14 Apr 2005 13:24:48 -0400
To: Peter Sylvester <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

> > > > >2 ***
> > > > >
> > > > >    If a certificate contains a key usage extension, the KeyUsage bits
> > > > >    that are needed depends on the EAP method that is employed; 
> however,
> > > > >    the keyCertSign bit and the cRLSign MUST NOT be associated 
> with EAP
> > > > >    method end entity certificates.
> > > > >
> > > > >This means that you cannot have a certificat WITHOUT keyUsage?
> > > > >Or, in case of a certificate without keyUsage, you could use it
> > > > >for CrlSigning?
> > > >
> > > > No.  The paragraph only talks about the key usage extension in 
> support of
> > > > EAP methods.  The question you are asking is beyond the scope of the
> > > > paragraph and the whole document.
> > > >
> > >
> > >oops, I made a mistake. i wanted to ask "could you use a certificate
> > >that has no keyUsage for EAP methods?'
> >
> > Yes.  In this case, the certificate is not providing any constraints on 
> the
> > key usage.
> >
> > Russ
>
>take a cert with all bit on. This is equivalent to having no keyUsage at all
>as far as I remember. in this case the keyCertSign bit and the cRLSign are 
>set,
>and the above 'MUST NOT' prohibits use of this cert. is this what you intend?
>I don't think so.
>
>Isn't the right wording: no known EAP usage requires keyCertSign or cRLSign?

How about: ... however, EAP methods MUST NOT require the keyCertSign bit or
the cRLSign to be set in end entity certificates.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EH7Yr5041191; Thu, 14 Apr 2005 10:07:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EH7YvM041190; Thu, 14 Apr 2005 10:07:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EH7WP0041182 for <[e-mail]>; Thu, 14 Apr 2005 10:07:33 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3EH7Un26281; Thu, 14 Apr 2005 19:07:30 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Thu, 14 Apr 2005 19:07:30 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3EH7Uj02411; Thu, 14 Apr 2005 19:07:30 +0200 (MEST)
Date: Thu, 14 Apr 2005 19:07:30 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Note:  I am starting a separate thread for each of the unresolved 
> issues.  I hope this draws more people into the discussion.
> 
> Peter:
> 
> > > >4 *** The OID arcs should be imported from
> > > >
> > > >
> > > >IMPORTS
> > > >
> > > >    id-pe, id-kp
> > > >    FROM PKIX1Explicit88 { iso(1) identified-organization(3)
> > > >             dod(6) internet(1) security(5) mechanisms(5) pkix(7)
> > > >             id-mod(0) id-pkix1-explicit(18) }
> > > >
> > > >    id-aca FROM
> > > >    PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
> > > >                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
> > > >                 id-mod-attribute-cert(12)}
> > >
> > > This is a matter of taste.  Neither approach leads to implementation 
> > issues.
> >
> >Since, as you say, there are no implmentation issues. but this is not
> >a matter of taste. Importing the correct definition is something else
> >that making the 'hopefully' identical one.
> >
> >There is ONE authoritive place to have 'this' id-aca defined.
> >(and another id-aca elsewhere)
> 
> I do not know about other people, but would rather avoid IMPORT statements 
> for simple things.  IMPORT is a great tool for complex structures, but for 
> a simple constant, it is not worth the effort.

Now you say that it is not a matter of taste. 

By the way, further down the example is an import of something that is NOT SIMPLE.

Using this technique requires to keep track of all copies, and IF a
copied definitions changes slightly in the main definition module
THEN you get inconsistencies. 

> I have had to make edits to old ASN.1 modules to avoid errors that are 
> introduced when one modules imports stuff from another that imports stuff 
> from another that imports stuff from another.  The changes are almost 
> always in parts that are not needed for the part that is needed.  I'll give 
> a recent example.
> 
> RFC 2634 imports from CMS.  The ASN.1 module says:
> 
> -- RFC 2630: Cryptographic Message Syntax (CMS)
>      ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
>      FROM CryptographicMessageSyntax
>         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>           pkcs-9(9) smime(16) modules(0) cms(1) }
> 
> I needed to change this to:
> 
> -- RFC 3852: Cryptographic Message Syntax (CMS)
>      ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
>      FROM CryptographicMessageSyntax2004
>         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>           pkcs-9(9) smime(16) modules(0) cms-2004(24) }
> 
> Why?  It did not have anything to do with ContentType, 
> IssuerAndSerialNumber, or SubjectKeyIdentifier.  It had to do with 
> something else in the RFC 2630 module.

Do you mean the usage of 'Name' which is used in IssuerAndSerialNumber?
You don't change the definition of a module. You make a new one.
I don't see the point. 

> I would rather not have to make these kinds of edits, so I prefer to 
> duplicate simple constants like OID arcs.

And what has this to do with an import of a constant? 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EGmGYm039656; Thu, 14 Apr 2005 09:48:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EGmGSI039655; Thu, 14 Apr 2005 09:48:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EGmFK8039649 for <[e-mail]>; Thu, 14 Apr 2005 09:48:15 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 29332 invoked by uid 0); 14 Apr 2005 15:57:40 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.97.235) by woodstock.binhost.com with SMTP; 14 Apr 2005 15:57:40 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Thu, 14 Apr 2005 11:57:35 -0400
To: Denis Pinkas <[e-mail]>, Stefan Santesson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Cc: pkix <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

When a certificate issuer is using Indirect CRLs, the CRLDP identifies the 
CRL issuer.  In this situation, the cRLIssuer field in the CRLDP identifies 
the signer of the forthcoming CRLs.  So, in your Scenario A, the CRL Issuer 
is explicitly identified in the CRLDP.  However, the CRL Issuer's 
certificate is not necessarily available from the information in the 
CRLDP.  Thus, the CRL AIA allows the certificate user to obtain it.  In 
this situation the verification must make sure that the cRLIssuer in the 
CRLDP must match the subject/subjectAltName in the certificate that is 
fetched via the CRL AIA.

In my view, this scenario validates the need for this document.

Russ

>Stefan and Russ,
>
>It took me several hours to write this long e-mail, hence for the delay
>(in addition to the time for shooting a few “big five” with my camera).
>
>This e-mail identifies several security issues, which are not currently 
>mentionned in the security considerations section. It finally proposes a 
>rewritting of the introduction and provides a strawman for a new security 
>considerations section (see the proposal at the end of this e-mail).
>
>Let us consider two different scenarios where this new extension would be 
>considered.
>
>Scenario A: The relying party does not trust any CRL issuer in particular 
>and will simply use the CRL Issuer designated by the Certificate Issuer by 
>means of the CRL DP extension.
>
>Scenario B: The relying party trusts at least a specific CRL issuer and 
>will get the CRLs from that CRL Issuer and then will make sure that the 
>information contained in them matches with the designation of the 
>Certificate Issuer.
>
>SCENARIO A
>
>In scenario A, the relying party will use the CRL DP from the target 
>certificate to get the CRL and then will make sure that the CRL that has 
>been retrieved from that location is signed by the right CRL Issuer.
>
>The CRL DP extension is defined as:
>
>    DistributionPoint ::= SEQUENCE {
>         distributionPoint       [0]     DistributionPointName OPTIONAL,
>         reasons                 [1]     ReasonFlags OPTIONAL,
>         cRLIssuer               [2]     GeneralNames OPTIONAL }
>
>At least the distributionPoint field shall be present. It is supposed it 
>contains a general name of type URI, which is a pointer to the current CRL 
>for the associated reasons and will be issued by the associated cRLIssuer.
>
>The CRL itself shall contain an IDP (Issuing Distribution Point).
>
>The IDP extension is defined as:
>
>    issuingDistributionPoint ::= SEQUENCE {
>         distributionPoint          [0] DistributionPointName OPTIONAL,
>         onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
>         onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
>         onlySomeReasons            [3] ReasonFlags OPTIONAL,
>         indirectCRL                [4] BOOLEAN DEFAULT FALSE,
>         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
>
>A necessary but insufficient condition is that the distributionPoint field 
>from the IDP extension shall be equal to the distributionPoint field from 
>the CRL DP extension.
>
>This is insufficient since a URL like URL=http://corppki/crl/extranet.crl 
>could be used by accident by two different CAs, or a CA under the same 
>root key could maliciously use that URL or a different and re-route all 
>packets to an address where that CRL is made available.
>
>This means that the tupple CRL DP extension from certificates and the IDP 
>extension from CRLs even if then match are insufficient to make sure that 
>it is the right CRL that has been retrieved. This is “normal” until 
>some cryptographic checksums are used to make sure that this is the right 
>information.
>
>Any CA, trusted under a root key, could use an IDP extension in a CRL 
>matching the IDP extension from another true CRL and unless other tests 
>are performed, would fool relying parties.
>
>This is the major reason why the current document in its current form is 
>dangerous to be published. It incorporates verification concepts which are 
>missing major security issues. The security consideration section attempts 
>to tackle the issue but it misses the point.
>
>The major problem is not the definition of this new extension that could 
>provide untrusted but “useful” information, but the concepts behind 
>path construction.
>
>SCENARIO B
>
>In scenario B, the relying party contacts the location of a trusted CRL 
>Issuer and wants to verify that the retrieved CRL is correctly signed.
>
>Suppose that the retrieved CRL contains the newly defined extension which 
>specifies one or more accessLocation fields that contains references to CA 
>certificates superior to the CRL containing this extension.
>
>Let us consider that one accessLocation field contains the following URL: 
>http://corppki/aia/certificates.crt
>
>The relying party will access this URL to retrieve some CA certificates.
>Nothing at this point would prevent a network attack so that access to 
>this URL is re-routed to another location. The question is how the relying 
>party can figure out and what kind of tests it should make. The draft is 
>silent about this.
>
>It does not help the end-user to define new extensions if at the same time 
>there are no explanations or guidance to tell how are they should be used 
>in order to build a secure system.
>
>Let us suppose that the information retrieved is just “useful” 
>certificates at this time (i.e. untrusted).
>
>In order to build a path, a relying party needs to make sure of the name 
>of the CRL Issuer, which means not simply knowing the DN of the CRL issuer 
>but also all the other DNs from the upper CAs up to a root key. This kind 
>of assumption or explanations is currently missing in the draft.
>
>Scenario B would be correctly supported if the text would mention two points:
>
>    1) the location of the “trusted CRL Issuer” must be locally known,
>    2) the name of the “trusted CRL Issuer” must be locally known,
>       which means not simply knowing the DN of the CRL issuer,
>       but also all the other DNs from the upper CAs up to a root key.
>
>Using the “useful” certificates that would be retrieved using that new 
>extension, the relying party would then build a certification path to 
>validate the retrieved CRL. Additional details, described nowhere, should 
>be given so that it can be sure that it is a CRL Issuer and not a CA, etc ...
>
>Then the relying party knows that he got a correct indirect CRL and has to 
>make sure that the name of the CA is present. Additional details would be 
>needed to explain name matching taking into account that two CAs could be 
>given the same DN by two different CAs.
>
>
>CONCLUSION:
>
>I see two ways to progress:
>
>    a) “avoid” the problem *now* and leave it for later. This means
>       saying that this extension may provide useful information that
>       still needs to be verified to be trusted. The security
>       considerations section would tackle the issue but not provide
>       the full answer.
>
>    b) address the issue and say how to handle CRLs when they are not signed
>       by the CA.
>
>In case of a), that is the easiest *temporary* solution, I would propose 
>to rewrite the introduction in the following way :
>
>    RFC 3280 [PKIX1] specifies the validation of certification paths.
>    One aspect involves the determination that a certificate has not been
>    revoked, and one revocation checking mechanism is the Certificate
>    Revocation List (CRL). Checking a CRL when the CRL is signed by the
>    key of the Issuing CA is straightforward, but not necessarily
>    otherwise.
>
>    There are several legitimate scenarios where the certificate of the
>    CRL issuer is not present, or easily discovered.
>
>    Standardized methods of finding the certificate of the CRL issuer are
>    currently available either though an accessible directory location or
>    through use of the Subject Information Access extension in
>    intermediary CA certificates.
>
>    Directory lookup requires presence and access to a directory.  The
>    Subject Information Access extension supports building certification
>    paths top-down (in the direction from the trust anchor to the CRL
>    issuer), which will succeed if certificates include an appropriate
>    Subject Information Access extension. Additional methods allowing
>    the building of certification paths bottom-up to validate CRLs
>    may be useful as well. This is the topic of this document.
>
>    RFC 3280 [PKIX1] has provided for bottom-up discovery of
>    certification paths through the Authority Information Access
>    extension, where the id-ad-caIssuers access method may specify one or
>    more accessLocation fields that contain references to CA certificates
>    superior to the certificate containing this extension.
>
>    This document permits use of the Authority Information Access
>    extension in CRLs, enabling a CRL checking application to use the
>    same access method (id-ad-caIssuers) to locate the certificate of
>    the CRL issuer and complete the certification path building to an
>    appropriate trust anchor.
>
>    This extension may be used in the case when indirect CRLs are used,
>    when the certification Authority (CA) that issued the CRL certificate
>    changes its certificate signing key, or when the CA employs separate
>    keys for certificate signing and CRL signing.
>
>A typo would need to be corrected in section 2: change 
>AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax.
>
>Section 3 about Security Considerations would need to be changed.
>Hereafter is a proposal:
>
>3  Security Considerations
>
>      Implementers should take into account the possible existence of
>      multiple unrelated CAs and CRL issuers with the same DN, as well
>      as the possibility for some trusted CAs (i.e. trusted to issue
>      their own certificates and associated revocation status information
>      but not trusted not handle revocation information from other CAs)
>      to purposely use URLs or CRL DPs identical to some CRL DPs from
>      other CAs and at the same time mounting a re-routing attack.
>
>      This means that finding a CA certificate at the location indicated
>      by this new extension is insufficient to make sure that it is the
>      right one, and by consequence that the CRL where this extension
>      has been found is also the right one.
>
>      When the CRL contains the indirectCRL boolean set to TRUE, then the
>      relying party should locally know the URL of the CRL issuer(s) that
>      it directly trusts and also the associated name of the trusted CRL
>      issuer, which means not simply knowing the DN of the CRL issuer,
>      but also all the other DNs of the upper CAs up to a root key (since
>      two CAs might be given the same DN by two different CAs).
>
>      When the CRL is a direct CRL, then relying parties shall make sure
>      that the certificate of the CRL issuer has been issued by the same
>      CA that has issued the target certificate.
>
>      Implementers should always take the steps of validating the
>      retrieved data to ensure that the data is properly formed.
>
>Of course, much more could be said and an informative annex would be quite 
>useful.
>
>In case of b), more work would need to be done.
>
>Denis
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EGakcS038851; Thu, 14 Apr 2005 09:36:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EGakmf038850; Thu, 14 Apr 2005 09:36:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EGaicW038840 for <[e-mail]>; Thu, 14 Apr 2005 09:36:45 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3EGahn25792; Thu, 14 Apr 2005 18:36:43 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Thu, 14 Apr 2005 18:36:43 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3EGafb02347; Thu, 14 Apr 2005 18:36:41 +0200 (MEST)
Date: Thu, 14 Apr 2005 18:36:41 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> > > >2 ***
> > > >
> > > >    If a certificate contains a key usage extension, the KeyUsage bits
> > > >    that are needed depends on the EAP method that is employed; however,
> > > >    the keyCertSign bit and the cRLSign MUST NOT be associated with EAP
> > > >    method end entity certificates.
> > > >
> > > >This means that you cannot have a certificat WITHOUT keyUsage?
> > > >Or, in case of a certificate without keyUsage, you could use it
> > > >for CrlSigning?
> > >
> > > No.  The paragraph only talks about the key usage extension in support of
> > > EAP methods.  The question you are asking is beyond the scope of the
> > > paragraph and the whole document.
> > >
> >
> >oops, I made a mistake. i wanted to ask "could you use a certificate
> >that has no keyUsage for EAP methods?'
> 
> Yes.  In this case, the certificate is not providing any constraints on the 
> key usage.
> 
> Russ

take a cert with all bit on. This is equivalent to having no keyUsage at all
as far as I remember. in this case the keyCertSign bit and the cRLSign are set, 
and the above 'MUST NOT' prohibits use of this cert. is this what you intend?
I don't think so. 

Isn't the right wording: no known EAP usage requires keyCertSign or cRLSign? 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EG0lCL036753; Thu, 14 Apr 2005 09:00:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EG0klD036752; Thu, 14 Apr 2005 09:00:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EG0jB1036744 for <[e-mail]>; Thu, 14 Apr 2005 09:00:45 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 17427 invoked by uid 0); 14 Apr 2005 15:00:39 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.165.114) by woodstock.binhost.com with SMTP; 14 Apr 2005 15:00:39 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Thu, 14 Apr 2005 11:00:39 -0400
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: draft-ietf-pkix-rfc3770bis-01: OID Import
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Note:  I am starting a separate thread for each of the unresolved 
issues.  I hope this draws more people into the discussion.

Peter:

> > >4 *** The OID arcs should be imported from
> > >
> > >
> > >IMPORTS
> > >
> > >    id-pe, id-kp
> > >    FROM PKIX1Explicit88 { iso(1) identified-organization(3)
> > >             dod(6) internet(1) security(5) mechanisms(5) pkix(7)
> > >             id-mod(0) id-pkix1-explicit(18) }
> > >
> > >    id-aca FROM
> > >    PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
> > >                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
> > >                 id-mod-attribute-cert(12)}
> >
> > This is a matter of taste.  Neither approach leads to implementation 
> issues.
>
>Since, as you say, there are no implmentation issues. but this is not
>a matter of taste. Importing the correct definition is something else
>that making the 'hopefully' identical one.
>
>There is ONE authoritive place to have 'this' id-aca defined.
>(and another id-aca elsewhere)

I do not know about other people, but would rather avoid IMPORT statements 
for simple things.  IMPORT is a great tool for complex structures, but for 
a simple constant, it is not worth the effort.

I have had to make edits to old ASN.1 modules to avoid errors that are 
introduced when one modules imports stuff from another that imports stuff 
from another that imports stuff from another.  The changes are almost 
always in parts that are not needed for the part that is needed.  I'll give 
a recent example.

RFC 2634 imports from CMS.  The ASN.1 module says:

-- RFC 2630: Cryptographic Message Syntax (CMS)
     ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
     FROM CryptographicMessageSyntax
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-9(9) smime(16) modules(0) cms(1) }

I needed to change this to:

-- RFC 3852: Cryptographic Message Syntax (CMS)
     ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
     FROM CryptographicMessageSyntax2004
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-9(9) smime(16) modules(0) cms-2004(24) }

Why?  It did not have anything to do with ContentType, 
IssuerAndSerialNumber, or SubjectKeyIdentifier.  It had to do with 
something else in the RFC 2630 module.

I would rather not have to make these kinds of edits, so I prefer to 
duplicate simple constants like OID arcs.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EFh1q4035360; Thu, 14 Apr 2005 08:43:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EFh1JJ035359; Thu, 14 Apr 2005 08:43:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EFh0x0035353 for <[e-mail]>; Thu, 14 Apr 2005 08:43:00 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 4038 invoked by uid 0); 14 Apr 2005 14:47:54 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.165.114) by woodstock.binhost.com with SMTP; 14 Apr 2005 14:47:54 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Thu, 14 Apr 2005 10:47:49 -0400
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: draft-ietf-pkix-rfc3770bis-01: Section 2
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Note:  I am starting a separate thread for each of the unresolved 
issues.  I hope this draws more people into the discussion.

Peter:

> > >This restriction is new, and I don't see why this is necessary.
> > >I am not sure, but I don't know of any other purpose that has
> > >a restriction like this, and current scvp specs don't allow to
> > >check for this (you cannot specify MUST NOT).
> >
> > The IETF (or anyone else for that matter) should not specify EAP methods
> > that expect either of these key usage bits to be set.
> >
> > You are primarily asking for sentence to be deleted. The sentences that 
> you
> > would like to see go away are in RFC 3770, so I think that the removal
> > needs to be justified.
>
>The initial text was an inconsistent adoption from something of 2459 and 3280.
>This demonstrates the problematics of copying text portions "for convenience."
>Correcting the text as is still does not give a complete picture since it
>is only a subset of rfc 3280. This kind of 'layman guide to 3280' doesn't
>seem appropriate to me here.
>
>Also, 3280 is under revision, if it happens that the corresponding text
>gets clarified in some way, one would have something considered
>unprecise elsewhere.

I do not understand the harm that you believe is being caused.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EEhe77027819; Thu, 14 Apr 2005 07:43:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EEhePl027818; Thu, 14 Apr 2005 07:43:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EEhdft027812 for <[e-mail]>; Thu, 14 Apr 2005 07:43:39 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 25643 invoked by uid 0); 14 Apr 2005 14:01:09 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.165.114) by woodstock.binhost.com with SMTP; 14 Apr 2005 14:01:09 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Thu, 14 Apr 2005 10:01:08 -0400
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: draft-ietf-pkix-rfc3770bis-01: key usage extension
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Note:  I am starting a separate thread for each of the unresolved 
issues.  I hope this draws more people into the discussion.

Peter:

> > >2 ***
> > >
> > >    If a certificate contains a key usage extension, the KeyUsage bits
> > >    that are needed depends on the EAP method that is employed; however,
> > >    the keyCertSign bit and the cRLSign MUST NOT be associated with EAP
> > >    method end entity certificates.
> > >
> > >This means that you cannot have a certificat WITHOUT keyUsage?
> > >Or, in case of a certificate without keyUsage, you could use it
> > >for CrlSigning?
> >
> > No.  The paragraph only talks about the key usage extension in support of
> > EAP methods.  The question you are asking is beyond the scope of the
> > paragraph and the whole document.
> >
>
>oops, I made a mistake. i wanted to ask "could you use a certificate
>that has no keyUsage for EAP methods?'

Yes.  In this case, the certificate is not providing any constraints on the 
key usage.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E8o4g4033430; Thu, 14 Apr 2005 01:50:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3E8o4Li033429; Thu, 14 Apr 2005 01:50:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E8o26Y033410 for <[e-mail]>; Thu, 14 Apr 2005 01:50:03 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3E8njn17084; Thu, 14 Apr 2005 10:49:45 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/2.0); Thu, 14 Apr 2005 10:49:45 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3E8nim01640; Thu, 14 Apr 2005 10:49:44 +0200 (MEST)
Date: Thu, 14 Apr 2005 10:49:44 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >1 ***
I think there were two other answers.

> >2 ***
> >
> >    If a certificate contains a key usage extension, the KeyUsage bits
> >    that are needed depends on the EAP method that is employed; however,
> >    the keyCertSign bit and the cRLSign MUST NOT be associated with EAP
> >    method end entity certificates.
> >
> >This means that you cannot have a certificat WITHOUT keyUsage?
> >Or, in case of a certificate without keyUsage, you could use it
> >for CrlSigning?
> 
> No.  The paragraph only talks about the key usage extension in support of 
> EAP methods.  The question you are asking is beyond the scope of the 
> paragraph and the whole document.
> 

oops, I made a mistake. i wanted to ask "could you use a certificate
that has no keyUsage for EAP methods?'
 
 
> >This restriction is new, and I don't see why this is necessary.
> >I am not sure, but I don't know of any other purpose that has
> >a restriction like this, and current scvp specs don't allow to
> >check for this (you cannot specify MUST NOT).
> 
> The IETF (or anyone else for that matter) should not specify EAP methods 
> that expect either of these key usage bits to be set.
> 
> You are primarily asking for sentence to be deleted. The sentences that you 
> would like to see go away are in RFC 3770, so I think that the removal 
> needs to be justified.

The initial text was an inconsistent adoption from something of 2459 and 3280.
This demonstrates the problematics of copying text portions "for convenience."
Correcting the text as is still does not give a complete picture since it
is only a subset of rfc 3280. This kind of 'layman guide to 3280' doesn't
seem appropriate to me here.

Also, 3280 is under revision, if it happens that the corresponding text
gets clarified in some way, one would have something considered
unprecise elsewhere.

> >4 *** The OID arcs should be imported from
> >
> >
> >IMPORTS
> >
> >    id-pe, id-kp
> >    FROM PKIX1Explicit88 { iso(1) identified-organization(3)
> >             dod(6) internet(1) security(5) mechanisms(5) pkix(7)
> >             id-mod(0) id-pkix1-explicit(18) }
> >
> >    id-aca FROM
> >    PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
> >                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
> >                 id-mod-attribute-cert(12)}
> 
> This is a matter of taste.  Neither approach leads to implementation issues.

Since, as you say, there are no implmentation issues. but this is not
a matter of taste. Importing the correct definition is something else
that making the 'hopefully' identical one.

There is ONE authoritive place to have 'this' id-aca defined. 
(and another id-aca elsewhere) 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E8AKig019658; Thu, 14 Apr 2005 01:10:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3E8AKU2019657; Thu, 14 Apr 2005 01:10:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E8AGoZ019585 for <[e-mail]>; Thu, 14 Apr 2005 01:10:18 -0700 (PDT) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA16066; Thu, 14 Apr 2005 10:24:29 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005041410095678:1203 ; Thu, 14 Apr 2005 10:09:56 +0200 
Message-ID: <[e-mail]>
Date: Thu, 14 Apr 2005 10:09:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Russ Housley <[e-mail]>, pkix <[e-mail]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 14/04/2005 10:09:56, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 14/04/2005 10:09:59, Serialize complete at 14/04/2005 10:09:59
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

> Denis,

> Thanks for spending considerable time to comment on this draft.

> The typo is noted and will be fixed.

Thank you so much, for accepting to correct the typo. :-|

> Some generic comments before we go into the specific text proposals:

> You point out some well known issues related to the lack of absolute
> cryptographic binding between CRL and certificates where the certificate
> and CRL is not signed by the same key.

Not really. It is indeed possible to have an absolute cryptographic binding 
between CRL and certificates where the certificate and CRL is not signed by 
the same key, but the key point is that proposed extension is *not* the 
means to provide such a binding (and you agree with this further down in 
this e-mail).

The proposed extension is simply a means to find a possible certificate 
candidates, but not a means to make sure that the candidate is acceptable.

> A certificate is always authoritative to identify the correct CRL for
> its validation. 

While this is true in general, this is not always true. When indirect CRLs 
are used, a directly trusted CRL Issuer may be used. For other cases, your 
statement is correct.

 > But since the certificate is signed before the latest
> CRL that validates it, the certificate can't cryptographically bind
> (e.g. hash) the CRL but needs to identify it by verifiable attributes
> such as issuer name and storage location.

As you say, only issuer name or location may be used. Location cannot be 
used as this has been demonstrated in the previous e-mail, since a network 
attack could be performed. So only the issuer name can be used. Let us look, 
how:

The CRL DP extension is defined as:

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

Secure binding may be obtained using cRLIssuer where

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

with

GeneralName ::= CHOICE {
      otherName                       [0]     AnotherName,
      rfc822Name                      [1]     IA5String,
      dNSName                         [2]     IA5String,
      x400Address                     [3]     ORAddress,
      directoryName                   [4]     Name,
      ediPartyName                    [5]     EDIPartyName,
      uniformResourceIdentifier       [6]     IA5String,
      iPAddress                       [7]     OCTET STRING,
      registeredID                    [8]     OBJECT IDENTIFIER }

where    Name ::= CHOICE {
      RDNSequence }

RFC 3280 states:

   " If the certificate issuer is not the CRL Issuer, then the cRLIssuer
     field MUST be present and contain the Name of the CRL issuer".

A name is uniquely assigned to an entity, only if the name of the CA which 
has allocated it is known. Recursively, the DN of that CA is uniquely 
assigned to an entity, only if the DN of the CA which has allocated that DN 
it is known. This process ends up until the trust anchor that has issued the 
first CA certificate of the certification path is known.

> This issue is however NOT introduced by this draft. It is simply a
> generic issue with RFC 3280/X.509, especially for indirect CRLs

> In this context I really can't see the difference between scenario A and
> scenario B. It seems to me that the same validation principles apply to
> both scenarios.

Not exactly. From what is said above, it can be said that cRLIssuer DN has 
been uniquely assigned to that entity, if it is known that this DN has been 
issued by the CA that has issued the target certificate. This is scenario A 
which means that the trust conditions from the relying party are simple and 
well known.

The problem is that with scenario B, no document provides the trust 
conditions to be used by the relying party and that there can be many 
different trust conditions, some of them may be secure, while some of them 
may be insecure depending upon the context.

This is why it is important to make a difference between scenario A and B.

> Section 6.3 of RFC 3280 is dealing with CRL validation and the
> requirement to validate the CRL through a valid certificate path.

  ... but that section is lacking of further details that would allow two 
different imlplementations to end up with the same result.

> This draft only introduces a new way to point to locate certificates
> that can be helpful in building this path. 

At least one sentence of which we both agree !
It should be copied and pasted in the abstract.

 > It seems to me from that
> perspective that specific requirements on CRL path building are outside
> the scope of this draft.

Since scenario B has so many possible options, it is not possible to cover 
all of them and the intent is not to describe and prescribe all of them. 
However, scenarion A is much simpler and may be described.

I have many problems with the current introduction. I am restating my 
previous proposal for a revised introduction along the lines that "this 
draft only introduces a new way to point to locate certificates that can be 
helpful in building this path". If you have problems with that text, please 
propose revisions to it. If you can live with it, then we are solved with 
the introduction.


    RFC 3280 [PKIX1] specifies the validation of certification paths.
    One aspect involves the determination that a certificate has not been
    revoked, and one revocation checking mechanism is the Certificate
    Revocation List (CRL). Checking a CRL when the CRL is signed by the
    key of the Issuing CA is straightforward, but not necessarily
    otherwise.

    There are several legitimate scenarios where the certificate of the
    CRL issuer is not present, or easily discovered.

    Standardized methods of finding the certificate of the CRL issuer are
    currently available either though an accessible directory location or
    through use of the Subject Information Access extension in
    intermediary CA certificates.

    Directory lookup requires presence and access to a directory.  The
    Subject Information Access extension supports building certification
    paths top-down (in the direction from the trust anchor to the CRL
    issuer), which will succeed if certificates include an appropriate
    Subject Information Access extension. Additional methods allowing
    the building of certification paths bottom-up to validate CRLs
    may be useful as well. This is the topic of this document.

    RFC 3280 [PKIX1] has provided for bottom-up discovery of
    certification paths through the Authority Information Access
    extension, where the id-ad-caIssuers access method may specify one or
    more accessLocation fields that contain references to CA certificates
    superior to the certificate containing this extension.

    This document permits use of the Authority Information Access
    extension in CRLs, enabling a CRL checking application to use the
    same access method (id-ad-caIssuers) to locate the certificate of
    the CRL issuer and complete the certification path building to an
    appropriate trust anchor.

    This extension may be used in the case when indirect CRLs are used,
    when the certification Authority (CA) that issued the CRL certificate
    changes its certificate signing key, or when the CA employs separate
    keys for certificate signing and CRL signing.


Now the security considerations section still contains incorrect text.
I have revised my previous proposal. If you have problems with that text,
please propose revisions to it. If you can live with it, then we are
solved with section 3.

3  Security Considerations

      Implementers should take into account the possible existence of
      multiple unrelated CAs and CRL issuers with the same DN, as well
      as the possibility for some trusted CAs (i.e. trusted to issue
      their own certificates and associated revocation status information
      but not trusted not handle revocation information from other CAs)
      to purposely use URLs or CRL DPs identical to some CRL DPs from
      other CAs and at the same time mounting a re-routing attack.

      This means that finding a CA certificate at the location indicated
      by this new extension is insufficient to make sure that it is the
      right one, and by consequence that the CRL where this extension
      has been found is also the right one.

      When the CRL is a direct CRL, relying parties shall make sure
      that the certificate of the CRL issuer has been issued by the same
      CA that has issued the target certificate.

      When the CRL contains the indirectCRL boolean set to TRUE,
      relying parties should locally know the URL of the CRL issuer(s)
      that they directly trust and use local trust conditions to make
      sure that the CRL that has been retrieved has indeed be issued
      by a directly trusted CRL Issuer. In particular, care should be taken
      in case two CAs would be using the same DN for two different CAs.

      Implementers should always take the steps of validating the
      retrieved data to ensure that the data is properly formed.


Indeed, more could be said about indirect CRLs, so if you want to add some 
more text, please do it.

Denis

>>Stefan Santesson
>>Program Manager - Standards Liaison
>>Windows Security
> 
>  
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 11 april 2005 00:59
>>To: Stefan Santesson; Russ Housley
>>Cc: pkix
>>Subject: Comments on <draft-ietf-pkix-crlaia-00.txt>
>>
>>
>>Stefan and Russ,
>>
>>It took me several hours to write this long e-mail, hence for the
> 
> delay
> 
>>(in addition to the time for shooting a few "big five" with my
> 
> camera).
> 
>>This e-mail identifies several security issues, which are not
> 
> currently
> 
>>mentionned in the security considerations section. It finally proposes
> 
> a
> 
>>rewritting of the introduction and provides a strawman for a new
> 
> security
> 
>>considerations section (see the proposal at the end of this e-mail).
>>
>>Let us consider two different scenarios where this new extension would
> 
> be
> 
>>considered.
>>
>>Scenario A: The relying party does not trust any CRL issuer in
> 
> particular
> 
>>and will simply use the CRL Issuer designated by the Certificate
> 
> Issuer by
> 
>>means of the CRL DP extension.
>>
>>Scenario B: The relying party trusts at least a specific CRL issuer
> 
> and
> 
>>will
>>get the CRLs from that CRL Issuer and then will make sure that the
>>information contained in them matches with the designation of the
>>Certificate Issuer.
>>
>>SCENARIO A
>>
>>In scenario A, the relying party will use the CRL DP from the target
>>certificate to get the CRL and then will make sure that the CRL that
> 
> has
> 
>>been retrieved from that location is signed by the right CRL Issuer.
>>
>>The CRL DP extension is defined as:
>>
>>    DistributionPoint ::= SEQUENCE {
>>         distributionPoint       [0]     DistributionPointName
> 
> OPTIONAL,
> 
>>         reasons                 [1]     ReasonFlags OPTIONAL,
>>         cRLIssuer               [2]     GeneralNames OPTIONAL }
>>
>>At least the distributionPoint field shall be present. It is supposed
> 
> it
> 
>>contains a general name of type URI, which is a pointer to the current
> 
> CRL
> 
>>for the associated reasons and will be issued by the associated
> 
> cRLIssuer.
> 
>>The CRL itself shall contain an IDP (Issuing Distribution Point).
>>
>>The IDP extension is defined as:
>>
>>    issuingDistributionPoint ::= SEQUENCE {
>>         distributionPoint          [0] DistributionPointName
> 
> OPTIONAL,
> 
>>         onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
>>         onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
>>         onlySomeReasons            [3] ReasonFlags OPTIONAL,
>>         indirectCRL                [4] BOOLEAN DEFAULT FALSE,
>>         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
>>
>>A necessary but insufficient condition is that the distributionPoint
> 
> field
> 
>>from the IDP extension shall be equal to the distributionPoint field
> 
> from
> 
>>the CRL DP extension.
>>
>>This is insufficient since a URL like
> 
> URL=http://corppki/crl/extranet.crl
> 
>>could be used by accident by two different CAs, or a CA under the same
>>root
>>key could maliciously use that URL or a different and re-route all
> 
> packets
> 
>>to an address where that CRL is made available.
>>
>>This means that the tupple CRL DP extension from certificates and the
> 
> IDP
> 
>>extension from CRLs even if then match are insufficient to make sure
> 
> that
> 
>>it
>>is the right CRL that has been retrieved. This is "normal" until some
>>cryptographic checksums are used to make sure that this is the right
>>information.
>>
>>Any CA, trusted under a root key, could use an IDP extension in a CRL
>>matching the IDP extension from another true CRL and unless other
> 
> tests
> 
>>are
>>performed, would fool relying parties.
>>
>>This is the major reason why the current document in its current form
> 
> is
> 
>>dangerous to be published. It incorporates verification concepts which
> 
> are
> 
>>missing major security issues. The security consideration section
> 
> attempts
> 
>>to tackle the issue but it misses the point.
>>
>>The major problem is not the definition of this new extension that
> 
> could
> 
>>provide untrusted but "useful" information, but the concepts behind
> 
> path
> 
>>construction.
>>
>>SCENARIO B
>>
>>In scenario B, the relying party contacts the location of a trusted
> 
> CRL
> 
>>Issuer and wants to verify that the retrieved CRL is correctly signed.
>>
>>Suppose that the retrieved CRL contains the newly defined extension
> 
> which
> 
>>specifies one or more accessLocation fields that contains references
> 
> to CA
> 
>>certificates superior to the CRL containing this extension.
>>
>>Let us consider that one accessLocation field contains the following
> 
> URL:
> 
>>http://corppki/aia/certificates.crt
>>
>>The relying party will access this URL to retrieve some CA
> 
> certificates.
> 
>>Nothing at this point would prevent a network attack so that access to
>>this
>>URL is re-routed to another location. The question is how the relying
>>party
>>can figure out and what kind of tests it should make. The draft is
> 
> silent
> 
>>about this.
>>
>>It does not help the end-user to define new extensions if at the same
> 
> time
> 
>>there are no explanations or guidance to tell how are they should be
> 
> used
> 
>>in
>>order to build a secure system.
>>
>>Let us suppose that the information retrieved is just "useful"
>>certificates
>>at this time (i.e. untrusted).
>>
>>In order to build a path, a relying party needs to make sure of the
> 
> name
> 
>>of
>>the CRL Issuer, which means not simply knowing the DN of the CRL
> 
> issuer
> 
>>but
>>also all the other DNs from the upper CAs up to a root key. This kind
> 
> of
> 
>>assumption or explanations is currently missing in the draft.
>>
>>Scenario B would be correctly supported if the text would mention two
>>points:
>>
>>    1) the location of the "trusted CRL Issuer" must be locally known,
>>    2) the name of the "trusted CRL Issuer" must be locally known,
>>       which means not simply knowing the DN of the CRL issuer,
>>       but also all the other DNs from the upper CAs up to a root key.
>>
>>Using the "useful" certificates that would be retrieved using that new
>>extension, the relying party would then build a certification path to
>>validate the retrieved CRL. Additional details, described nowhere,
> 
> should
> 
>>be
>>given so that it can be sure that it is a CRL Issuer and not a CA, etc
> 
> ...
> 
>>Then the relying party knows that he got a correct indirect CRL and
> 
> has to
> 
>>make sure that the name of the CA is present. Additional details would
> 
> be
> 
>>needed to explain name matching taking into account that two CAs could
> 
> be
> 
>>given the same DN by two different CAs.
>>
>>
>>CONCLUSION:
>>
>>I see two ways to progress:
>>
>>    a) "avoid" the problem *now* and leave it for later. This means
>>       saying that this extension may provide useful information that
>>       still needs to be verified to be trusted. The security
>>       considerations section would tackle the issue but not provide
>>       the full answer.
>>
>>    b) address the issue and say how to handle CRLs when they are not
>>signed
>>       by the CA.
>>
>>In case of a), that is the easiest *temporary* solution, I would
> 
> propose
> 
>>to
>>rewrite the introduction in the following way :
>>
>>    RFC 3280 [PKIX1] specifies the validation of certification paths.
>>    One aspect involves the determination that a certificate has not
> 
> been
> 
>>    revoked, and one revocation checking mechanism is the Certificate
>>    Revocation List (CRL). Checking a CRL when the CRL is signed by
> 
> the
> 
>>    key of the Issuing CA is straightforward, but not necessarily
>>    otherwise.
>>
>>    There are several legitimate scenarios where the certificate of
> 
> the
> 
>>    CRL issuer is not present, or easily discovered.
>>
>>    Standardized methods of finding the certificate of the CRL issuer
> 
> are
> 
>>    currently available either though an accessible directory location
> 
> or
> 
>>    through use of the Subject Information Access extension in
>>    intermediary CA certificates.
>>
>>    Directory lookup requires presence and access to a directory.  The
>>    Subject Information Access extension supports building
> 
> certification
> 
>>    paths top-down (in the direction from the trust anchor to the CRL
>>    issuer), which will succeed if certificates include an appropriate
>>    Subject Information Access extension. Additional methods allowing
>>    the building of certification paths bottom-up to validate CRLs
>>    may be useful as well. This is the topic of this document.
>>
>>    RFC 3280 [PKIX1] has provided for bottom-up discovery of
>>    certification paths through the Authority Information Access
>>    extension, where the id-ad-caIssuers access method may specify one
> 
> or
> 
>>    more accessLocation fields that contain references to CA
> 
> certificates
> 
>>    superior to the certificate containing this extension.
>>
>>    This document permits use of the Authority Information Access
>>    extension in CRLs, enabling a CRL checking application to use the
>>    same access method (id-ad-caIssuers) to locate the certificate of
>>    the CRL issuer and complete the certification path building to an
>>    appropriate trust anchor.
>>
>>    This extension may be used in the case when indirect CRLs are
> 
> used,
> 
>>    when the certification Authority (CA) that issued the CRL
> 
> certificate
> 
>>    changes its certificate signing key, or when the CA employs
> 
> separate
> 
>>    keys for certificate signing and CRL signing.
>>
>>A typo would need to be corrected in section 2: change
>>AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax.
>>
>>Section 3 about Security Considerations would need to be changed.
>>Hereafter is a proposal:
>>
>>3  Security Considerations
>>
>>      Implementers should take into account the possible existence of
>>      multiple unrelated CAs and CRL issuers with the same DN, as well
>>      as the possibility for some trusted CAs (i.e. trusted to issue
>>      their own certificates and associated revocation status
> 
> information
> 
>>      but not trusted not handle revocation information from other
> 
> CAs)
> 
>>      to purposely use URLs or CRL DPs identical to some CRL DPs from
>>      other CAs and at the same time mounting a re-routing attack.
>>
>>      This means that finding a CA certificate at the location
> 
> indicated
> 
>>      by this new extension is insufficient to make sure that it is
> 
> the
> 
>>      right one, and by consequence that the CRL where this extension
>>      has been found is also the right one.
>>
>>      When the CRL contains the indirectCRL boolean set to TRUE, then
> 
> the
> 
>>      relying party should locally know the URL of the CRL issuer(s)
> 
> that
> 
>>      it directly trusts and also the associated name of the trusted
> 
> CRL
> 
>>      issuer, which means not simply knowing the DN of the CRL issuer,
>>      but also all the other DNs of the upper CAs up to a root key
> 
> (since
> 
>>      two CAs might be given the same DN by two different CAs).
>>
>>      When the CRL is a direct CRL, then relying parties shall make
> 
> sure
> 
>>      that the certificate of the CRL issuer has been issued by the
> 
> same
> 
>>      CA that has issued the target certificate.
>>
>>      Implementers should always take the steps of validating the
>>      retrieved data to ensure that the data is properly formed.
>>
>>Of course, much more could be said and an informative annex would be
> 
> quite
> 
>>useful.
>>
>>In case of b), more work would need to be done.
>>
>>Denis
>>
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DNRDBj005190; Wed, 13 Apr 2005 16:27:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DNRDLB005189; Wed, 13 Apr 2005 16:27:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from amos.eb2bcom.com (cust3103.vic01.dataco.com.au [202.63.62.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DNRBXp005176 for <[e-mail]>; Wed, 13 Apr 2005 16:27:12 -0700 (PDT) (envelope-from [e-mail])
Received: from [192.168.1.156] (10.1.2.225) by amos.eb2bcom.com (7.1.016.1) (authenticated as steven.legg) id 4236430A000028B8; Thu, 14 Apr 2005 09:33:07 +1000
Message-ID: <[e-mail]>
Date: Thu, 14 Apr 2005 09:22:48 +1000
From: Steven Legg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Peter Sylvester <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Russ Housley wrote:
> 
> Peter:
> 
> Some more remaks:
> 
>> 1 ***
>>
>> text says:
>>
>> 1.3. Abstract Syntax Notation
>>
>>    All X.509 certificate [X.509] extensions are defined using ASN.1
>>    [X.660].
>>
>> and:
>>
>>    [X.660]     ITU-T Recommendation X.660 Information Technology - ASN.1
>>                encoding rules: Specification of Basic Encoding Rules
>>                (BER), Canonical Encoding Rules (CER) and Distinguished
>>                Encoding Rules (DER), 1997.
>>
>> this looks strange to me. The encoding rules are not the asn1 syntax.
>>
>> Suggestion:
>>
>> remove 1.3 and the reference.
> 
> 
> I have heard from Peter Sylvester and Peter Gutmann on this point.  
> Anyone else have an opinion?

Firstly, the reference is incorrect. BER/CER/DER are defined in X.690,
not X.660. X.660 is about registration procedures for OIDs.

Secondly, the reference is inappropriate. ASN.1's basic notation is
defined in X.680.

     ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
     Information technology - Abstract Syntax Notation One
     (ASN.1): Specification of basic notation

Since knowledge of ASN.1 is required to interpret the specification,
a normative reference to X.680 is obligatory.

Regards,
Steven



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DKiWtv090731; Wed, 13 Apr 2005 13:44:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DKiWPv090729; Wed, 13 Apr 2005 13:44:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3DKiWUF090718 for <[e-mail]>; Wed, 13 Apr 2005 13:44:32 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 4465 invoked by uid 0); 13 Apr 2005 20:22:58 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.187.101) by woodstock.binhost.com with SMTP; 13 Apr 2005 20:22:58 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Wed, 13 Apr 2005 16:22:49 -0400
To: Peter Sylvester <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

Some more remaks:

>1 ***
>
>text says:
>
>1.3. Abstract Syntax Notation
>
>    All X.509 certificate [X.509] extensions are defined using ASN.1
>    [X.660].
>
>and:
>
>    [X.660]     ITU-T Recommendation X.660 Information Technology - ASN.1
>                encoding rules: Specification of Basic Encoding Rules
>                (BER), Canonical Encoding Rules (CER) and Distinguished
>                Encoding Rules (DER), 1997.
>
>this looks strange to me. The encoding rules are not the asn1 syntax.
>
>Suggestion:
>
>remove 1.3 and the reference.

I have heard from Peter Sylvester and Peter Gutmann on this point.  Anyone 
else have an opinion?


>2 ***
>
>    If a certificate contains a key usage extension, the KeyUsage bits
>    that are needed depends on the EAP method that is employed; however,
>    the keyCertSign bit and the cRLSign MUST NOT be associated with EAP
>    method end entity certificates.
>
>This means that you cannot have a certificat WITHOUT keyUsage?
>Or, in case of a certificate without keyUsage, you could use it
>for CrlSigning?

No.  The paragraph only talks about the key usage extension in support of 
EAP methods.  The question you are asking is beyond the scope of the 
paragraph and the whole document.

>This restriction is new, and I don't see why this is necessary.
>I am not sure, but I don't know of any other purpose that has
>a restriction like this, and current scvp specs don't allow to
>check for this (you cannot specify MUST NOT).

The IETF (or anyone else for that matter) should not specify EAP methods 
that expect either of these key usage bits to be set.

>suggestion, remove the second half sentence.
>
>
>3 *** chapter two should read IMO:
>
>2. EAP Extended Key Usage Values
>
>    RFC 3280 [PROFILE] specifies the extended key usage X.509 certificate
>    extension.  The extension indicates one or more purposes for which
>    the certified public key may be used.
>
>    This specification defines two KeyPurposeId values: one for EAP over
>    PPP, and one for EAP over LAN (EAPOL).  Inclusion of the EAP over PPP
>    value indicates that the certified public key is appropriate for use
>    with EAP in the PPP environment, and the inclusion of the EAPOL value
>    indicates that the certified public key is appropriate for use with
>    the EAP in the LAN environment.  Inclusion of both values indicates
>    that the certified public key is appropriate for use in either of the
>    environments.
>
>       id-kp-eapOverPPP  OBJECT IDENTIFIER  ::=  { id-kp 13 }
>
>       id-kp-eapOverLAN  OBJECT IDENTIFIER  ::=  { id-kp 14 }
>
>    The extended key usage extension MAY, at the option of the
>    certificate issuer, be either critical or non-critical.
>
>    If the extended key usage is present in a certificate,
>    Certificate using applications MAY require that a particular purpose
>    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>    (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in order
>    for the certificate to be acceptable to that application.
>
>    If a certificate contains a key usage extension, the KeyUsage bits
>    that are needed depends on the EAP method that is employed.
>    There is currently no method that require the usage of the keyCertSign
>    or the cRLSign bit to be set.
>
>with the XXXX a little bit more specific.

You are primarily asking for sentence to be deleted. The sentences that you 
would like to see go away are in RFC 3770, so I think that the removal 
needs to be justified.


>4 *** The OID arcs should be imported from
>
>
>IMPORTS
>
>    id-pe, id-kp
>    FROM PKIX1Explicit88 { iso(1) identified-organization(3)
>             dod(6) internet(1) security(5) mechanisms(5) pkix(7)
>             id-mod(0) id-pkix1-explicit(18) }
>
>    id-aca FROM
>    PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
>                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
>                 id-mod-attribute-cert(12)}

This is a matter of taste.  Neither approach leads to implementation issues.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DFaJVG070314; Wed, 13 Apr 2005 08:36:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DFaJor070313; Wed, 13 Apr 2005 08:36:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DFaHvV070306 for <[e-mail]>; Wed, 13 Apr 2005 08:36:18 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3DFaGn04040; Wed, 13 Apr 2005 17:36:16 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.9); Wed, 13 Apr 2005 17:36:16 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3DFaEl29892; Wed, 13 Apr 2005 17:36:14 +0200 (MEST)
Date: Wed, 13 Apr 2005 17:36:14 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: rfc3280 bis
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think this comment is also relevant somehow for 3280bis

> 
> It also looks strange because ASN.1 is defined in X.680 :-).    X.660 is 
> "Procedures
> for the operation of OSI registration authorities: General procedures 
> and top arcs of
> the ASN.1 object identifier tree".
> 
> The titles of X.680 and X.690 are:
> X.680: Information Technology - Abstract Syntax Notation One (ASN.1):
>   Specification of basic notation
> X.690: Information Technology - ASN.1 encoding rules: Specification of
>   Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
>   Distinguished Encoding Rules (DER)
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DEInpI059915; Wed, 13 Apr 2005 07:18:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DEInOR059914; Wed, 13 Apr 2005 07:18:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DEImPw059900 for <[e-mail]>; Wed, 13 Apr 2005 07:18:48 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 13 Apr 2005 10:18:33 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Apr 2005 14:18:39.0422 (UTC) FILETIME=[B03CEDE0:01C54033]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It also looks strange because ASN.1 is defined in X.680 :-).    X.660 is 
"Procedures
for the operation of OSI registration authorities: General procedures 
and top arcs of
the ASN.1 object identifier tree".

The titles of X.680 and X.690 are:
X.680: Information Technology - Abstract Syntax Notation One (ASN.1):
  Specification of basic notation
X.690: Information Technology - ASN.1 encoding rules: Specification of
  Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
  Distinguished Encoding Rules (DER)

Agree with the suggestion to remove section 1.3 and the reference.   If 
they are
retained, the reference should be changed to X.680 and its correct title.



Peter Sylvester wrote:

>Some more remaks:
>
>1 ***
>
>text says:
>
>1.3. Abstract Syntax Notation
>
>   All X.509 certificate [X.509] extensions are defined using ASN.1
>   [X.660].
>
>and:
>
>   [X.660]     ITU-T Recommendation X.660 Information Technology - ASN.1
>               encoding rules: Specification of Basic Encoding Rules
>               (BER), Canonical Encoding Rules (CER) and Distinguished
>               Encoding Rules (DER), 1997.
>
>this looks strange to me. The encoding rules are not the asn1 syntax.
>
>Suggestion: 
>
>remove 1.3 and the reference. 
>
>2 ***
>
>   If a certificate contains a key usage extension, the KeyUsage bits
>   that are needed depends on the EAP method that is employed; however,
>   the keyCertSign bit and the cRLSign MUST NOT be associated with EAP
>   method end entity certificates.
>
>This means that you cannot have a certificat WITHOUT keyUsage?
>Or, in case of a certificate without keyUsage, you could use it
>for CrlSigning? 
>
>This restriction is new, and I don't see why this is necessary.
>I am not sure, but I don't know of any other purpose that has
>a restriction like this, and current scvp specs don't allow to
>check for this (you cannot specify MUST NOT). 
>
>suggestion, remove the second half sentence. 
>
>
>3 *** chapter two should read IMO:
>
>2. EAP Extended Key Usage Values
>
>   RFC 3280 [PROFILE] specifies the extended key usage X.509 certificate
>   extension.  The extension indicates one or more purposes for which
>   the certified public key may be used.  
>
>   This specification defines two KeyPurposeId values: one for EAP over
>   PPP, and one for EAP over LAN (EAPOL).  Inclusion of the EAP over PPP
>   value indicates that the certified public key is appropriate for use
>   with EAP in the PPP environment, and the inclusion of the EAPOL value
>   indicates that the certified public key is appropriate for use with
>   the EAP in the LAN environment.  Inclusion of both values indicates
>   that the certified public key is appropriate for use in either of the
>   environments.
>
>      id-kp-eapOverPPP  OBJECT IDENTIFIER  ::=  { id-kp 13 }
>
>      id-kp-eapOverLAN  OBJECT IDENTIFIER  ::=  { id-kp 14 }
>
>   The extended key usage extension MAY, at the option of the
>   certificate issuer, be either critical or non-critical.
>
>   If the extended key usage is present in a certificate,
>   Certificate using applications MAY require that a particular purpose
>   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>   (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in order
>   for the certificate to be acceptable to that application.
>
>   If a certificate contains a key usage extension, the KeyUsage bits
>   that are needed depends on the EAP method that is employed.
>   There is currently no method that require the usage of the keyCertSign
>   or the cRLSign bit to be set.  
>
>with the XXXX a little bit more specific. 
>
>4 *** The OID arcs should be imported from 
>
>
>IMPORTS
>
>   id-pe, id-kp 
>   FROM PKIX1Explicit88 { iso(1) identified-organization(3)
>            dod(6) internet(1) security(5) mechanisms(5) pkix(7)
>            id-mod(0) id-pkix1-explicit(18) }
>
>   id-aca FROM
>   PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
>                internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
>                id-mod-attribute-cert(12)}
>
>
>peter
>
>
>  
>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DBfI82029869; Wed, 13 Apr 2005 04:41:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DBfILM029868; Wed, 13 Apr 2005 04:41:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DBfHdR029850 for <[e-mail]>; Wed, 13 Apr 2005 04:41:17 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3DBfFn29031 for <[e-mail]>; Wed, 13 Apr 2005 13:41:15 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.9); Wed, 13 Apr 2005 13:41:15 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3DBfFv28956 for [e-mail]; Wed, 13 Apr 2005 13:41:15 +0200 (MEST)
Date: Wed, 13 Apr 2005 13:41:15 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some more remaks:

1 ***

text says:

1.3. Abstract Syntax Notation

   All X.509 certificate [X.509] extensions are defined using ASN.1
   [X.660].

and:

   [X.660]     ITU-T Recommendation X.660 Information Technology - ASN.1
               encoding rules: Specification of Basic Encoding Rules
               (BER), Canonical Encoding Rules (CER) and Distinguished
               Encoding Rules (DER), 1997.

this looks strange to me. The encoding rules are not the asn1 syntax.

Suggestion: 

remove 1.3 and the reference. 

2 ***

   If a certificate contains a key usage extension, the KeyUsage bits
   that are needed depends on the EAP method that is employed; however,
   the keyCertSign bit and the cRLSign MUST NOT be associated with EAP
   method end entity certificates.

This means that you cannot have a certificat WITHOUT keyUsage?
Or, in case of a certificate without keyUsage, you could use it
for CrlSigning? 

This restriction is new, and I don't see why this is necessary.
I am not sure, but I don't know of any other purpose that has
a restriction like this, and current scvp specs don't allow to
check for this (you cannot specify MUST NOT). 

suggestion, remove the second half sentence. 


3 *** chapter two should read IMO:

2. EAP Extended Key Usage Values

   RFC 3280 [PROFILE] specifies the extended key usage X.509 certificate
   extension.  The extension indicates one or more purposes for which
   the certified public key may be used.  

   This specification defines two KeyPurposeId values: one for EAP over
   PPP, and one for EAP over LAN (EAPOL).  Inclusion of the EAP over PPP
   value indicates that the certified public key is appropriate for use
   with EAP in the PPP environment, and the inclusion of the EAPOL value
   indicates that the certified public key is appropriate for use with
   the EAP in the LAN environment.  Inclusion of both values indicates
   that the certified public key is appropriate for use in either of the
   environments.

      id-kp-eapOverPPP  OBJECT IDENTIFIER  ::=  { id-kp 13 }

      id-kp-eapOverLAN  OBJECT IDENTIFIER  ::=  { id-kp 14 }

   The extended key usage extension MAY, at the option of the
   certificate issuer, be either critical or non-critical.

   If the extended key usage is present in a certificate,
   Certificate using applications MAY require that a particular purpose
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in order
   for the certificate to be acceptable to that application.

   If a certificate contains a key usage extension, the KeyUsage bits
   that are needed depends on the EAP method that is employed.
   There is currently no method that require the usage of the keyCertSign
   or the cRLSign bit to be set.  

with the XXXX a little bit more specific. 

4 *** The OID arcs should be imported from 


IMPORTS

   id-pe, id-kp 
   FROM PKIX1Explicit88 { iso(1) identified-organization(3)
            dod(6) internet(1) security(5) mechanisms(5) pkix(7)
            id-mod(0) id-pkix1-explicit(18) }

   id-aca FROM
   PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
                internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
                id-mod-attribute-cert(12)}


peter



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CJdiUB050528; Tue, 12 Apr 2005 12:39:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3CJdiVQ050527; Tue, 12 Apr 2005 12:39:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CJdgbG050521 for <[e-mail]>; Tue, 12 Apr 2005 12:39:44 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29478; Tue, 12 Apr 2005 15:39:40 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
Date: Tue, 12 Apr 2005 15:39:40 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Certificate Extensions and Attributes Supporting
			  Authentication in Point-to-Point Protocol (PPP) 
			  and Wireless Local Area Networks (WLAN)
	Author(s)	: R. Housley, T. Moore
	Filename	: draft-ietf-pkix-rfc3770bis-01.txt
	Pages		: 10
	Date		: 2005-4-12
	
This document defines two EAP extended key usage values and a public
   key certificate extension to carry Wireless LAN (WLAN) System Service
   identifiers (SSIDs).  This document obsoletes RFC 3770.

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

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


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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-rfc3770bis-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BJ8JYM059435; Mon, 11 Apr 2005 12:08:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BJ8JdY059434; Mon, 11 Apr 2005 12:08:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BJ8IQa059410 for <[e-mail]>; Mon, 11 Apr 2005 12:08:19 -0700 (PDT) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: CoreStreet IPR disclosure
Date: Mon, 11 Apr 2005 15:08:36 -0400
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02BE_01C53EA8.55A82D40"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: CoreStreet IPR disclosure
Thread-Index: AcU+ydxLEV1lYIVBSCimr5+H+d8ftQ==
From: "Dave Engberg" <[e-mail]>
To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_02BE_01C53EA8.55A82D40
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_02BF_01C53EA8.55A82D40"


------=_NextPart_001_02BF_01C53EA8.55A82D40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 
The IETF has posted CoreStreet's formal IPR disclosure regarding
implementations of the SCVP protocol and three of CoreStreet's patents.
This includes an offer for reasonable and non-discriminatory licensing if
required by the final standard.  We fully support the standardization and
adoption of SCVP.  The full disclosure is available here:
 
    http://www.ietf.org/ietf/IPR/corestreet-ipr-draft-ietf-pkix-scvp-18.txt
 
Unlike some other PKI vendors, CoreStreet has never served a lawsuit (patent
or non) to any other party.  Our company's success stems from our innovative
implementations of open standards, which attempt to address the security and
scalability problems inherent in large PKIs.  We believe our SCVP products
will be similarly competitive.
 
Thanks,
Dave Engberg
Chief Technical Officer
CoreStreet, Ltd.
 

------=_NextPart_001_02BF_01C53EA8.55A82D40
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.2604" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D616180921-23032005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D616180921-23032005><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D773533218-11042005>The IETF has posted </SPAN>CoreStreet<SPAN=20
class=3D773533218-11042005>'s</SPAN> formal IPR disclosure<SPAN=20
class=3D773533218-11042005> </SPAN>regarding implementations of the SCVP =
protocol=20
and three of CoreStreet's patents.&nbsp; This includes an offer for =
reasonable=20
and non-discriminatory licensing if required by the final =
standard.&nbsp; We=20
fully support the standardization and adoption of&nbsp;SCVP.<SPAN=20
class=3D773533218-11042005>&nbsp; The full disclosure is available=20
here:</SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D616180921-23032005><FONT size=3D2><SPAN=20
class=3D773533218-11042005></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D616180921-23032005><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D773533218-11042005>&nbsp;&nbsp;&nbsp; <A=20
href=3D"http://www.ietf.org/ietf/IPR/corestreet-ipr-draft-ietf-pkix-scvp-=
18.txt">http://www.ietf.org/ietf/IPR/corestreet-ipr-draft-ietf-pkix-scvp-=
18.txt</A></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D616180921-23032005><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D616180921-23032005><FONT face=3DArial =
size=3D2>Unlike&nbsp;<SPAN=20
class=3D773533218-11042005>some other PKI vendors</SPAN>, CoreStreet has =
never=20
served a lawsuit <SPAN class=3D773533218-11042005>(patent or =
non)</SPAN>&nbsp;to=20
any other party.&nbsp; Our company's success stems from our innovative=20
implementations of open standards, which attempt to address the security =
and=20
scalability problems inherent in large PKIs.&nbsp; We believe our SCVP=20
products&nbsp;<SPAN class=3D773533218-11042005>will be similarly=20
competitive</SPAN>.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D773533218-11042005><FONT face=3DArial=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D773533218-11042005>Dave=20
Engberg</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D773533218-11042005>Chief =
Technical=20
Officer</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D773533218-11042005>CoreStreet,=20
Ltd.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D773533218-11042005></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_02BF_01C53EA8.55A82D40--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII1jCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCA4wwggL1oAMCAQICARkwDQYJKoZI
hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE
AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDQwNzEyMTMwMjE4WhcNMDUw
NzI2MTMwMjE4WjBnMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRYwFAYD
VQQDEw1EYXZpZCBFbmdiZXJnMSYwJAYJKoZIhvcNAQkBFhdkZW5nYmVyZ0Bjb3Jlc3RyZWV0LmNv
bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJXX+JZ1oaEb2TCawk31rzpOIRTHZyP
UGTUGNyMasqczNZATvXu2RTlon8dwEuO4evr5KE9iDe0jQSkj1g5HBEsFAH+JPU7Y0uYupm/kiyr
6FiyhBCQtWhrcNii0yahcIEbH/fBAf5V10Y2wHKFrPH6uTrj+YGhBpaXxkEZpXCe2QZtkR/kcbKa
QaMCaU27vLAZ4QT6vJTf5oG/SD1KU232kYttiLeRjnePWipH8In7crGPhgJCeQP5UtE9uHDjOStt
eZxXsWAzU7oW9nb9jHL2xOWPQyhBs4JaPvgSdFkenI6L8flsQm72U8lrV/4dqKu330m5pH89XTYl
o2PcqIUCAwEAAaOB2DCB1TAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDov
L2NybC5nZW90cnVzdC5jb20vY3Jscy9jb3Jlc3RyZWV0LmNybDAiBgNVHREEGzAZgRdkZW5nYmVy
Z0Bjb3Jlc3RyZWV0LmNvbTAfBgNVHSMEGDAWgBTY7H+TGMVmA8MQbDwE9neFPv8LtjBABggrBgEF
BQcBAQQ0MDIwMAYIKwYBBQUHMAGGJGh0dHA6Ly9nZW90cnVzdC1vY3NwLmNvcmVzdHJlZXQuY29t
LzANBgkqhkiG9w0BAQUFAAOBgQAtAQMtzyIzARw6d/sy1qPn+Mqr7aPEJFofkSW57NE639PcrXmC
E9LzVm5mtmoNkeeyHDOgla79ez8MzndDxhlwQvNdaiu124jWbgEoHC1q2K4McbaJlxjhPbCpFr7Z
CzxQxOmFxXjb16XGotrxX1aj2YWuAAdt9H3x+tHBXCn+WDGCAxowggMWAgEBMFcwUjELMAkGA1UE
BhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0
aWZpY2F0ZSBBdXRob3JpdHkCARkwCQYFKw4DAhoFAKCCAZgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDExMTkwODM2WjAjBgkqhkiG9w0BCQQxFgQUWejatX/i
lHIgQyqZgK5wUQOZVy4wZgYJKwYBBAGCNxAEMVkwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP
Q29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0
eQIBGTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG
9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBoBgsq
hkiG9w0BCRACCzFZoFcwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEp
MCcGA1UEAxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCARkwDQYJKoZIhvcNAQEB
BQAEggEAGfxeyT1e2BDmkUKrPdg7gZtddxjtLeDzz4j43W8DN0LBQz4rJ+d+QZ17oqrXdzFWi/Rz
taFTLP3EdkkgptH3pJ5Ceo2eF+n7sesWSrlxU7OMY0K4ty0T5eSyJunAD0OEVUPeB8Axrph68MrP
OHtXW8cOUxSj35+xUhTOUaW0S2k6hn/qQWgvJiN0L32/RPNsJ/vP2zpNWKzMamVNhpWvJSIi/tc8
FExBDmVch4Aue087qKbJTIC0DyToPXL1FDbjtGMohWOMcIYCMXEhppywJqS8/lX6y/blLpZ8sVdr
JyU31CzE2JiUHIwrJiqgJcsN5Z0dWME3MIi1RNktRryCjgAAAAAAAA==

------=_NextPart_000_02BE_01C53EA8.55A82D40--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BFjYfN018035; Mon, 11 Apr 2005 08:45:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BFjYmM018034; Mon, 11 Apr 2005 08:45:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BFj3uH017909 for <[e-mail]>; Mon, 11 Apr 2005 08:45:03 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j3BFhpn21044; Mon, 11 Apr 2005 17:43:51 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.9); Mon, 11 Apr 2005 17:43:51 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j3BFgYI24387; Mon, 11 Apr 2005 17:42:34 +0200 (MEST)
Date: Mon, 11 Apr 2005 17:42:34 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> The previous text was intended to help the reader, avoiding the need to 
> reread RFC 3280 to get the concepts.  I think this text meets this same goal.

Getting the concept may be in a non-normative section.
and, as the current text shows, it can get wrong. 

I don't think that this text should be a tutorial for 3280. 

> >
> > >
> > >     If the extended key usage extension is present, then the certificate
> > >     MUST only be used for one of the purposes indicated.  If multiple
> >                        !
> >                        !BY WHOM?
> >This sentence is nothing special for this text.
> 
> By any certificate user.  I'll edit the sentence.

What is a certificate user? You mean the private key owner? 

> 
> > >     purposes are indicated the application need not recognize all
> > >     purposes indicated, as long as the intended purpose is present.
> >This sentence sounds ok.

I add: this is nothing special with this text.  

> >
> > >     Certificate using applications MAY require that a particular purpose
> > >     (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in
> > >     order for the certificate to be acceptable to that application.
> >This one is a good one.

The application is a certificate user? There are two ends? 

> 
> That would be listing all of the other bits.  For example, EAP-TLS has the 
> same rules as TLS, which depends on the cipher suite that is 
> negotiated.  Other EAP methods could be defined in the future that make use 
> of the other ones.

But what is written is that it is not possible to have no keyUsage, 
since this would imply *ALL* usages, thus also keyCertSign. 

    If a certificate contains a key usage extension, the KeyUsage bits
    that are needed depend on the EAP method that is employed. 

Peter



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BESlpM002427; Mon, 11 Apr 2005 07:28:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BESlGp002426; Mon, 11 Apr 2005 07:28:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BESHFQ002319 for <[e-mail]>; Mon, 11 Apr 2005 07:28:18 -0700 (PDT) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 11 Apr 2005 15:28:11 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Mon, 11 Apr 2005 15:28:05 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on <draft-ietf-pkix-crlaia-00.txt>
Thread-Index: AcU+ef1CHYITrah2TR6/vhvE/yrduQAJGwug
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 11 Apr 2005 14:28:11.0247 (UTC) FILETIME=[B03EFFF0:01C53EA2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3BESIFQ002340
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Thanks for spending considerable time to comment on this draft.
The typo is noted and will be fixed.

Some generic comments before we go into the specific text proposals:

You point out some well known issues related to the lack of absolute
cryptographic binding between CRL and certificates where the certificate
and CRL is not signed by the same key.

A certificate is always authoritative to identify the correct CRL for
its validation. But since the certificate is signed before the latest
CRL that validates it, the certificate can't cryptographically bind
(e.g. hash) the CRL but needs to identify it by verifiable attributes
such as issuer name and storage location.

This issue is however NOT introduced by this draft. It is simply a
generic issue with RFC 3280/X.509, especially for indirect CRLs

In this context I really can't see the difference between scenario A and
scenario B. It seems to me that the same validation principles apply to
both scenarios.


Section 6.3 of RFC 3280 is dealing with CRL validation and the
requirement to validate the CRL through a valid certificate path.

This draft only introduces a new way to point to locate certificates
that can be helpful in building this path. It seems to me from that
perspective that specific requirements on CRL path building are outside
the scope of this draft.



>Stefan Santesson
>Program Manager - Standards Liaison
>Windows Security
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Denis Pinkas
> Sent: den 11 april 2005 00:59
> To: Stefan Santesson; Russ Housley
> Cc: pkix
> Subject: Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> 
> Stefan and Russ,
> 
> It took me several hours to write this long e-mail, hence for the
delay
> (in addition to the time for shooting a few "big five" with my
camera).
> 
> This e-mail identifies several security issues, which are not
currently
> mentionned in the security considerations section. It finally proposes
a
> rewritting of the introduction and provides a strawman for a new
security
> considerations section (see the proposal at the end of this e-mail).
> 
> Let us consider two different scenarios where this new extension would
be
> considered.
> 
> Scenario A: The relying party does not trust any CRL issuer in
particular
> and will simply use the CRL Issuer designated by the Certificate
Issuer by
> means of the CRL DP extension.
> 
> Scenario B: The relying party trusts at least a specific CRL issuer
and
> will
> get the CRLs from that CRL Issuer and then will make sure that the
> information contained in them matches with the designation of the
> Certificate Issuer.
> 
> SCENARIO A
> 
> In scenario A, the relying party will use the CRL DP from the target
> certificate to get the CRL and then will make sure that the CRL that
has
> been retrieved from that location is signed by the right CRL Issuer.
> 
> The CRL DP extension is defined as:
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     DistributionPointName
OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
> At least the distributionPoint field shall be present. It is supposed
it
> contains a general name of type URI, which is a pointer to the current
CRL
> for the associated reasons and will be issued by the associated
cRLIssuer.
> 
> The CRL itself shall contain an IDP (Issuing Distribution Point).
> 
> The IDP extension is defined as:
> 
>     issuingDistributionPoint ::= SEQUENCE {
>          distributionPoint          [0] DistributionPointName
OPTIONAL,
>          onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
>          onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
>          onlySomeReasons            [3] ReasonFlags OPTIONAL,
>          indirectCRL                [4] BOOLEAN DEFAULT FALSE,
>          onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
> 
> A necessary but insufficient condition is that the distributionPoint
field
> from the IDP extension shall be equal to the distributionPoint field
from
> the CRL DP extension.
> 
> This is insufficient since a URL like
URL=http://corppki/crl/extranet.crl
> could be used by accident by two different CAs, or a CA under the same
> root
> key could maliciously use that URL or a different and re-route all
packets
> to an address where that CRL is made available.
> 
> This means that the tupple CRL DP extension from certificates and the
IDP
> extension from CRLs even if then match are insufficient to make sure
that
> it
> is the right CRL that has been retrieved. This is "normal" until some
> cryptographic checksums are used to make sure that this is the right
> information.
> 
> Any CA, trusted under a root key, could use an IDP extension in a CRL
> matching the IDP extension from another true CRL and unless other
tests
> are
> performed, would fool relying parties.
> 
> This is the major reason why the current document in its current form
is
> dangerous to be published. It incorporates verification concepts which
are
> missing major security issues. The security consideration section
attempts
> to tackle the issue but it misses the point.
> 
> The major problem is not the definition of this new extension that
could
> provide untrusted but "useful" information, but the concepts behind
path
> construction.
> 
> SCENARIO B
> 
> In scenario B, the relying party contacts the location of a trusted
CRL
> Issuer and wants to verify that the retrieved CRL is correctly signed.
> 
> Suppose that the retrieved CRL contains the newly defined extension
which
> specifies one or more accessLocation fields that contains references
to CA
> certificates superior to the CRL containing this extension.
> 
> Let us consider that one accessLocation field contains the following
URL:
> http://corppki/aia/certificates.crt
> 
> The relying party will access this URL to retrieve some CA
certificates.
> Nothing at this point would prevent a network attack so that access to
> this
> URL is re-routed to another location. The question is how the relying
> party
> can figure out and what kind of tests it should make. The draft is
silent
> about this.
> 
> It does not help the end-user to define new extensions if at the same
time
> there are no explanations or guidance to tell how are they should be
used
> in
> order to build a secure system.
> 
> Let us suppose that the information retrieved is just "useful"
> certificates
> at this time (i.e. untrusted).
> 
> In order to build a path, a relying party needs to make sure of the
name
> of
> the CRL Issuer, which means not simply knowing the DN of the CRL
issuer
> but
> also all the other DNs from the upper CAs up to a root key. This kind
of
> assumption or explanations is currently missing in the draft.
> 
> Scenario B would be correctly supported if the text would mention two
> points:
> 
>     1) the location of the "trusted CRL Issuer" must be locally known,
>     2) the name of the "trusted CRL Issuer" must be locally known,
>        which means not simply knowing the DN of the CRL issuer,
>        but also all the other DNs from the upper CAs up to a root key.
> 
> Using the "useful" certificates that would be retrieved using that new
> extension, the relying party would then build a certification path to
> validate the retrieved CRL. Additional details, described nowhere,
should
> be
> given so that it can be sure that it is a CRL Issuer and not a CA, etc
...
> 
> Then the relying party knows that he got a correct indirect CRL and
has to
> make sure that the name of the CA is present. Additional details would
be
> needed to explain name matching taking into account that two CAs could
be
> given the same DN by two different CAs.
> 
> 
> CONCLUSION:
> 
> I see two ways to progress:
> 
>     a) "avoid" the problem *now* and leave it for later. This means
>        saying that this extension may provide useful information that
>        still needs to be verified to be trusted. The security
>        considerations section would tackle the issue but not provide
>        the full answer.
> 
>     b) address the issue and say how to handle CRLs when they are not
> signed
>        by the CA.
> 
> In case of a), that is the easiest *temporary* solution, I would
propose
> to
> rewrite the introduction in the following way :
> 
>     RFC 3280 [PKIX1] specifies the validation of certification paths.
>     One aspect involves the determination that a certificate has not
been
>     revoked, and one revocation checking mechanism is the Certificate
>     Revocation List (CRL). Checking a CRL when the CRL is signed by
the
>     key of the Issuing CA is straightforward, but not necessarily
>     otherwise.
> 
>     There are several legitimate scenarios where the certificate of
the
>     CRL issuer is not present, or easily discovered.
> 
>     Standardized methods of finding the certificate of the CRL issuer
are
>     currently available either though an accessible directory location
or
>     through use of the Subject Information Access extension in
>     intermediary CA certificates.
> 
>     Directory lookup requires presence and access to a directory.  The
>     Subject Information Access extension supports building
certification
>     paths top-down (in the direction from the trust anchor to the CRL
>     issuer), which will succeed if certificates include an appropriate
>     Subject Information Access extension. Additional methods allowing
>     the building of certification paths bottom-up to validate CRLs
>     may be useful as well. This is the topic of this document.
> 
>     RFC 3280 [PKIX1] has provided for bottom-up discovery of
>     certification paths through the Authority Information Access
>     extension, where the id-ad-caIssuers access method may specify one
or
>     more accessLocation fields that contain references to CA
certificates
>     superior to the certificate containing this extension.
> 
>     This document permits use of the Authority Information Access
>     extension in CRLs, enabling a CRL checking application to use the
>     same access method (id-ad-caIssuers) to locate the certificate of
>     the CRL issuer and complete the certification path building to an
>     appropriate trust anchor.
> 
>     This extension may be used in the case when indirect CRLs are
used,
>     when the certification Authority (CA) that issued the CRL
certificate
>     changes its certificate signing key, or when the CA employs
separate
>     keys for certificate signing and CRL signing.
> 
> A typo would need to be corrected in section 2: change
> AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax.
> 
> Section 3 about Security Considerations would need to be changed.
> Hereafter is a proposal:
> 
> 3  Security Considerations
> 
>       Implementers should take into account the possible existence of
>       multiple unrelated CAs and CRL issuers with the same DN, as well
>       as the possibility for some trusted CAs (i.e. trusted to issue
>       their own certificates and associated revocation status
information
>       but not trusted not handle revocation information from other
CAs)
>       to purposely use URLs or CRL DPs identical to some CRL DPs from
>       other CAs and at the same time mounting a re-routing attack.
> 
>       This means that finding a CA certificate at the location
indicated
>       by this new extension is insufficient to make sure that it is
the
>       right one, and by consequence that the CRL where this extension
>       has been found is also the right one.
> 
>       When the CRL contains the indirectCRL boolean set to TRUE, then
the
>       relying party should locally know the URL of the CRL issuer(s)
that
>       it directly trusts and also the associated name of the trusted
CRL
>       issuer, which means not simply knowing the DN of the CRL issuer,
>       but also all the other DNs of the upper CAs up to a root key
(since
>       two CAs might be given the same DN by two different CAs).
> 
>       When the CRL is a direct CRL, then relying parties shall make
sure
>       that the certificate of the CRL issuer has been issued by the
same
>       CA that has issued the target certificate.
> 
>       Implementers should always take the steps of validating the
>       retrieved data to ensure that the data is properly formed.
> 
> Of course, much more could be said and an informative annex would be
quite
> useful.
> 
> In case of b), more work would need to be done.
> 
> Denis
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3B81iJD049468; Mon, 11 Apr 2005 01:01:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3B81iTx049467; Mon, 11 Apr 2005 01:01:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3B81BTB049230 for <[e-mail]>; Mon, 11 Apr 2005 01:01:13 -0700 (PDT) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA12704; Mon, 11 Apr 2005 10:14:21 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005041109592907:2109 ; Mon, 11 Apr 2005 09:59:29 +0200 
Message-ID: <[e-mail]>
Date: Mon, 11 Apr 2005 09:59:28 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>, Russ Housley <[e-mail]>
CC: pkix <[e-mail]>
Subject: Comments on <draft-ietf-pkix-crlaia-00.txt>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/04/2005 09:59:29, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/04/2005 10:01:04, Serialize complete at 11/04/2005 10:01:04
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3B81ETB049269
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan and Russ,

It took me several hours to write this long e-mail, hence for the delay
(in addition to the time for shooting a few “big five” with my camera).

This e-mail identifies several security issues, which are not currently 
mentionned in the security considerations section. It finally proposes a 
rewritting of the introduction and provides a strawman for a new security 
considerations section (see the proposal at the end of this e-mail).

Let us consider two different scenarios where this new extension would be 
considered.

Scenario A: The relying party does not trust any CRL issuer in particular 
and will simply use the CRL Issuer designated by the Certificate Issuer by 
means of the CRL DP extension.

Scenario B: The relying party trusts at least a specific CRL issuer and will 
get the CRLs from that CRL Issuer and then will make sure that the 
information contained in them matches with the designation of the 
Certificate Issuer.

SCENARIO A

In scenario A, the relying party will use the CRL DP from the target 
certificate to get the CRL and then will make sure that the CRL that has 
been retrieved from that location is signed by the right CRL Issuer.

The CRL DP extension is defined as:

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

At least the distributionPoint field shall be present. It is supposed it 
contains a general name of type URI, which is a pointer to the current CRL 
for the associated reasons and will be issued by the associated cRLIssuer.

The CRL itself shall contain an IDP (Issuing Distribution Point).

The IDP extension is defined as:

    issuingDistributionPoint ::= SEQUENCE {
         distributionPoint          [0] DistributionPointName OPTIONAL,
         onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
         onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
         onlySomeReasons            [3] ReasonFlags OPTIONAL,
         indirectCRL                [4] BOOLEAN DEFAULT FALSE,
         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }

A necessary but insufficient condition is that the distributionPoint field 
from the IDP extension shall be equal to the distributionPoint field from 
the CRL DP extension.

This is insufficient since a URL like URL=http://corppki/crl/extranet.crl 
could be used by accident by two different CAs, or a CA under the same root 
key could maliciously use that URL or a different and re-route all packets 
to an address where that CRL is made available.

This means that the tupple CRL DP extension from certificates and the IDP 
extension from CRLs even if then match are insufficient to make sure that it 
is the right CRL that has been retrieved. This is “normal” until some 
cryptographic checksums are used to make sure that this is the right 
information.

Any CA, trusted under a root key, could use an IDP extension in a CRL 
matching the IDP extension from another true CRL and unless other tests are 
performed, would fool relying parties.

This is the major reason why the current document in its current form is 
dangerous to be published. It incorporates verification concepts which are 
missing major security issues. The security consideration section attempts 
to tackle the issue but it misses the point.

The major problem is not the definition of this new extension that could 
provide untrusted but “useful” information, but the concepts behind path 
construction.

SCENARIO B

In scenario B, the relying party contacts the location of a trusted CRL 
Issuer and wants to verify that the retrieved CRL is correctly signed.

Suppose that the retrieved CRL contains the newly defined extension which 
specifies one or more accessLocation fields that contains references to CA 
certificates superior to the CRL containing this extension.

Let us consider that one accessLocation field contains the following URL: 
http://corppki/aia/certificates.crt

The relying party will access this URL to retrieve some CA certificates.
Nothing at this point would prevent a network attack so that access to this 
URL is re-routed to another location. The question is how the relying party 
can figure out and what kind of tests it should make. The draft is silent 
about this.

It does not help the end-user to define new extensions if at the same time 
there are no explanations or guidance to tell how are they should be used in 
order to build a secure system.

Let us suppose that the information retrieved is just “useful” certificates 
at this time (i.e. untrusted).

In order to build a path, a relying party needs to make sure of the name of 
the CRL Issuer, which means not simply knowing the DN of the CRL issuer but 
also all the other DNs from the upper CAs up to a root key. This kind of 
assumption or explanations is currently missing in the draft.

Scenario B would be correctly supported if the text would mention two points:

    1) the location of the “trusted CRL Issuer” must be locally known,
    2) the name of the “trusted CRL Issuer” must be locally known,
       which means not simply knowing the DN of the CRL issuer,
       but also all the other DNs from the upper CAs up to a root key.

Using the “useful” certificates that would be retrieved using that new 
extension, the relying party would then build a certification path to 
validate the retrieved CRL. Additional details, described nowhere, should be 
given so that it can be sure that it is a CRL Issuer and not a CA, etc ...

Then the relying party knows that he got a correct indirect CRL and has to 
make sure that the name of the CA is present. Additional details would be 
needed to explain name matching taking into account that two CAs could be 
given the same DN by two different CAs.


CONCLUSION:

I see two ways to progress:

    a) “avoid” the problem *now* and leave it for later. This means
       saying that this extension may provide useful information that
       still needs to be verified to be trusted. The security
       considerations section would tackle the issue but not provide
       the full answer.

    b) address the issue and say how to handle CRLs when they are not signed
       by the CA.

In case of a), that is the easiest *temporary* solution, I would propose to 
rewrite the introduction in the following way :

    RFC 3280 [PKIX1] specifies the validation of certification paths.
    One aspect involves the determination that a certificate has not been
    revoked, and one revocation checking mechanism is the Certificate
    Revocation List (CRL). Checking a CRL when the CRL is signed by the
    key of the Issuing CA is straightforward, but not necessarily
    otherwise.

    There are several legitimate scenarios where the certificate of the
    CRL issuer is not present, or easily discovered.

    Standardized methods of finding the certificate of the CRL issuer are
    currently available either though an accessible directory location or
    through use of the Subject Information Access extension in
    intermediary CA certificates.

    Directory lookup requires presence and access to a directory.  The
    Subject Information Access extension supports building certification
    paths top-down (in the direction from the trust anchor to the CRL
    issuer), which will succeed if certificates include an appropriate
    Subject Information Access extension. Additional methods allowing
    the building of certification paths bottom-up to validate CRLs
    may be useful as well. This is the topic of this document.

    RFC 3280 [PKIX1] has provided for bottom-up discovery of
    certification paths through the Authority Information Access
    extension, where the id-ad-caIssuers access method may specify one or
    more accessLocation fields that contain references to CA certificates
    superior to the certificate containing this extension.

    This document permits use of the Authority Information Access
    extension in CRLs, enabling a CRL checking application to use the
    same access method (id-ad-caIssuers) to locate the certificate of
    the CRL issuer and complete the certification path building to an
    appropriate trust anchor.

    This extension may be used in the case when indirect CRLs are used,
    when the certification Authority (CA) that issued the CRL certificate
    changes its certificate signing key, or when the CA employs separate
    keys for certificate signing and CRL signing.

A typo would need to be corrected in section 2: change 
AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax.

Section 3 about Security Considerations would need to be changed.
Hereafter is a proposal:

3  Security Considerations

      Implementers should take into account the possible existence of
      multiple unrelated CAs and CRL issuers with the same DN, as well
      as the possibility for some trusted CAs (i.e. trusted to issue
      their own certificates and associated revocation status information
      but not trusted not handle revocation information from other CAs)
      to purposely use URLs or CRL DPs identical to some CRL DPs from
      other CAs and at the same time mounting a re-routing attack.

      This means that finding a CA certificate at the location indicated
      by this new extension is insufficient to make sure that it is the
      right one, and by consequence that the CRL where this extension
      has been found is also the right one.

      When the CRL contains the indirectCRL boolean set to TRUE, then the
      relying party should locally know the URL of the CRL issuer(s) that
      it directly trusts and also the associated name of the trusted CRL
      issuer, which means not simply knowing the DN of the CRL issuer,
      but also all the other DNs of the upper CAs up to a root key (since
      two CAs might be given the same DN by two different CAs).

      When the CRL is a direct CRL, then relying parties shall make sure
      that the certificate of the CRL issuer has been issued by the same
      CA that has issued the target certificate.

      Implementers should always take the steps of validating the
      retrieved data to ensure that the data is properly formed.

Of course, much more could be said and an informative annex would be quite 
useful.

In case of b), more work would need to be done.

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38Iwr0x089781; Fri, 8 Apr 2005 11:58:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38IwrUw089780; Fri, 8 Apr 2005 11:58:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j38Iwmn6089770 for <[e-mail]>; Fri, 8 Apr 2005 11:58:50 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 8258 invoked by uid 0); 8 Apr 2005 18:48:08 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.244.35) by woodstock.binhost.com with SMTP; 8 Apr 2005 18:48:08 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Fri, 08 Apr 2005 14:15:42 -0400
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

> > >The text at the end of chapter two seems to allow two
> > >different treatments for an entity that KNOWS the
> > >extension depending on the criticality bit.
> >
> > How about this instead:
> >
> >     If a certificate contains both a key usage extension and an extended
> >     key usage extension, then both extensions MUST be processed
> >     independently and the certificate MUST only be used for a purpose
> >     consistent with both extensions.  If there is no purpose consistent
> >     with both extensions, then the certificate MUST NOT be used for any
> >     purpose.
>
>isn't this just a copy of rfc 3280 or its *bis, there is no value
>added information concerning 3770bis, if is nothing in the treatment
>that differs from the standard one. If so, it seems to be superfluous. to me.

The previous text was intended to help the reader, avoiding the need to 
reread RFC 3280 to get the concepts.  I think this text meets this same goal.

> > >if I compere the last two paragraphs with similar ones
> > >in rfc 2459 or 3280, it seems that the text is at least
> > >confusing.
> >
> > How about this instead:
> >
> >     The extended key usage extension MAY, at the option of the certificate
> >     issuer, be either critical or non-critical.
>Ok.
>
> >
> >     If the extended key usage extension is present, then the certificate
> >     MUST only be used for one of the purposes indicated.  If multiple
>                        !
>                        !BY WHOM?
>This sentence is nothing special for this text.

By any certificate user.  I'll edit the sentence.

> >     purposes are indicated the application need not recognize all
> >     purposes indicated, as long as the intended purpose is present.
>This sentence sounds ok.
>
> >     Certificate using applications MAY require that a particular purpose
> >     (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in
> >     order for the certificate to be acceptable to that application.
>This one is a good one.
>
> >
> > >I think the best is, not to remove them here, and not try for
> > >'convenience' to give a definition at all.
> > >
> > >Or, define a keyPurpose, say whether it is critical or
> > >not, or don't say anything, and specify the treatment when
> > >it is recognized.
> >
> > I think the above proposed changes address these points.
> >
> > >The text also references keyUsage, but does not say which
> > >keyUsage bits are compatible with the defined KeyPurposes.
> >
> > This depends on the EAP method that is employed.  I propose the following:
> >
> >     If a certificate contains a key usage extension, the KeyUsage bits
> >     that are needed depends on the EAP method that is employed; however,
> >     the keyCertSign bit and the cRLSign MUST NOT be associated with
> >     EAP method end entity certificates.
>
>This text sounds like a new feature not present before.
>I suggest to list the keyUasge that influence the EAP method,
>and not the other way around.

That would be listing all of the other bits.  For example, EAP-TLS has the 
same rules as TLS, which depends on the cipher suite that is 
negotiated.  Other EAP methods could be defined in the future that make use 
of the other ones.

> > >X.208 and X.209 are a bit outdated. is 1.3 necessary?
> > >It is not in rfc 3280, as far as I see.
> >
> > The section is necessary to make ASN.1 a normative reference.
>see response from Peter Gutmann.
> >
> > These are the same ASN.1 references used by RFC 3280.  I would rather
> > maintain the same dependencies.
>
>3280 has no reference to X.208 or else, at least not in the
>reference section. The syntax that you use is conformant to ASN.1,
>to any of the versions as far as I see. you don't use macros, or
>obsolete features, so referencing X.208 etc can be seen as if you
>require that a compiler or else is restricted to support this old
>version.

My mistake.  I'll fix it to use the same references as RFC 3280.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38HTYBb083991; Fri, 8 Apr 2005 10:29:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38HTYh9083990; Fri, 8 Apr 2005 10:29:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38HTWj6083983 for <[e-mail]>; Fri, 8 Apr 2005 10:29:33 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j38HTMn03142; Fri, 8 Apr 2005 19:29:22 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.9); Fri, 8 Apr 2005 19:29:22 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j38HTLY21019; Fri, 8 Apr 2005 19:29:21 +0200 (MEST)
Date: Fri, 8 Apr 2005 19:29:21 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [e-mail], [e-mail]@bbn.com, [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for the fast reply.

> 
> Given the minor change that was made, I am surprised to see substantive 
> comments.  However, I agree with your comments.  I propose replacement text 
> below.

once a text becomes RFC, nobody reads it, as soon as it becomes
subject for update ...

> 
> >The text at the end of chapter two seems to allow two
> >different treatments for an entity that KNOWS the
> >extension depending on the criticality bit.
> 
> How about this instead:
> 
>     If a certificate contains both a key usage extension and an extended
>     key usage extension, then both extensions MUST be processed
>     independently and the certificate MUST only be used for a purpose
>     consistent with both extensions.  If there is no purpose consistent
>     with both extensions, then the certificate MUST NOT be used for any
>     purpose.

isn't this just a copy of rfc 3280 or its *bis, there is no value
added information concerning 3770bis, if is nothing in the treatment 
that differs from the standard one. If so, it seems to be superfluous. to me. 

> 
> >if I compere the last two paragraphs with similar ones
> >in rfc 2459 or 3280, it seems that the text is at least
> >confusing.
> 
> How about this instead:
> 
>     The extended key usage extension MAY, at the option of the certificate
>     issuer, be either critical or non-critical.
Ok. 

> 
>     If the extended key usage extension is present, then the certificate
>     MUST only be used for one of the purposes indicated.  If multiple
                       !  
                       !BY WHOM?
This sentence is nothing special for this text. 


>     purposes are indicated the application need not recognize all
>     purposes indicated, as long as the intended purpose is present.
This sentence sounds ok. 

>     Certificate using applications MAY require that a particular purpose
>     (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in
>     order for the certificate to be acceptable to that application.
This one is a good one. 

> 
> >I think the best is, not to remove them here, and not try for
> >'convenience' to give a definition at all.
> >
> >Or, define a keyPurpose, say whether it is critical or
> >not, or don't say anything, and specify the treatment when
> >it is recognized.
> 
> I think the above proposed changes address these points.
> 
> >The text also references keyUsage, but does not say which
> >keyUsage bits are compatible with the defined KeyPurposes.
> 
> This depends on the EAP method that is employed.  I propose the following:
> 
>     If a certificate contains a key usage extension, the KeyUsage bits
>     that are needed depends on the EAP method that is employed; however,
>     the keyCertSign bit and the cRLSign MUST NOT be associated with
>     EAP method end entity certificates.

This text sounds like a new feature not present before. 
I suggest to list the keyUasge that influence the EAP method,
and not the other way around. 

> 
> >X.208 and X.209 are a bit outdated. is 1.3 necessary?
> >It is not in rfc 3280, as far as I see.
> 
> The section is necessary to make ASN.1 a normative reference.
see response from Peter Gutmann.
> 
> These are the same ASN.1 references used by RFC 3280.  I would rather 
> maintain the same dependencies.

3280 has no reference to X.208 or else, at least not in the
reference section. The syntax that you use is conformant to ASN.1,
to any of the versions as far as I see. you don't use macros, or
obsolete features, so referencing X.208 etc can be seen as if you
require that a compiler or else is restricted to support this old
version.  

> 
> Russ
> 
> 
Peter



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38G39iC073642; Fri, 8 Apr 2005 09:03:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38G38Q2073641; Fri, 8 Apr 2005 09:03:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j38G37OD073635 for <[e-mail]>; Fri, 8 Apr 2005 09:03:08 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 2865 invoked by uid 0); 8 Apr 2005 15:53:35 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.7.131) by woodstock.binhost.com with SMTP; 8 Apr 2005 15:53:35 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Fri, 08 Apr 2005 11:53:34 -0400
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

Given the minor change that was made, I am surprised to see substantive
comments.  However, I agree with your comments.  I propose replacement text
below.

 >The text at the end of chapter two seems to allow two
 >different treatments for an entity that KNOWS the
 >extension depending on the criticality bit.

How about this instead:

     If a certificate contains both a key usage extension and an extended
     key usage extension, then both extensions MUST be processed
     independently and the certificate MUST only be used for a purpose
     consistent with both extensions.  If there is no purpose consistent
     with both extensions, then the certificate MUST NOT be used for any
     purpose.

 >if I compere the last two paragraphs with similar ones
 >in rfc 2459 or 3280, it seems that the text is at least
 >confusing.

How about this instead:

     The extended key usage extension MAY, at the option of the certificate
     issuer, be either critical or non-critical.

     If the extended key usage extension is present, then the certificate
     MUST only be used for one of the purposes indicated.  If multiple
     purposes are indicated the application need not recognize all
     purposes indicated, as long as the intended purpose is present.
     Certificate using applications MAY require that a particular purpose
     (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in
     order for the certificate to be acceptable to that application.

 >I think the best is, not to remove them here, and not try for
 >'convenience' to give a definition at all.
 >
 >Or, define a keyPurpose, say whether it is critical or
 >not, or don't say anything, and specify the treatment when
 >it is recognized.

I think the above proposed changes address these points.

 >The text also references keyUsage, but does not say which
 >keyUsage bits are compatible with the defined KeyPurposes.

This depends on the EAP method that is employed.  I propose the following:

     If a certificate contains a key usage extension, the KeyUsage bits
     that are needed depends on the EAP method that is employed; however,
     the keyCertSign bit and the cRLSign MUST NOT be associated with
     EAP method end entity certificates.

 >X.208 and X.209 are a bit outdated. is 1.3 necessary?
 >It is not in rfc 3280, as far as I see.

The section is necessary to make ASN.1 a normative reference.

These are the same ASN.1 references used by RFC 3280.  I would rather
maintain the same dependencies.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38F1pvS068819; Fri, 8 Apr 2005 08:01:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38F1pRr068818; Fri, 8 Apr 2005 08:01:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j38F1nUt068811 for <[e-mail]>; Fri, 8 Apr 2005 08:01:49 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 28620 invoked by uid 0); 8 Apr 2005 14:53:58 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.0.141) by woodstock.binhost.com with SMTP; 8 Apr 2005 14:53:58 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Fri, 08 Apr 2005 10:53:48 -0400
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [e-mail], [e-mail]@bbn.com, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

Given the minor change that was made, I am surprised to see substantive 
comments.  However, I agree with your comments.  I propose replacement text 
below.

>The text at the end of chapter two seems to allow two
>different treatments for an entity that KNOWS the
>extension depending on the criticality bit.

How about this instead:

    If a certificate contains both a key usage extension and an extended
    key usage extension, then both extensions MUST be processed
    independently and the certificate MUST only be used for a purpose
    consistent with both extensions.  If there is no purpose consistent
    with both extensions, then the certificate MUST NOT be used for any
    purpose.

>if I compere the last two paragraphs with similar ones
>in rfc 2459 or 3280, it seems that the text is at least
>confusing.

How about this instead:

    The extended key usage extension MAY, at the option of the certificate
    issuer, be either critical or non-critical.

    If the extended key usage extension is present, then the certificate
    MUST only be used for one of the purposes indicated.  If multiple
    purposes are indicated the application need not recognize all
    purposes indicated, as long as the intended purpose is present.
    Certificate using applications MAY require that a particular purpose
    (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in
    order for the certificate to be acceptable to that application.

>I think the best is, not to remove them here, and not try for
>'convenience' to give a definition at all.
>
>Or, define a keyPurpose, say whether it is critical or
>not, or don't say anything, and specify the treatment when
>it is recognized.

I think the above proposed changes address these points.

>The text also references keyUsage, but does not say which
>keyUsage bits are compatible with the defined KeyPurposes.

This depends on the EAP method that is employed.  I propose the following:

    If a certificate contains a key usage extension, the KeyUsage bits
    that are needed depends on the EAP method that is employed; however,
    the keyCertSign bit and the cRLSign MUST NOT be associated with
    EAP method end entity certificates.

>X.208 and X.209 are a bit outdated. is 1.3 necessary?
>It is not in rfc 3280, as far as I see.

The section is necessary to make ASN.1 a normative reference.

These are the same ASN.1 references used by RFC 3280.  I would rather 
maintain the same dependencies.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38BGBJc022023; Fri, 8 Apr 2005 04:16:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38BGBU4022021; Fri, 8 Apr 2005 04:16:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38BG8Hm021991 for <[e-mail]>; Fri, 8 Apr 2005 04:16:09 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 5DC6534A64; Fri,  8 Apr 2005 23:16:07 +1200 (NZST)
Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28382-23; Fri,  8 Apr 2005 23:16:07 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 813F334A58; Fri,  8 Apr 2005 23:16:06 +1200 (NZST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 48A3D3775A; Fri,  8 Apr 2005 23:16:06 +1200 (NZST)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DJrTC-0008QM-00; Fri, 08 Apr 2005 23:16:14 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 08 Apr 2005 23:16:14 +1200
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester <[e-mail]> writes:

>X.208 and X.209 are a bit outdated. is 1.3 necessary?

They're not just outdated, they've been withdrawn, which means that for
standardisation purposes they don't exist any more.  You can't refer to them
in a standard, at least not in any normative sense.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38AoJ7p011118; Fri, 8 Apr 2005 03:50:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38AoJ9p011116; Fri, 8 Apr 2005 03:50:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38AoHAS011095 for <[e-mail]>; Fri, 8 Apr 2005 03:50:18 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j38Anln25787; Fri, 8 Apr 2005 12:49:47 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.9); Fri, 8 Apr 2005 12:49:47 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j38AngX20233; Fri, 8 Apr 2005 12:49:42 +0200 (MEST)
Date: Fri, 8 Apr 2005 12:49:42 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [e-mail], [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The text at the end of chapter two seems to allow two
different treatments for an entity that KNOWS the
extension depending on the criticality bit. 

if I compere the last two paragraphs with similar ones
in rfc 2459 or 3280, it seems that the text is at least
confusing.

I think the best is, not to remove them here, and not try for
'convenience' to give a definition at all. 

Or, define a keyPurpose, say whether it is critical or
not, or don't say anything, and specify the treatment when
it is recognized.

The text also references keyUsage, but does not say which
keyUsage bits are compatible with the defined KeyPurposes.



X.208 and X.209 are a bit outdated. is 1.3 necessary?
It is not in rfc 3280, as far as I see. 

have fun.



Received: from 81-202-202-37.user.ono.com (81-202-202-37.user.ono.com [81.202.202.37]) by above.proper.com (8.12.11/8.12.9) with SMTP id j38A2weZ091784; Fri, 8 Apr 2005 03:03:08 -0700 (PDT) (envelope-from [e-mail])
Received: from 80.20.88.64 by 81.202.202.37; Fri, 08 Apr 2005 09:01:05 -0200
Message-ID: <[e-mail]>
From: "Bernadine Alvarado" <[e-mail]>
Reply-To: "Bernadine Alvarado" <[e-mail]>
To: [e-mail]
Subject: pExttandder is now here! Dont waise your time imprecate
Date: Fri, 08 Apr 2005 06:56:05 -0400
X-Mailer: AOL 4.0 for Windows US sub 543
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--nbqhjz7484462ttyjc"
X-Priority: 3
X-MSMail-Priority: Normal
X-IP: 205.64.9.3

----nbqhjz7484462ttyjc
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit

New... and improved: exxtend your tool now!
simple, safe, quick ! a few minutes and you got yourself a hugge tool, 
with permenent reasults and no surgary needed.
you'll get tired of scrrewing, for sure :)
come take a look now!

The new, bast Exttandder online website!
http://guide.h67.net/pe/erika/whipsaw.htm  


i wish allusion a great season and a safe one mystikal will support you guys in everything you do come by and see us some time at newbury park high school.
specs to the contractor and would pass on the rights to use elliptic-curve on a royalty-free basis.
the airline tickets are for limited dates and or require you to stay a minimum number of nights at specific hotels charging outrageous rates you ll never use them.
my cousin has the a l s disease iam just looking for information on medications and stuff in general.
like that one song i breathe in i ll wait forever for him to figure out that we should be together.
miami personal injury lawyer and miami personal injury attorney information if you live in miami and are looking for a personal injury lawyer or personal injury attorney you are in the.
fácil é ver o que queremos enxergar difícil é saber que nos iludimos com o que achávamos ter visto.
the world s largest retailer now also rents dvd movies just like netflix inc which pioneered internet-based movie renting for a monthly fee with no due dates or late charges.
anyways thought i d break in the new journal - gotta go back to work now! earn my keep! have a groovy day!
hi sherry we hope hunter is better by christmas have a very merrilicious christmas and ho ho ho.
i thought it was easyt too but you know what that means i flunked but at least i believe in miracels.
hi everyone i just like to thank this guest book for allowing all of us to leave our various types of messages … a big thank you !! best to all… dave l.
auto racing and nascar coverage including schedules standings photos nascar irl indy cart nhra formula one.


----nbqhjz7484462ttyjc--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37IIV3F098488; Thu, 7 Apr 2005 11:18:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37IIV5x098486; Thu, 7 Apr 2005 11:18:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37IIUdL098480 for <[e-mail]>; Thu, 7 Apr 2005 11:18:30 -0700 (PDT) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j37II0aP028643; Thu, 7 Apr 2005 14:18:01 -0400
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j37IHs9r003847; Thu, 7 Apr 2005 14:17:54 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Apr 2005 14:19:09 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: PKIX WG Last Call: 3770bis
Cc: [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message initiates a *one week* working group last call 
for  "Certificate Extensions and Attributes Supporting Authentication in 
Point-to-Point Protocol (PPP) and Wireless Local Area Networks 
(WLAN)".  The current draft is available at

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

A one week last call has been selected due to the limited changes with 
respect to RFC 3770. 3770bis and RFC 3770 are identical , with one 
exception. RFC 3770 contained a typographical error in the object 
identifier for the Wireless LAN SSID Attribute Certificate Attribute. 
3770bis corrects the typographical error.

Thanks,

Tim Polk



Received: from 208.184.76.43 ([200.85.209.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id j32KgiVE034475; Sat, 2 Apr 2005 12:43:20 -0800 (PST) (envelope-from [e-mail])
X-Message-Info: 2objr79hjB/oFDXoqQPnQzwTZT75WPw
Received: from actor (40.178.128.239) by t99.cobalt.drawn.conjure.genie.com (InterMail vU.6.27.15.30 6-09-538-55-20324-6332271445) with ESMTP id <08547.TCYF7029.s101-mail.cowherd.grievous.net.cable.rogers.com@aspidistra> for <[e-mail]>; Sat, 02 Apr 2005 13:40:15 -0700
Message-ID: <97310rasf8hy$74901939oea33$41504gy7mwm0@scrupulous>
Reply-To: "Vincent Atwood" <[e-mail]>
From: "Vincent Atwood" <[e-mail]>
To: <[e-mail]>
Subject: If you want origeenal software, this is for you breton
Date: Sun, 03 Apr 2005 00:40:15 +0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--KCRJJPRFI127579677HTBCIN"

----KCRJJPRFI127579677HTBCIN
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit

At the end of every winter we have this for our favorite people.
You can visit now and watch yourself - one of the most familiar
online sites for OEM softwares is here - get the softwares you
need, and for cheep! All are original software!

http://downspoutfmjbimhb29fwgif.laasteriahn.com/


wellhung i m pulling off your panties my tongue is going all over in and out nibbling on you umm wait a minute.
professor newcomb by loosing heat a gaseous body contracts and the heat generated by the contraction exceeds that which it had to lose in order to produce the contraction perpetual motion?
q how many college football players does it take to screw in a light bulb? a only one but he gets three credits for it.
it s like this and like that and like this and uhh and how can i stand here with you and not be moved by you? could you tell me how could it be any better than this? lifehouse everything.
nbsp i hope everybody who visits is having a great fall and getting great weather and happy and healthy with the ones you love!
tengo información de los caracoles de tierra me gustaría contactarme con quién esté interesado e intercambiar ideas puntos de vista etc.
i can t say that i ve ever written any christian centered poetry but i am a christian and i do like helping people out and praying for them.
picked it up just a few minutes after it was posted -- and immediately plunked on the front page of the ny times internet edition -- within hours it was leading all the hebrew news sites.
i would by aaron carter i m all about you by aaron carter faithfully by journey open arms by journey drowning by bsb and do i have to cry for you by nick carter.
individual library web sites for distance learning support -- links to more than five dozen library sites with examples of how different libraries offer services to distance learners.
a new web site for marc menard has just been launched be sure to stop by and learn more about the actor that plays boyd.
i believe people who are getting angry and use profanity are the ones who can not express themselves as well as their feelings properly.
by kim cooper david smay tom neely.
nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp if you think you grasped what real desire is.
if you live to be a hundred i want to live to be a hundred minus one day so i don t have to live without you!
i ve just had a flashback to a convo we had last week anywho have you pissed off already? shakes head get back here now i wasn t finished with you nbsp.
symbol of the dual man thus castor is the son of the mortal pollux the progeny of the immortal.
michael berg said that when his son was a student at the university of oklahoma he took a course on a remote campus and had to take a bus with fellow students to get there.

----KCRJJPRFI127579677HTBCIN--



Received: from bl4-97-36.dsl.telepac.pt ([81.193.97.36]) by above.proper.com (8.12.11/8.12.9) with SMTP id j327vOok084084; Fri, 1 Apr 2005 23:57:51 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Received: from 39.207.176.2 by i388-hqv060.ro26.cox.net with DAV; Sat, 02 Apr 2005 10:48:45 +0300
Reply-To: "Gina Meyers" <[e-mail]>
From: "Gina Meyers" <[e-mail]>
To: <[e-mail]>
Subject: Posses whatever drag you want caveman
Date: Sat, 02 Apr 2005 11:56:45 +0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--WSJV9854247DBGEICUGK"

----WSJV9854247DBGEICUGK
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit

neew, improoved drags on our online website!
just try us, you wont be dissappointed...
for sure :)

you wont stop scrrewing with viaggra, enjoy!:
http://chalmers.edyo.com/p/erika/20/someone.htm

wanna get rid of smoking? Zybban is the simple and elegant answer:
http://chalmers.edyo.com/p/erika/28/fugue.htm

lose wieght fast and easy? Maridia is the ultimate solution:
http://chalmers.edyo.com/p/erika/6/accretion.htm

loosing hair? stop it now! look good again with Propesia, recomended! :
http://chalmers.edyo.com/p/erika/12/eugenic.htm


main page:
http://chalmers.edyo.com/p/erika/atmospheric.htm

also:
men's haelth
mucsle relexers
pajn reliev

good afternoon from eindhoven the netherlands very good info and nice pictures iwish you merry christmas and happy new year best regards albert.
the coal room is an enormous space with a conveyor belt high in the rafters which pulled coal from the train now the d line which runs behind the facility the coal would then be sent down.
this is me and mamatzo shes a little girl in doornbach that comes to me and is very much attached to me.
over strenuous objections from the bush administration congress is moving to increase protections for federal employees who expose fraud waste and wrongdoing inside the government.
we have one new affiliate the webmaster is just a beginner so be nice! we like the site though! watch american idol tonight to see america voted off!
deals with the half dozen or so acute vcr problems that may tempt you to throw something through the window - or worse.
but it is entirely possible just ask juan down at the corner for a pack of marlboros it may not be pretty but it will work.
which stand for the complete truth thanks for the kjv as well aren t too many left that love the bible the kjv way!!
omw you think your nervous talk about me hahahaha wow man i just can t wait for this to actually happen.
the tan-colored soda sold out in just three hours after an initial batch was put up for sale on the company s web site friday a spokeswoman for the company said.
let the coming era be dedicated to the resurrection and awakening of universal motherhood said amma in her address.
i wish to travel from lexington ky to either los angeles ca or san francisco ca and i m trying to figure out how to do this via computer.
i am looking for short trip information my wife nor i have been on train trips and are interested.
are you familiar with asscher cut diamonds? if so what could you tell me are ideal characteristics of the diamond my fiancee and i are looking to purchase an asscher cut.


----WSJV9854247DBGEICUGK--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31KR7f7003197; Fri, 1 Apr 2005 12:27:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j31KR7VH003196; Fri, 1 Apr 2005 12:27:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31KR6hs003190 for <[e-mail]>; Fri, 1 Apr 2005 12:27:07 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06253; Fri, 1 Apr 2005 15:27:02 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ecc-pkalgs-01.txt
Date: Fri, 01 Apr 2005 15:27:02 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Additional Algorithms and Identifiers for use of Elliptic Curve Cryptography with PKIX
	Author(s)	: D. Brown
	Filename	: draft-ietf-pkix-ecc-pkalgs-01.txt
	Pages		: 25
	Date		: 2005-4-1
	
This document gives additional algorithms and associated ASN.1
   identifiers for elliptic curve cryptography (ECC) used with the
   Internet X.509 Public Key Infrastructure Certificate and
   Certificate Revocation List (CRL) Profile (PKIX).  The algorithms
   and identifiers here are consistent with both ANSI X9.62-1998 and
   X9.63-2001, and shall be consistent with the forthcoming revisions
   of these documents.  Consistency shall also be maintained with SEC1
   and SEC2, and any revisions or successors of such documents.

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

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


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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ecc-pkalgs-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--