Subject: TimeStampToken mime type?

From: Alicia da Conceicao <[email-masked]>
Date: Thu, 28 Apr 2005 11:58:29 -0400 (EDT)

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.

---

From: "Miguel A Rodriguez" <[email-masked]>
Date: Thu, 28 Apr 2005 13:08:17 -0500

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Alicia da Conceicao
Sent: Thursday, April 28, 2005 10:58 AM
To: [email-masked]
Subject: TimeStampToken mime type?

Greetings:

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?

Alicia.

---

From: Alicia da Conceicao <[email-masked]>
Date: Thu, 28 Apr 2005 19:14:33 -0400 (EDT)

> CMS-type structure. Maybe you can find some info in the LTANS group

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:

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

Alicia.

---

From: Alicia da Conceicao <[email-masked]>
Date: Thu, 28 Apr 2005 19:14:33 -0400 (EDT)

<<< No Message Collected >>>

---

From: "Miguel A Rodriguez" <[email-masked]>
Date: Fri, 29 Apr 2005 10:20:09 -0500

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:[email-masked]] 
Sent: Thursday, April 28, 2005 6:15 PM
To: Miguel A Rodriguez
Cc: [email-masked]
Subject: Re: TimeStampToken mime type?

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

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:

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

Alicia.

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

---

From: Alicia da Conceicao <[email-masked]>
Date: Sat, 30 Apr 2005 05:55:56 -0400 (EDT)

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?

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.

From: Alicia da Conceicao <[email-masked]>
Subject: Re: TimeStampToken mime type?
To: [email-masked] (Miguel A Rodriguez)
Date: Sat, 30 Apr 2005 05:55:56 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]

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?

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.

From: "Antone Belanger" <[email-masked]>
To: <[email-masked]>
Subject: Acquire softs for nearly no monney! dee
Date: Fri, 29 Apr 2005 12:45:59 -0600

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

Content-class: urn:content-classes:message
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Fri, 29 Apr 2005 18:03:30 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

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

> From: Russ Housley [mailto:[email-masked]]
> 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
> >>
> >>
> >>>From: Denis Pinkas [mailto:[email-masked]]
> >>>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
> >
> >

From: "Miguel A Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: RE: TimeStampToken mime type?
Date: Fri, 29 Apr 2005 10:20:09 -0500
Importance: Normal
Sender: [email-masked]

Miguel

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

Hi Miguel:

Alicia.

> as the offical standard.  Comments???

Date: Fri, 29 Apr 2005 03:25:47 -0400
To: Denis Pinkas <[email-masked]>, Stefan Santesson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Cc: pkix <[email-masked]>
Sender: [email-masked]

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
>>
>>
>>>From: Denis Pinkas [mailto:[email-masked]]
>>>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
>
>

From: Alicia da Conceicao <[email-masked]>
Subject: Re: TimeStampToken mime type?
To: [email-masked] (Miguel A Rodriguez)
Date: Thu, 28 Apr 2005 19:14:33 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]

From: Alicia da Conceicao <[email-masked]>
Subject: Re: TimeStampToken mime type?
To: [email-masked] (Miguel A Rodriguez)
Date: Thu, 28 Apr 2005 19:14:33 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]

Hi Miguel:

Alicia.

> as the offical standard.  Comments???

Content-class: urn:content-classes:message
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Fri, 29 Apr 2005 00:03:33 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

Comments in line;

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> From: Denis Pinkas [mailto:[email-masked]]
> 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
> >
> >
> >
> >>From: Denis Pinkas [mailto:[email-masked]]
> >>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
> >>
> >
> >
> 

Date: Thu, 28 Apr 2005 14:25:22 -0400
To: [email-masked]
From: Shu-jen Chang <[email-masked]>
Subject: Cryptographic Hash Workshop - Call for Participation
Sender: [email-masked]

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

--=====================_14969562==_--

From: "Miguel A Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: RE: TimeStampToken mime type?
Date: Thu, 28 Apr 2005 13:08:17 -0500
Importance: Normal
Sender: [email-masked]

Hi,

Regards,

Miguel Rodriguez
SeguriData
Mexico  

-----Original Message-----

Greetings:

Alicia.

Date: Thu, 28 Apr 2005 19:12:25 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>, Russ Housley <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

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
>  
> 
> 
>>From: Denis Pinkas [mailto:[email-masked]]
>>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
>>
> 
> 

From: Alicia da Conceicao <[email-masked]>
Subject: TimeStampToken mime type?
To: [email-masked]
Date: Thu, 28 Apr 2005 11:58:29 -0400 (EDT)
Sender: [email-masked]

Greetings:

Alicia.

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: US e-Gov dep. turns to gateway PKI
Date: Mon, 25 Apr 2005 22:34:09 +0200
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-crlaia-01.txt
Date: Mon, 25 Apr 2005 16:29:28 -0400
Sender: [email-masked]

--NextPart

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

	Title		: 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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Nicole Mccabe" <[email-masked]>
To: "'Ietf-smtp-request'" <[email-masked]>
Subject: Posses viaggra, propesia and more... now! julio
Date: Sun, 24 Apr 2005 03:28:19 -0100

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

Content-class: urn:content-classes:message
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Sat, 23 Apr 2005 00:02:35 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

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

> From: Denis Pinkas [mailto:[email-masked]]
> 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

Date: Wed, 20 Apr 2005 17:35:47 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Certificate Policy OID registration
Sender: [email-masked]

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

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: Arshad Noor <[email-masked]>, [email-masked]
Subject: RE: Certificate Policy OID registration
Date: Wed, 20 Apr 2005 07:56:08 -0400
Sender: [email-masked]

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

------_=_NextPart_001_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:  732 524 3785

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Arshad Noor
Sent: Tuesday, April 19, 2005 7:52 PM
To: [email-masked]
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: [email-masked]</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:[email-masked]">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: [email-masked]</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--

Reply-To: "Manuel Gil Perez" <[email-masked]>
From: "Manuel Gil Perez" <[email-masked]>
To: <[email-masked]>
Subject: Location of a CMC server
Date: Wed, 20 Apr 2005 11:53:45 +0200
Organization: ANTS Research Group
Sender: [email-masked]

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 

Date: Wed, 20 Apr 2005 10:32:50 +0200
From: Olivier Dubuisson <[email-masked]>
Organization: France Telecom - Research & Development
To: "Legendre, Robert" <[email-masked]>
CC: [email-masked]
Subject: Re: Certificate Policy OID registration
Sender: [email-masked]

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: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/

To: Bob Wheeler <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: XML schema or dtd for X.509?
From: Martin Clausen <[email-masked]>
Date: Wed, 20 Apr 2005 09:51:35 +0200
Sender: [email-masked]

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 <[email-masked]>
IBM Research GmbH, Zurich Research Laboratory
S=E4umerstrasse 4 / Postfach, CH-8803 R=FCschlikon
Phone: (+41) 1 724 8469=20

[email-masked] 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;[email-masked]&gt;<br>
IBM Research GmbH, Zurich Research Laboratory<br>
S=E4umerstrasse 4 / Postfach, CH-8803 R=FCschlikon<br>
Phone: (+41) 1 724 8469 </font>
<br>
<br><font size=3D2><tt>[email-masked] 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_=--

Date: Wed, 20 Apr 2005 17:29:01 +1000
From: Steven Legg <[email-masked]>
To: Bob Wheeler <[email-masked]>
CC: [email-masked]
Subject: Re: XML schema or dtd for X.509?
Sender: [email-masked]

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>

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Tue, 19 Apr 2005 21:26:58 -0700 (PDT)
From: Bob Wheeler <[email-masked]>
Subject: XML schema or dtd for X.509?
To: [email-masked]
Sender: [email-masked]

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

Date: Tue, 19 Apr 2005 16:52:17 -0700
From: Arshad Noor <[email-masked]>
Subject: Re: Certificate Policy OID registration
To: [email-masked]
Organization: StrongAuth, Inc.
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: Certificate Policy OID registration
Date: Tue, 19 Apr 2005 18:34:47 -0400
From: "Legendre, Robert" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-00.txt
From: Jostein Tveit <[email-masked]>
Organization: Norwegian University of Science and Technology
Date: Tue, 19 Apr 2005 20:29:10 +0200
Sender: [email-masked]

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 <[email-masked]>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc3770bis-02.txt
Date: Mon, 18 Apr 2005 15:53:25 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Certificate 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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 18 Apr 2005 15:51:01 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: Dave Engberg <[email-masked]>, [email-masked]
Subject: Re: CoreStreet IPR disclosure
Sender: [email-masked]

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.

Content-class: urn:content-classes:message
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Mon, 18 Apr 2005 14:42:30 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

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
 
> From: Denis Pinkas [mailto:[email-masked]]
> 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

Date: Mon, 18 Apr 2005 13:41:22 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>
CC: Russ Housley <[email-masked]>, pkix <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-00.txt
Date: Fri, 15 Apr 2005 15:36:30 -0400
Sender: [email-masked]

--NextPart

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

	Title		: 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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 15 Apr 2005 18:40:46 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import
Sender: [email-masked]

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

Date: Fri, 15 Apr 2005 18:30:22 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension
Sender: [email-masked]

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
> 

Date: Fri, 15 Apr 2005 18:20:48 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension
Sender: [email-masked]

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

Date: Fri, 15 Apr 2005 11:03:46 -0400
To: "Dave Engberg" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: CoreStreet IPR disclosure
Sender: [email-masked]

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

Date: Fri, 15 Apr 2005 10:38:24 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension
Sender: [email-masked]

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

Date: Fri, 15 Apr 2005 10:14:47 -0400
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import
Sender: [email-masked]

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.

Content-class: urn:content-classes:message
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Fri, 15 Apr 2005 11:53:55 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

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
 
> From: Denis Pinkas [mailto:[email-masked]]
> 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
> >
> >
> >
> >>From: [email-masked]
> >
> > [mailto:[email-masked]]
> >
> >>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
> >>
> >
> >
> >
> 

Date: Fri, 15 Apr 2005 10:37:32 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: Section 2
Sender: [email-masked]

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.

Date: Fri, 15 Apr 2005 10:25:16 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 15 Apr 2005 10:10:45 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 15 Apr 2005 09:12:03 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: Stefan Santesson <[email-masked]>, pkix <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

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

Date: Thu, 14 Apr 2005 13:45:59 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 14 Apr 2005 13:24:48 -0400
To: Peter Sylvester <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 14 Apr 2005 19:07:30 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: OID Import
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 14 Apr 2005 11:57:35 -0400
To: Denis Pinkas <[email-masked]>, Stefan Santesson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Cc: pkix <[email-masked]>
Sender: [email-masked]

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
>

Date: Thu, 14 Apr 2005 18:36:41 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-rfc3770bis-01: key usage extension
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 14 Apr 2005 11:00:39 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: draft-ietf-pkix-rfc3770bis-01: OID Import
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 14 Apr 2005 10:47:49 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: draft-ietf-pkix-rfc3770bis-01: Section 2
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 14 Apr 2005 10:01:08 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: draft-ietf-pkix-rfc3770bis-01: key usage extension
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 14 Apr 2005 10:49:44 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
Sender: [email-masked]

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

Date: Thu, 14 Apr 2005 10:09:54 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>
CC: Russ Housley <[email-masked]>, pkix <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

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
> 
>  
> 
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>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
>>
> 
> 
> 

Date: Thu, 14 Apr 2005 09:22:48 +1000
From: Steven Legg <[email-masked]>
To: Russ Housley <[email-masked]>
CC: Peter Sylvester <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
Sender: [email-masked]

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

Date: Wed, 13 Apr 2005 16:22:49 -0400
To: Peter Sylvester <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
Sender: [email-masked]

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

Date: Wed, 13 Apr 2005 17:36:14 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: rfc3280 bis
Cc: [email-masked]
Sender: [email-masked]

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

Date: Wed, 13 Apr 2005 10:18:33 -0400
From: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
Sender: [email-masked]

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

Date: Wed, 13 Apr 2005 13:41:15 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt
Date: Tue, 12 Apr 2005 15:39:40 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Certificate 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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: CoreStreet IPR disclosure
Date: Mon, 11 Apr 2005 15:08:36 -0400
From: "Dave Engberg" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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"

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

Date: Mon, 11 Apr 2005 17:42:34 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Mon, 11 Apr 2005 15:28:05 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 11 Apr 2005 09:59:28 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>, Russ Housley <[email-masked]>
CC: pkix <[email-masked]>
Subject: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

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

Date: Fri, 08 Apr 2005 14:15:42 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Fri, 8 Apr 2005 19:29:21 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [email-masked], [email-masked]@bbn.com, [email-masked]
Sender: [email-masked]

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

Date: Fri, 08 Apr 2005 11:53:34 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Fri, 08 Apr 2005 10:53:48 -0400
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [email-masked], [email-masked]@bbn.com, [email-masked]
Sender: [email-masked]

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [email-masked], [email-masked], [email-masked]
Date: Fri, 08 Apr 2005 23:16:14 +1200
Sender: [email-masked]

Peter Sylvester <[email-masked]> 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.

Date: Fri, 8 Apr 2005 12:49:42 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: PKIX WG Last Call: 3770bis
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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.

From: "Bernadine Alvarado" <[email-masked]>
Reply-To: "Bernadine Alvarado" <[email-masked]>
To: [email-masked]
Subject: pExttandder is now here! Dont waise your time imprecate
Date: Fri, 08 Apr 2005 06:56:05 -0400

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

Date: Thu, 07 Apr 2005 14:19:09 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: PKIX WG Last Call: 3770bis
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Reply-To: "Vincent Atwood" <[email-masked]>
From: "Vincent Atwood" <[email-masked]>
To: <[email-masked]>
Subject: If you want origeenal software, this is for you breton
Date: Sun, 03 Apr 2005 00:40:15 +0400

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

Reply-To: "Gina Meyers" <[email-masked]>
From: "Gina Meyers" <[email-masked]>
To: <[email-masked]>
Subject: Posses whatever drag you want caveman
Date: Sat, 02 Apr 2005 11:56:45 +0400

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ecc-pkalgs-01.txt
Date: Fri, 01 Apr 2005 15:27:02 -0500
Sender: [email-masked]

--NextPart

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

	Title		: 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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ecc-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:
	[email-masked].
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="[email-masked]"

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

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:	<[email-masked]>

--OtherAccess--

--NextPart--