Subject: RFC 3379 Compliance Matrix: SCVP draft 22 (intro)

From: Tim Polk <[email-masked]>
Date: Thu, 26 Jan 2006 11:06:57 -0500

I have completed the RFC 3379 compliance matrix for SCVP draft 22.  As the 
compliance matrix is very large (24 pages!), I will post it in three 
parts.  This message includes only a summary of my results and three excerpts.

In my opinion, the current draft of SCVP fully satisfies 31 of the 34 
requirements.  I have selected text and provided references to the sections 
that satisfy the requirements in the compliance matrix.  Where requirements 
have multiple parts, I attempted to identify how each part was satisfied.

For requirements #14, #23, and #29, I could not convince myself that the 
current draft completely satisfied the requirements.  The matrix entries 
for these requirements describe the mechanisms already in SCVP -22 and 
proposes mechanisms for completely satisfying the requirement.  Note that 
in the case of #29, I am unclear why we included this requirement, so 
perhaps I am misinterpreting the text.

I have appended requirements #14, #23, and #29 to this message, for those 
who want to start with the agreed open issues.  (Those requirements are 
included in the completed matrix as well.)

Thanks,

Tim Polk

------------------ Known Open Issues ---------------------

3379 Requirement #14. The DPV server MUST be able, upon request, copy a 
text field provided by the client into the DPV response. (4.1 Basic Protocol)

SCVP Draft 22:

This requirement is poorly addressed in scvp-21

An SCVP request may include a requesterRef, which is a SEQUENCE of 
GeneralNames.

"If the SCVP client includes a requestorRef value in the request, then the 
SCVP server MUST return the same value if the server is generating a 
non-cached response." Section 4.7

One legal value for a GeneralName is an IA5string, so we could argue that 
it is met, but this is a very poor fit.

Proposed Resolution:

Add an optional item, requesterText, to both the CVRequest and CVResponse 
sequences.  The responseText would be UTF8String, maximum size 256 
characters.  There would be no semantics; the server would be required to 
copy the value from the CVRequest into the CVResponse for all non-cached 
responses.

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

3379 Requirement #23. Clients MUST be able to specify whether they want, in 
addition to the certification path, the revocation information associated 
with the path, for the end-entity certificate, for the CA certificates, or 
for both. (5. Delegated Path Discovery Protocol)
SCVP Draft 22:

SCVP does not permit the client to request status for just the EE 
certificate or just the CA certificates.  Clients that request status get 
status information for the entire path.

The SCVP client requests this information by asserting the wantback

"   - id-swb-pkc-revocation-info: Proof of revocation status for each 
certificate in the certification path;"
Section 3.2.3

Propose adding two new wantbacks, id-swb-ee-revocation-info and 
id-swb-CAs-revocation-info with the appropriate functionality.

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

3379 Requirement #29. Path discovery MUST be performed according to the 
path discovery policy.  The DPD response MUST indicate one of the following 
status alternatives:
1.	one or more certification paths was found according to the path 
discovery policy, with all of the requested revocation information present.
2.	one or more certification paths was found according to the path 
discovery policy, with a subset of the requested revocation information 
present.
3.	one or more certification paths was found according to the path 
discovery policy, with none of the requested revocation information present.
4.	no certification path was found according to the path discovery policy.
5.	path construction could not be performed due to an error.
(Source for 29: 5. Delegated Path Discovery Protocol)

SCVP Draft 22:

This requirement is not fully satisfied.  The DPD response will not 
differentiate between states 2 and 3 as described in requirement 29.

The replyStatus item gives status information to the client about the 
request for the specific certificate.

State 1:  If one or more certification paths was found according to the 
path discovery policy, with all of the requested revocation information 
present, the replyStatus will be 0:

"0  Success: all checks were performed successfully."

State 2:  If one or more certification paths was found according to the 
path discovery policy, but only a subset of the requested revocation 
information was available, the replyStatus will be 8:

"8  Failure: all checks were performed successfully, however one or
        more of the wantBacks could not be satisfied."

State 3: If one or more certification paths was found according to the path 
discovery policy, but only a subset of the requested revocation information 
was available, the replyStatus will be 8:

"8  Failure: all checks were performed successfully, however one or
        more of the wantBacks could not be satisfied."

State 4: If no certification path was found according to the path discovery 
policy, the replyStatus will be 5:

"5  Failure: no certification path could be constructed."

State 5:  If path construction could not be performed due to an error, the 
replyStatus will be 1, 2, 3, or 4:

"  1  Failure: the public key certificate was malformed.
     2  Failure: the attribute certificate was malformed.
     3  Failure: historical data for the requested validity time is not
        available.
     4  Failure: the server could not locate the reference certificate or
        the referenced certificate did not match the hash value
        provided."

(Section 4.9.2)

Possible resolution:  This requirement could be met by adding two 
additional reply check status codes for  { id-stc 1} -- but we do not see 
any value in this change!

---

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Jan 2006 13:41:57 -0500

Tim,

Thanks to you and the other authors of SCVP for doing this in 
response to my request.

I hereby solicit comments from the WG on the compliance matrix that 
Tim sent in subsequent messages.  I plan to make a determination on 
forwarding SCVP to the IESG in about two weeks.  Please get comments 
to me before then.

Thanks,

Steve

---

From: Russ Housley <[email-masked]>
Date: Thu, 26 Jan 2006 16:22:17 -0500

All:

I am starting a thread for each of the open issues.  Hopefully, these 
can be brought to closure very quickly.

One could also argue that the Nonce could be used to meet this 
requirement, but like requestorRef, this is not really a good fit.

I think the most expedient solution is to ad the field as Tim suggests.

Tim:

Thanks for all of the work.  This clearly was a lot of effort.

Russ

At 11:06 AM 1/26/2006, Tim Polk wrote:

>3379 Requirement #14. The DPV server MUST be able, upon request, 
>copy a text field provided by the client into the DPV response. (4.1 
>Basic Protocol)
>
>SCVP Draft 22:
>
>"If the SCVP client includes a requestorRef value in the request, 
>then the SCVP server MUST return the same value if the server is 
>generating a non-cached response." Section 4.7
>
>One legal value for a GeneralName is an IA5string, so we could argue 
>that it is met, but this is a very poor fit.
>
>Proposed Resolution:
>
>Add an optional item, requesterText, to both the CVRequest and 
>CVResponse sequences.  The responseText would be UTF8String, maximum 
>size 256 characters.  There would be no semantics; the server would 
>be required to copy the value from the CVRequest into the CVResponse 
>for all non-cached responses.

---

From: Russ Housley <[email-masked]>
Date: Thu, 26 Jan 2006 16:34:40 -0500

All:

I think this is a straightforward one.  I propose the following text changes:

OLD:

     - id-swb-pkc-revocation-info: Proof of revocation status for each
        certificate in the certification path;

NEW:

     - id-swb-pkc-revocation-info: Proof of revocation status for each
        certificate in the certification path;

     - id-swb-pkc-ee-revocation-info: Proof of revocation status for the
        end-entity certificate;

     - id-swb-pkc-ca-revocation-info: Proof of revocation status for each
        issuer certificate in the certification path;

Then, this change needs to be made in two places:

OLD:

      id-swb-pkc-revocation-info     OBJECT IDENTIFIER ::= { id-swb 2 }

NEW:

      id-swb-pkc-revocation-info     OBJECT IDENTIFIER ::= { id-swb 2 }
      id-swb-pkc-ee-revocation-info  OBJECT IDENTIFIER ::= { id-swb 13 }
      id-swb-pkc-ca-revocation-info  OBJECT IDENTIFIER ::= { id-swb 14 }

Russ

At 11:06 AM 1/26/2006, Tim Polk wrote:
>3379 Requirement #23. Clients MUST be able to specify whether they 
>want, in addition to the certification path, the revocation 
>information associated with the path, for the end-entity 
>certificate, for the CA certificates, or for both. (5. Delegated 
>Path Discovery Protocol)
>SCVP Draft 22:
>
>certificate or just the CA certificates.  Clients that request 
>status get status information for the entire path.
>
>"   - id-swb-pkc-revocation-info: Proof of revocation status for 
>each certificate in the certification path;"
>Section 3.2.3
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 26 Jan 2006 16:42:23 -0500

I do not see any value in making a change here.  I suggest that we 
add a section to the Introduction, stating that this protocol meets 
all of the requirements in RFC 3379.  Then go on to say that when 
SCVP is used for DPD, the response is the same when a path is 
constructed, but some and all of the revocation information is 
unavailable.  Provide the text from RFC 3379 and say that 2 and 3 
will result in the same response as some of the revocation 
information is not available.

Russ

At 11:06 AM 1/26/2006, Tim Polk wrote:

>3379 Requirement #29. Path discovery MUST be performed according to 
>the path discovery policy.  The DPD response MUST indicate one of 
>the following status alternatives:
>1.      one or more certification paths was found according to the 
>path discovery policy, with all of the requested revocation 
>information present.
>2.      one or more certification paths was found according to the 
>path discovery policy, with a subset of the requested revocation 
>information present.
>3.      one or more certification paths was found according to the 
>path discovery policy, with none of the requested revocation 
>information present.
>The replyStatus item gives status information to the client about 
>the request for the specific certificate.
>
>State 1:  If one or more certification paths was found according to 
>the path discovery policy, with all of the requested revocation 
>information present, the replyStatus will be 0:
>
>State 2:  If one or more certification paths was found according to 
>the path discovery policy, but only a subset of the requested 
>revocation information was available, the replyStatus will be 8:
>
>State 3: If one or more certification paths was found according to 
>the path discovery policy, but only a subset of the requested 
>revocation information was available, the replyStatus will be 8:
>
>State 4: If no certification path was found according to the path 
>discovery policy, the replyStatus will be 5:
>
>State 5:  If path construction could not be performed due to an 
>error, the replyStatus will be 1, 2, 3, or 4:
>
>additional reply check status codes for  { id-stc 1} -- but we do 
>not see any value in this change!
>

---

From: Tom Gindin <[email-masked]>
Date: Mon, 30 Jan 2006 22:28:14 -0500

Russ:

        Although several values of GeneralName are (IA5) text strings, 
none of them are free-form ones, so they don't really fit this 
requirement.  The solution given in your note seems better.  I do have one 
request for clarification, though.  Is the length limit 256 Unicode 
characters, or 256 octets?  The text suggests Unicode characters, but it 
isn't absolutely clear.  Given that the string is simply copied, a length 
limit in octets might make more sense.  Indeed, in view of the fact that 
the string's internal structure is not important to the server, it might 
be wiser to encode it as an OCTET STRING.

                Tom Gindin

Russ Housley <[email-masked]>
Sent by: [email-masked]
01/26/2006 04:22 PM
 
        To:     [email-masked]
        cc: 
        Subject:        SCVP-22 Open Issue: RFC 3379 Requirement #14

All:

Tim:

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 31 Jan 2006 13:06:30 +0100

The requirement of returing a text was the result of my request to allow 
identifiers
of requestors and responders in both request and response. It seems that the
authors of thge requirement have misunderstood identifier and textual
reference.

Anyway, if a text is to be added, then an opaque octetification doesn't seem
appropriate. A string has no internal structure, but it is still a 
string. The string
still need to be displayed by the client, and other clients in case of 
relaying
etc.

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 31 Jan 2006 11:53:20 -0500

I would suggest:
     UTF8String (SIZE (1..256))

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 31 Jan 2006 13:21:24 -0500

Peter:

>The requirement of returing a text was the result of my request to 
>allow identifiers
>still need to be displayed by the client, and other clients in case 
>of relaying
>etc.

I do not recall the origins at this point.  Your requirements is 
clearly already met by the existing protocol elements.  We need to 
deal with the protocol requirements as documented, or we need to 
changes them, which is more work at this point.

Russ

Date: Tue, 31 Jan 2006 13:21:24 -0500
To: Peter Sylvester <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SCVP-22 Open Issue: RFC 3379 Requirement #14
Cc: [email-masked]
Sender: [email-masked]

Peter:

>The requirement of returing a text was the result of my request to 
>allow identifiers
>still need to be displayed by the client, and other clients in case 
>of relaying
>etc.

I do not recall the origins at this point.  Your requirements is 
clearly already met by the existing protocol elements.  We need to 
deal with the protocol requirements as documented, or we need to 
changes them, which is more work at this point.

Russ

Date: Tue, 31 Jan 2006 11:53:20 -0500
To: Tom Gindin <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SCVP-22 Open Issue: RFC 3379 Requirement #14
Cc: [email-masked]
Sender: [email-masked]

I would suggest:

Russ

> >for all non-cached responses.

Date: Tue, 31 Jan 2006 13:06:30 +0100
From: Peter Sylvester <[email-masked]>
To: Tom Gindin <[email-masked]>
CC: Russ Housley <[email-masked]>, [email-masked]
Subject: Re: SCVP-22 Open Issue: RFC 3379 Requirement #14
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

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

--------------ms040702060700040308050001--

To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: SCVP-22 Open Issue: RFC 3379 Requirement #14
From: Tom Gindin <[email-masked]>
Date: Mon, 30 Jan 2006 22:28:14 -0500
Sender: [email-masked]

        Russ:

                Tom Gindin

        To:     [email-masked]
        cc: 

All:

Tim:

Russ

>for all non-cached responses.

From: "Matt Cooper" <[email-masked]>
To: "'Keutel, Jochen'" <[email-masked]>, <[email-masked]>
Subject: RE: again: pmiUser ...
Date: Mon, 30 Jan 2006 19:19:32 -0500
Sender: [email-masked]

Perhaps I am incorrect, but I would think your initial finding of pmiUser ->
attributeCertificateAttribute would be an appropriate object class and
attribute.  At least one commercial product does this.

pmiUser OBJECT-CLASS ::= {
  SUBCLASS OF  {top}
  KIND         auxiliary
  MAY CONTAIN  {attributeCertificateAttribute}
  ID           id-oc-pmiUser
}

attributeCertificateAttribute ATTRIBUTE ::= {
  WITH SYNTAX             AttributeCertificate
  EQUALITY MATCHING RULE  attributeCertificateExactMatch
  ID                      id-at-attributeCertificate
}

http://www.itu.int/ITU-T/asn1/database/itu-t/x/x509/2000/AttributeCertificat
eDefinitions.html

Best Regards,

Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Keutel, Jochen
Sent: Sunday, December 11, 2005 4:17 PM
To: [email-masked]
Subject: again: pmiUser ...

Hello,
   I didn't get any answer on the question I asked some days ago (see
below). So, let me ask this as follows:

Do you store attribute certificates in LDAP directories? If so:
Which object class are you using?

Bye, Jochen.

---

Hello,
   X.509 defines the LDAP object class pmiUser and the attribute
attributeCertificateAttribute.

I can't find these definitions in LDAP RFCs oder non-expired drafts ...
I found

http://tools.ietf.org/wg/pkix/draft-ietf-pkix-ldap-pmi-schema/draft-ietf-pki
x-ldap-pmi-schema-00.txt

- but it's from June, 2002 ...

Did I miss an I-D and/or RFC?

Regards,  Jochen.

Date: Thu, 26 Jan 2006 18:18:57 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-22.txt
Sender: [email-masked]

[email-masked] wrote:

>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		: Standard Certificate Validation Protocol (SCVP)
>	Author(s)	: A. Malpani, et al.
>	Filename	: draft-ietf-pkix-scvp-22.txt
>	Pages		: 82
>	Date		: 2006-1-23
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-22.txt
>  
>
I have posted a "diff" file on the NIST Web site showing the differences 
between drafts 21 and 22 of SCVP.  It is available at:

http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-21_to_22.html

Draft 22 includes changes that were made to address the requirement for 
algorithm agility, but does not include changes to address any other issues.

As was agreed during the November IETF meeting, ESSCertID has been 
replaced with a data structure that allows the use of any hash algorithm 
rather than being limited to SHA-1.  The hash algorithm used to compute 
the hash of the certificate is specified as part of the data structure.  
The default value for the hash algorithm is SHA-1, so that the DER 
encoding of the data structure is the same as the DER encoding of 
ESSCertID when SHA-1 is used.

Since ESSCertID was the only data structure that hard coded the use of a 
particular cryptographic algorithm, no other data structures needed to 
be changed to allow for algorithm agility.  However, changes needed to 
be made to the protocol in order to allow the client and server to 
signal their capabilities to each other.

In draft 22, the SCVP server signals its capabilities to the client in 
its validation policy response message.  When the client is using 
cryptography in creating its request message, it should choose 
cryptographic algorithms based on the server's indicated capabilities.  
When the server will need to use cryptography in creating the response, 
the client should indicate which algorithm(s) the server should use by 
selecting from the set of algorithms that the server indicates in its 
validation policy response message that it can support.

There are four places that cryptography is used: when the client sends 
an authenticated request to the server; when the server sends an 
authenticated response to the client; when a certificate is specified by 
reference; and when the response includes a hash of the request.

Authenticated request messages may be either digitally signed or MACed.  
For digitally signed request messages, the server indicates the set of 
digital signature algorithms that it is capable of validating 
(signatureVerification).  When key agreement is used, the 
serverPublicKeys item in the validation policy response message 
indicates the set of key agreement keys that the server holds along with 
the key derivation function (KDF) and MAC algorithm that should be used 
with each key.  When pre-shared secret keys are used, it is expected 
that the client will know what MAC algorithm to use through out-of-band 
means.

It is expected that the server's response will be protected with a MAC 
only if the client's request was similarly protected or if there is a 
pre-shared secret key between the client and server.  If the client's 
request was protected with a MAC, the server will use the same 
algorithm(s) to protect the response.  In the case of pre-shared secret 
keys, it is expected that the algorithm to use will be determined 
through out-of-band means.

For digitally signed response messages (CVResponse messages), the server 
indicates in its validation policy response message the set of 
algorithms with with it can sign (signatureGeneration).  That is, it 
lists the algorithms for which its cryptographic module is capable of 
generating the signature and for which it has a certified public key.  
The first algorithm in the signatureGeneration sequence is designated as 
the server's default signature algorithm.  Clients requesting a 
digitally signed CVResponse message may either accept the server's 
default signature algorithm or may specify that the response is to be 
signed using one of the other algorithms listed in the 
signatureGeneration item from the server's validation policy response 
message.

The server's validation policy response message also indicates the set 
of hash algorithms that the server supports (hashAlgorithms), with the 
algorithm in the sequence being the server's default hash algorithm.  If 
the client includes a certificate by reference in its request (either in 
the queriedCerts or trustAnchors item, then the client must use one of 
these algorithms to compute the certHash.  If the client wishes the 
server's response message to include a hash of the request 
(requestHash), the client may either accept the server's default hash 
algorithm or may specify which of the hash algorithms from the 
hashAlgorithms item in the server's validation policy response message 
the server is to use to compute requestHash.

Dave

Date: Thu, 26 Jan 2006 16:42:23 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: SCVP-22 Open Issue: RFC 3379 Requirement #29
Sender: [email-masked]

Russ

>not see any value in this change!

Date: Thu, 26 Jan 2006 16:34:40 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: SCVP-22 Open Issue: RFC 3379 Requirement #23
Sender: [email-masked]

All:

OLD:

NEW:

OLD:

NEW:

Russ

>id-swb-CAs-revocation-info with the appropriate functionality.

Date: Thu, 26 Jan 2006 16:22:17 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: SCVP-22 Open Issue: RFC 3379 Requirement #14
Sender: [email-masked]

All:

Tim:

Russ

>for all non-cached responses.

Date: Thu, 26 Jan 2006 13:41:57 -0500
To: Tim Polk <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: RFC 3379 Compliance Matrix: SCVP draft 22 (intro)
Cc: [email-masked]
Sender: [email-masked]

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

Tim,

Thanks,

Steve
--============_-1073821574==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: RFC 3379 Compliance Matrix: SCVP draft 22
(intro)</title></head><body>
<div>Tim,</div>
<div><br></div>
<div>Thanks to you and the other authors of SCVP for doing this in
response to my request.</div>
<div><br></div>
<div><b>I hereby solicit comments from the WG on the compliance matrix
that Tim sent in subsequent messages.&nbsp; I plan to make a
determination on forwarding SCVP to the IESG in about two weeks.&nbsp;
Please get comments to me before then.</b></div>
<div><br></div>
<div>Thanks,</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1073821574==_ma============--

Date: Thu, 26 Jan 2006 11:11:46 -0500
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: 3379 Compliance Matrix: SCVP-22 (3 of 3)
Cc: [email-masked]
Sender: [email-masked]

[RFC 3379 requirements 25 through 34]

3379 Requirement #25. The DPD request MUST allow more elaborated path 
discovery policies to be referenced. (5. Delegated Path Discovery Protocol)

SCVP Draft 22:

The SCVP client either specifies a particular validation policy or the 
server�s default policy as an object identifier in the validationPolRef 
item.  (section 3.2.4.1)  The parameters associated with this policy may be 
modified through the use of optional items in the validationPolicy. 
(sections 3.2.4.1 through 3.2.4.9)

3379 Requirement #26. If the trust anchor is a self-signed certificate, 
that self-signed certificate MUST NOT be included.  In addition, if 
requested, the revocation information associated with each certificate in 
the path MUST also be returned. (5. Delegated Path Discovery Protocol)

SCVP Draft 22:

DPD servers do not include the self-signed certificate in the returned path.

�The octet string value for the certification path used to verify the 
certificate in the request, { id-swb 1 }, contains the CertBundle 
type.  �  This CertBundle includes all the certificates in the path, 
starting with the end certificate and ending with the certificate issued by 
the trust anchor.�
Section 4.9.5

�The octet string value for the proof of revocation status, { id-swb 2 }, 
contains the RevInfoWantBack type.  The RevInfoWantBack type is a SEQUENCE 
of the RevocationInfos type and an optional CertBundle. The syntax and 
semantics of the RevocationInfos type are described in section 3.2.9.  The 
CertBundle MUST be included if any certificates required to validate the 
revocation information were not returned in the id-swb-pkc-best-cert-path 
or id-swb-pkc-all-cert-paths want back.  The CertBundle MUST include all 
such certificates but there are no ordering requirements.

      RevInfoWantBack ::= SEQUENCE {
        revocationInfo             RevocationInfos,
        extraCerts                 CertBundle OPTIONAL }�
Section 4.9.5

3379 Requirement #27. By default, the DPD server MUST return a single 
certification path for each end-entity certificate in the DPD request. (5. 
Delegated Path Discovery Protocol)

SCVP Draft 22:

DPD clients specify the wantback id-swb-pkc-best-cert-path:

�- id-swb-pkc-best-cert-path: The certification path built for the 
certificate including the certificate that was validated;�
Section 3.2.3

�The octet string value for the certification path used to verify the 
certificate in the request, { id-swb 1 }, contains the CertBundle 
type.  �  This CertBundle includes all the certificates in the path, 
starting with the end certificate and ending with the certificate issued by 
the trust anchor.�
Section 4.9.5

If the DPD client checks revocation information, it will also spefiy the 
wantback id-swb-pkc-revocation-info:

�    - id-swb-pkc-revocation-info: Proof of revocation status for 
eachcertificate in the certification path;�
Section 3.2.3

�The octet string value for the proof of revocation status, { id-swb 2 }, 
contains the RevInfoWantBack type.  The RevInfoWantBack type is a SEQUENCE 
of the RevocationInfos type and an optional CertBundle. The syntax and 
semantics of the RevocationInfos type are described in section 3.2.9.  The 
CertBundle MUST be included if any certificates required to validate the 
revocation information were not returned in the id-swb-pkc-best-cert-path 
or id-swb-pkc-all-cert-paths want back.  The CertBundle MUST include all 
such certificates but there are no ordering requirements.

      RevInfoWantBack ::= SEQUENCE {
        revocationInfo             RevocationInfos,
        extraCerts                 CertBundle OPTIONAL }�
Section 4.9.5

3379 Requirement #28. Therefore, the DPD client MUST have a means of 
obtaining more than one certification path for each end-entity certificate 
in the DPD request.  At the same time, the mechanism for obtaining 
additional certification paths MUST NOT impose protocol state on the DPD 
server. (5. Delegated Path Discovery Protocol)

SCVP Draft 22:

SCVP includes two mechanisms for obtaining additional paths:

(1) If the DPD client wishes to get all the paths the DPD server can find, 
the client asserts the wantback id-swb-pkc-all-cert-paths:

�- id-swb-pkc-all-cert-paths: A set of certification paths for the 
certificate.�
(Section 3.2.3)

�The octet string value for returning all paths, { id-swb 12 }, contains an 
ASN.1 type CertBundles, as defined below.  The syntax and semantics of the 
CertBundle type are described in section 3.2.8. Each CertBundle includes 
all the certificates in one path, starting the end certificate and ending 
with the certificate issued by the trust anchor.

       CertBundles ::= SEQUENCE SIZE (1..MAX) OF CertBundle�

(Section 4.9.5)

No state is imposed by this mechanism, since multiple paths are returned 
from a single request.

(2) The client may also request a single path at a time.  If the server 
detects multiple paths, it may include a serverContextInfo item in the 
response.  If the client does not like the certification path returned, it 
can make a new query and pass along this context information.  After 
obtaining each path, the client could submit the serverContextInfo from the 
previous request to obtain another path until the client either found a 
suitable path or the server indicated (by not returning a 
serverContextInfo) that no more paths were available.

The server may choose to implement serverContextInfo so that all necessary 
state information is embedded in the opaque blob, so state is not imposed 
by the protocol.  (A stateful implementation is also possible, of course.)

(Sections 3.2.6 and 4.11)

SCVP Draft 22:

�0  Success: all checks were performed successfully.�

�8  Failure: all checks were performed successfully, however one or
        more of the wantBacks could not be satisfied.�

�8  Failure: all checks were performed successfully, however one or
        more of the wantBacks could not be satisfied.�

�5  Failure: no certification path could be constructed.�

�  1  Failure: the public key certificate was malformed.
        provided.�

(Section 4.9.2)

3379 Requirement #30.   For the client to be confident that all of the 
elements from the response originate from the expected DPD server, an 
authenticated response MAY be required.  For example, the server might sign 
the response or data authentication might also be achieved using a 
lower-layer security protocol. (5. Delegated Path Discovery Protocol)

SCVP Draft 22:

�The protectResponse item indicates whether the client requires the server 
to protect the response.�  If asserted, the server digitally signs or MACs 
the response.

�SCVP servers MUST support returning protected responses�
(Section 3.2.5.3)

3379 Requirement #31. The DPD server MAY require client authentication, 
allowing the DPD request MUST to be authenticated. (5. Delegated Path 
Discovery Protocol)

SCVP Draft 22:

�A server MAY require all requests to be protected, and a server MAY 
discard all unprotected requests.  Alternatively, a server MAY choose to 
process unprotected requests.�
(Section 3)

3379 Requirement #32. Using a separate request/response pair, the DPV or 
DPD client MUST be able to obtain references for the default policy or for 
all of the policies supported by the server. (6. DPV and DPD Policy Query)

SCVP Draft 22:

An SCVP client uses the Server Policy Request (i.e., the ValPolRequest 
item) �to request information about an SCVP server's policies and 
configuration information, including the list of validation policies 
supported by the SCVP server.�
(Section 5)
�In response to a ValPolRequest, the SCVP server provides a ValPolResponse.�

The ValPolResponse includes a comprehensive description of the default 
validation policy, as well as a list of all policies supported by the server.
(Section 6)

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

SCVP Draft 22:

If one or more certification paths was found according to the validation 
policy, and all requested information  will be 0:

�0  Success: all checks were performed successfully.�

3379 Requirement #34. The validation policy MUST specify the source of 
revocation information:
1.	full CRLs (or full Authority Revocation Lists) have to be collected.
2.	OCSP responses, using [OCSP], have to be collected.
3.	delta CRLs and the relevant associated full CRLs (or full Authority 
Revocation Lists) are to be collected.
4.	any available revocation information has to be collected.
5.	no revocation information need be collected.
(Source for 34: 7.3. Revocation Requirements)

SCVP Draft 22:

The valPolResponse includes the revocationInfoTypes item.

RevocationInfoTypes ::= BIT STRING {
        fullCRLs                   (0),
        deltaCRLs                  (1),
        indirectCRLs               (2),
        oCSPResponses              (3) }

revocationInfoTypes allows the server to indicate the sources of revocation 
information that it is capable of processing.  For each bit in the 
RevocationInfoTypes bit string, the server MUST set the bit to one if it is 
capable of processing the corresponding revocation information type and to 
zero if it can not.

(Sections 6 and 6.11)

Date: Thu, 26 Jan 2006 11:10:18 -0500
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: 3379 Compliance Matrix: SCVP-22 (2 of 3)
Cc: [email-masked]
Sender: [email-masked]

[RFC 3379 requirements 13 through 24]

3379 Requirement #13. The DPV request MUST allow the client to request that 
the server include in its response additional information which will allow 
relying parties not trusting the DPV server to be confident that the 
certificate validation has correctly been performed. [�]When the 
certificate is valid according to the validation policy, the server MUST, 
upon request, include that information in the response.  However, the 
server MAY omit that information when the certificate is invalid or when it 
cannot determine the validity. (4.1 Basic Protocol)

SCVP Draft 22:

Where requested, an SCVP server must return the certification path, status 
information (CRLs, OCSP responses and SCVP responses) and additional 
certificates required to validate the status information. This information 
is sufficient to verify that the validation has been performed correctly.

The SCVP client requests this information by asserting the wantbacks

�  - id-swb-pkc-best-cert-path: The certification path built for the 
certificate including the certificate that was validated;

      - id-swb-relayed-responses: Any SCVP responses received by the server 
that were used to generate the response to this query.�
Section 3.2.3

Support for these wantbacks is optional for DPV servers and required for 
DPD servers:

�Conforming SCVP server implementations that support delegated path 
discovery (DPD) as defined in [RQMTS] MUST support the 
id-swb-pkc-best-cert-path and id-swb-pkc-revocation-info wantBacks.�
Section 3.2.3

If the requester asserts these codes and the SCVP server does not support 
them, the SCVP server must return the CVStatusCode �unsupportedWantBacks�
(Section 4.4)

SCVP Draft 22:

�If the SCVP client includes a requestorRef value in the request, then the 
SCVP server MUST return the same value if the server is generating a 
non-cached response.� Section 4.7

Proposed Resolution:

3379 Requirement #15. The DPV response MUST be bound to the DPV request so 
that the client can be sure that all the parameters from the request have 
been taken into consideration by the DPV server to build the 
response.  This can be accomplished by including a one-way hash of the 
request in the  response. In some environments it may be necessary to 
present only a DPV response to another relying party without the 
corresponding request. In this case the response MUST be self 
contained.  This can be accomplished by repeating only the important 
components from the request in the response. (4.1 Basic Protocol)

SCVP Draft 22:

�By default, the server includes a hash of the request in non-cached 
responses to allow the client to identify the response.  If the client 
wants the server to include the full request in the non-cached response, 
fullRequestInResponse is set to TRUE. (section 3.2.5.1)

The DPV response and request are bound through inclusion of a hash of the 
request, or the request itself, for all non-cached responses.

If the requester chooses to accept cached responses, the client can still 
verify the binding by comparing the parameters from the request, such as 
the requested certificate and the validation policy, with the parameters in 
the cached response.

3379 Requirement #16. For the client to be confident that the certificate 
validation was handled by the expected DPV server, the DPV response MUST be 
authenticated, unless an error is reported (such as a badly formatted 
request or unknown validation policy).For the client to be able prove to a 
third party that trusts the same DPV server that the certificate validation 
was handled correctly, the DPV response MUST be digitally signed, unless an 
error is reported. The DPV server's certificate MUST authenticate the DPV 
server. (4.1 Basic Protocol)

SCVP Draft 22:
�The protectResponse item indicates whether the client requires the server 
to protect the response. �

    SCVP clients that support delegated path validation (DPV) as defined in 
[RQMTS] require an authenticated response.  Unless a protected transport 
mechanism (such a TLS) is used, such clients MUST always set this value to 
TRUE or omit the responseFlags item entirely, which requires the server to 
return a protected response.

    SCVP servers MUST support returning protected responses��

(Section 3.2.5.3)

If the client requests a protected response and signs the request, the 
server is required to sign the response.

(Section 4)

3379 Requirement #17. The DPV server MAY require client authentication, 
therefore, the DPV request MUST be able to be authenticated. (4.1 Basic 
Protocol)

SCVP Draft 22:

�There are two forms of SCVP request: unprotected and protected.  A 
protected request is used to authenticate the client to the server or to 
provide anonymous client integrity over the request-response pair.  The 
protection is provided by a digital signature or message authentication 
code (MAC).  In the later case, the MAC key is derived using a key 
agreement algorithm, such as Diffie-Hellman.  If the client's public key is 
contained in a certificate, then it may be used to authenticate the 
client.  More commonly, the client's key agreement public key will be 
ephemeral, supporting anonymous client integrity.

A server MAY require all requests to be protected, and a server MAY discard 
all unprotected requests.  Alternatively, a server MAY choose to process 
unprotected requests.�

Section 3.

3379 Requirement #18. When the DPV request is authenticated, the client 
SHOULD be able to include a client identifier in the request for the DPV 
server to copy into the response.  Mechanisms for matching this identifier 
with the authenticated identity depends on local DPV server conditions 
and/or the validation policy.  The DPV server MAY choose to blindly copy 
the identifier, omit the identifier, or return an error response. (4.1 
Basic Protocol)

SCVP Draft 22:

�The optional requestorName item is used by the client to include an 
identifier in the request.  The client MAY include this information for the 
DPV server to copy into the response.

Conforming SCVP clients MAY support specification of this item in 
requests.  SCVP servers MUST be able to process requests that include this 
item.�

Section 3.5

�The optional requestorName item is used by the server to return one or 
more identities associated with the client in the response.

The SCVP server MAY choose to include any or all of the following:

      (1) the identity asserted by the client in the requestorName item of 
the request,
      (2) an authenticated identity for the client from a certificate or 
other credential used to authenticate the request, or
      (3) a client identifier from an out-of-band mechanism.

Alternatively, the SCVP server MAY omit this item.�

(Section 4.8)

3379 Requirement #19. Protocols designed to satisfy these requirements MAY 
include optional fields and/or extensions to support relaying, re-direction 
or multicasting.  [�]  If the protocol supports such features, the protocol 
MUST include provisions for DPV clients and DPV servers that do not support 
such features, allowing them to conform to the basic set of requirements. 
(4.2. Relaying, Re-direction and Multicasting)

SCVP Draft 22:

Servers that do not support redirection or relay are not required to 
process the requestorRef item or the responderName item.  The former is 
used for loop control, and is irrelevant for a server that does not itself 
relay requests.  The latter item identifies the intended signer, but 
servers that do not re-direct and sign under a single identity are not 
required to process this field.

As a general rule, redirection and relay are transparent to the 
client.  Clients are aware of redirection or relay only if they (1) wish to 
prompt redirection (through the responderName) or (2) request SCVP 
responses in the wantbacks.

(sections 3.2.3, 3.3, 3.6, 7)

3379 Requirement #20. When a server supports a relay mechanism, a mechanism 
to detect loops or repetition MUST be provided. (4.2. Relaying, 
Re-direction and Multicasting)

SCVP Draft 22:

�When an SCVP server relays a request, the request MUST include the 
requestorRef item.  If the request to be relayed already contains a 
requestorRef item, then the server-generated request MUST contain a 
requestorRef item constructed from this value followed by a GeneralName 
that contains an identifier of the SCVP server.  If the request to be 
relayed does not contain a requestorRef item, then the server-generated 
request MUST contain a requestorRef item that includes a GeneralName that 
contains an identifier of the SCVP server.

When an SVCP server receives a request that contains a requestorRef item, 
the server MUST check the sequence of names in the requestorRef item for 
its own identifier.  If the server discovers its own identifier in the 
requestor item, it MUST respond with an error, setting the cvResponseStatus 
to 40.�

(Section 7)

3379 Requirement #21. When a protocol provides the capability for a DPV 
server to redirect a request to another DPV server (that is, the protocol 
chooses to provide a referral mechanism), a mechanism to provide 
information to be used for the re-direction SHOULD be supported. If such 
re-direction information is sent back to clients, then the protocol MUST 
allow conforming clients to ignore it. (4.2. Relaying, Re-direction and 
Multicasting)

SCVP Draft 22:
The client can manage redirection by including the responderName item.  The 
optional responderName item is used by the client to indicate the identity 
of the SCVP server that the client expects to sign the SCVP response if the 
response is digitally signed.  If the server that receives this request 
behaves as a proxy, it can use this field to determine where to direct the 
request.  The success of the redirection can be established by verifying 
the signature on the response.  The processing server returns its response 
to the proxy, which passes the SCVP response to the client.

(Sections 3.6 and 7)

3379 Requirement #22. Optional parameters in the protocol request and/or 
response MAY be provide support for relaying, re-direction or 
multicasting.  DPV clients that ignore any such optional parameters MUST be 
able to use the DPV service.  DPV servers that ignore any such optional 
parameters MUST still be able to offer the DPV service, although they might 
not be able to overcome the limitations imposed by the network 
topology.  In this way, protocol implementers do not need to understand the 
syntax or semantics of any such optional parameters. (4.2. Relaying, 
Re-direction and Multicasting)

SCVP Draft 22:

If an SCVP server returns a response that reflects the results of relay or 
redirection, this will be transparent to the client unless the client 
requested SCVP responses in the wantbacks.

- id-swb-relayed-responses: Any SCVP responses received by the server that 
were used to generate the response to this query.

In this case, any SCVP responses used by the server will be included in the 
response in replyWantBacks:

�The octet string value for relayed responses, { id-swb 13 }, contains an 
ASN.1 type SCVPResponses, as defined below.  If the SCVP server used 
information obtained from other SCVP servers when generating this response, 
then SCVPResponses MUST include each of the SCVP responses received from 
those servers.  If the SCVP server did not use information obtained from 
other SCVP servers when generating the response, then SCVPResponses MUST be 
an empty sequence.

(Sections 3.2.3, 4.9.5)

�   - id-swb-pkc-revocation-info: Proof of revocation status for each 
certificate in the certification path;�
Section 3.2.3

3379 Requirement #24. If the DPD server does not support the client 
requested path discovery policy, the DPD server MUST return an error. (5. 
Delegated Path Discovery Protocol)

SCVP Draft 22:

�If the server is unable to perform validations using the required 
validation policy or the request contains an unsupported option, then the 
server MUST return an error response.�

(Section 4)

Date: Thu, 26 Jan 2006 11:08:44 -0500
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: 3379 Compliance Matrix: SCVP-22 (1 of 3)
Cc: [email-masked]
Sender: [email-masked]

[RFC 3379 requirements 1 through 12]

3379 Requirement #1. If the DPV server does not support the client 
requested validation policy, then the DPV server MUST return an error. 
(4.1. Basic Protocol)

SCVP Draft 22:

DPV responses include the responseStatus item.  If the client asserts the 
OID for an unsupported validation policy, the SCVP server returns an error 
response and specifies the statusCode unrecognizedValPol.

SCVP draft -21 specifies that unrecognizedValPol has the meaning �The 
request contained an unrecognized validation policy reference.� (section 4.4)

3379 Requirement #2. If the DPV request does not specify a validation 
policy, the server response MUST indicate the validation policy that was 
used. (4.1. Basic Protocol)

SCVP Draft 22:

All DPV requests include the validationPolicy item.  The validationPolicy 
item is itself a sequence with a single mandatory item, the 
validationPolRef item. (section 3.2.4)

The SCVP client either specifies a particular validation policy or the 
server�s default policy as an object identifier in the validationPolRef 
item.  (section 3.2.4.1)  The parameters associated with this policy may be 
modified through the use of optional items in the validationPolicy. 
(sections 3.2.4.1 through 3.2.4.9)

All DPV success responses include respValidationPolicy item (section 4.5), 
which indicate the validation policy that was used:

�The respValidationPolicy item contains either a reference to the full 
validation policy or the full policy by value used by the server to 
validate the request.�

3379 Requirement #3. The protocol MUST allow the client to include these 
policy dependent parameters in the DPV request; however, it is expected 
that most clients will simply reference a validation policy for a given 
application or accept the DPV server's default validation  policy. (4.1. 
Basic Protocol)

SCVP Draft 22:

All DPV requests include the validationPolicy item.  The validationPolicy 
item is itself a sequence with a single mandatory item, the 
validationPolRef item. (section 3.2.4)

The SCVP client either specifies a particular validation policy or the 
server�s default policy as an object identifier in the validationPolRef 
item.  (section 3.2.4.1)  The parameters associated with this policy may be 
modified through the use of optional items in the validationPolicy. 
(sections 3.2.4.1 through 3.2.4.9)

3379 Requirement #4. The DPV server MUST obtain revocation status 
information for the validation time in the client request. (4.1. Basic 
Protocol)

SCVP Draft 22:

An SCVP client specifies the validation time  by including the optional 
validationTime item (section 3.2.7)

�The optional validationTime item, if present, tells the date and time 
relative to which the SCVP client wants the server to perform the 
checks.  If the validationTime is not present, the server MUST perform the 
validation using the date and time at which the server processes the request.�

3379 Requirement #5. If the revocation status information for the requested 
validation time is unavailable, then the DPV server MUST return a status 
indicating that the certificate is invalid. Additional information about 
the reason for invalidity MAY also be provided. (4.1 Basic Protocol)

SCVP Draft 22:

The DPV server returns this information in the replyStatus item, which 
gives status information to the client about the request for the specific 
certificate.

If the revocation status information for the requested validation time is 
unavailable, the replyStatus will be 0 or 7:

�3  Failure: historical data for the requested validity time is notavailable.
    �.

7  Failure: the constructed certification path is not valid with respect to 
the validation policy, but a query at a later time may be successful.
    �

    Code 7 is used to tell the client that a valid certification path was 
found with the exception that a certificate in the path is on hold, current 
revocation information is unavailable, or the validation time precedes the 
notBefore time in one or more certificates in the path.�

(Section 4.9.2)

3379 Requirement #6. The certificate to be validated MUST either be 
directly provided in the request or unambiguously referenced, such as the 
CA distinguished name, certificate serial number, and the hash of the 
certificate, like ESSCertID as defined in [ESS] or OtherSigningCertificate 
as defined in [ES-F]. (4.1 Basic Protocol)

SCVP Draft 22:

The requestor specifies the list of certificates to be  validated in the 
sequence CertReferences.  Certificate references are performed by inclusion 
of the certificate itself or are specified using the CertID structure, 
which is based on the ESSCertID. The CertID structure includes the hash of 
the certificate and the issuer and serial number.  (section 3.2.1)

3379 Requirement #7. The DPV client MUST be able to provide to the 
validation server, associated with each certificate to be validated, useful 
certificates, as well as useful revocation information. (4.1 Basic Protocol)

SCVP Draft 22:

The DPV client can include potentially useful certificates in the request 
in the optional intermediateCerts item (section 3.2.8):

�The optional intermediateCerts item may help the SCVP server create valid 
certification paths.  The intermediateCerts item, when present, provides 
certificates that the server MAY use when forming a certification path.�

The DPV client can include potentially useful revocation information in the 
request in the optional revInfos item (section 3.2.9):

�The optional revInfos item specifies revocation information such as CRLs, 
delta CRLs [PKIX-1], and OCSP responses [OCSP] that the SCVP server MAY use 
when validating certification paths.  The purpose of the revInfos item is 
to provide revocation information to which the server might not otherwise 
have access, such as an OCSP response that the client received along with 
the certificate.�

3379 Requirement #8. The DPV server MUST have the certificate to be 
validated.  When the certificate is not provided in the request, the server 
MUST obtain the certificate and then verify that the certificate is indeed 
the one being unambiguous referenced by the client. (4.1 Basic Protocol)

SCVP Draft 22:

The DPV client must either explicitly provide the certificate to be 
validated to the DPV server or reference the certificate by its hash value 
in the queriedCerts item.

(Section 3.2.1)

The DPV server returns this information in the replyStatus item, which 
gives status information to the client about the request for the specific 
certificate.

If the certificate is not included in the request (i.e., the certificate is 
referenced by hash value), and the server is unable to obtain the 
certificate, the replyStatus will be 4:

�4  Failure: the server could not locate the reference certificate or the 
referenced certificate did not match the hash value provided.�

(Section 4.9.2)

3379 Requirement #9. The DPV server MUST include either the certificate or 
an unambiguous reference to the certificate (in case of a CA key 
compromise) in the DPV response. (4.1 Basic Protocol)

SCVP Draft 22:

The DPV server includes a certReply in the replyObjects in the response for 
each certificate that was validated.  The certReply is a sequence that 
includes the mandatory cert item (section 4.9.1)

�The cert item contains either the certificate or a reference to the 
certificate about which the client is requesting information.�

The CertID structure is used when the server specifies the certificate by 
reference.

3379 Requirement #10. The DPV response MUST indicate one of the following 
status alternatives:
1.      the certificate is valid according to the validation policy.
2.      the certificate is not valid according to the validation policy.
3.      the validity of the certificate is unknown according to the 
validation policy.
4.      the validity could not be determined due to an error.
(source for 10: 4.1 Basic Protocol)

SCVP Draft 22:

If the certificate is valid according to the validation policy, the 
replyStatus will be 0 or 8:

�0  Success: all checks were performed successfully.�

�8  Failure: all checks were performed successfully, however one or more of 
the wantBacks could not be satisfied.�

If the certificate is not valid according to the validation policy, the 
replyStatus will be 6 or 7:

�6  Failure: the constructed certification path is not valid with respect 
to the validation policy.
7  Failure: the constructed certification path is not valid with respect to 
the validation policy, but a query at a later time may be successful.�

If the validity of the certificate is unknown according to the validation 
policy, the replyStatus will be 3 or 5:

�3  Failure: historical data for the requested validity time is not available.
    �.
5       Failure: no certification path could be constructed.�

If the validity could not be determined due to an error, the replyStatus 
will be 1, 2, or 4:

�  1  Failure: the public key certificate was malformed.
     2  Failure: the attribute certificate was malformed.
   �.
     4  Failure: the server could not locate the reference certificate or 
the referenced certificate did not match the hash value provided.

(Section 4.9.2)

3379 Requirement #11. When the certificate is not valid according to the 
validation policy, then the reason MUST also be indicated.  Invalidity 
reasons include:
1.      the DPV server cannot determine the validity of the certificate 
because a certification path cannot be constructed.
2.      the DPV server successfully constructed a certification path, but 
it was not valid according to the validation algorithm in [PKIX-1].
3.      the certificate is not valid at this time.  If another request 
could be made later on, the certificate could possibly be determined as 
valid.  This condition may occur before a certificate validity period has 
begun or while a certificate is suspended
(Source for 11: 4.1 Basic Protocol)

SCVP Draft 22:

These reasons correspond to replyStatus codes 5, 6, and 7 respectively.

5  Failure: no certification path could be constructed.
6  Failure: the constructed certification path is not valid with respect to 
the validation policy.
7  Failure: the constructed certification path is not valid with respect to 
the validation policy, but a query at a later time may be successful.
(Section 4.9.2)

Additional information may be provided by the validation Errors field.

�The validationErrors item SHOULD only be included when the replyStatus is 
3, 5, 6, 7, or 8.  SCVP servers are not required to specify all of the 
reasons that validation failed. SCVP clients MUST NOT assume that the OIDs 
included in validationErrors represent all of the validation errors for the 
certification path.�
Section 4.9.6

3379 Requirement #12. The protocol MUST prevent replay attacks, and the 
replay prevention mechanism employed by the protocol MUST NOT rely on 
synchronized clocks. (4.1 Basic Protocol)

SCVP Draft 22:

SCVP includes a nonce mechanism to prevent replay attacks:

The requester may include a nonce in the request item requestNonce; the 
server returns this nonce in the response item respNonce. (section 3.4)

Date: Thu, 26 Jan 2006 11:06:57 -0500
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: RFC 3379 Compliance Matrix: SCVP draft 22 (intro)
Cc: [email-masked]
Sender: [email-masked]

Thanks,

Tim Polk

------------------ Known Open Issues ---------------------

SCVP Draft 22:

Proposed Resolution:

SCVP Draft 22:

(Section 4.9.2)

Date: Wed, 25 Jan 2006 15:06:20 -0500
To: [email-masked]
From: Shu-jen Chang <[email-masked]>
Subject: The Second Cryptographic Hash Workshop Call for Participation
Sender: [email-masked]

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

--=====================_17399187==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

The Second Cryptographic Hash Workshop
Santa Barbara, CA
August 24-25, 2006 (Starting at 1PM, August 24)
Submission deadline: May 12, 2006 (Workshop without proceedings)

As a follow-up to the first Cryptographic Hash Workshop held on Oct. 
31-Nov. 1, 2005, NIST plans to host a series of public workshops to focus 
on hash function research.  The next workshop will be held on August 24-25, 
2006, in conjunction with Crypto 2006, at UCSB, Santa Barbara. Attached is 
the Call for Participation for the Second Cryptographic Hash Workshop. 
Details about the workshop will be available at the following web site 
shortly: http://www.nist.gov/hash-function

Shu-jen Chang
Computer Security Division
NIST

--=====================_17399187==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font face="Courier New, Courier">The Second Cryptographic Hash
Workshop<br>
Santa Barbara, CA<br>
August 24-25, 2006 (Starting at 1PM, August 24)<br>
<b>Submission deadline: May 12, 2006 (Workshop without
proceedings)<br><br>
</b>As a follow-up to the first Cryptographic Hash Workshop held on Oct.
31-Nov. 1, 2005, NIST plans to host a series of public workshops to focus
on hash function research.&nbsp; The next workshop will be held on August
24-25, 2006, in conjunction with Crypto 2006, at UCSB, Santa Barbara.
Attached is the Call for Participation for the Second Cryptographic Hash
Workshop. Details about the workshop will be available at the following
web site shortly:
</font><a href="http://www.nist.gov/hash-function" eudora="autourl"><font face="Courier New, Courier" color="#0000FF"><u>http://www.nist.gov/hash-function</a><br><br>
</u></font><font face="Courier New, Courier">Shu-jen Chang<br>
Computer Security Division<br>
NIST<br><br>
</font></html>

--=====================_17399187==.ALT--

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

--=====================_17399171==_--

From: "Triple Crown Stocks" <[email-masked]>
To: <[email-masked]>
Subject: TripleCrownStocks.com features Water Technology Stock
Date: Wed, 25 Jan 2006 08:53:46 -0800

Date: Tue, 24 Jan 2006 09:03:31 +0100
From: Peter Rybar <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Dave Cooper, 13-Jan-06
Sender: [email-masked]

Hello,

I am very pleased to see your document which supersedes obsolete RFC 3280.

I compared the draft with the old RFC 3280 and I identified there 
several useful requirements that are similar to requirements published 
in documents on our web:
http://www.nbusr.sk/NBU_SEP/en_9.php
http://www.nbusr.sk/NBU_SEP/en_10.php
http://www.nbusr.sk/NBU_SEP/en_11.php
http://www.nbusr.sk/NBU_SEP/11_2.php  - finalCertCrl.zip

Our intend was to prepare easy readable documents containing simply 
understandable description of some standards and the best practices.
The documents can be helpful for SW developer, auditors or users to get 
a better view in a short time of the usage X.509 certificates in 
qualified electronic signatures.

Let me present some additional ideas which I considered to be useful in 
your draft.

Under the mandatory requirements:

If CRL1 (OCSP1) is issued then it is not possible to issue such CRL2 
(OCSP2) which would revoke a certificate before issuing time of CRL1 
(OCSP1) in which certificate has not been revoked yet.

It is useful in the verification process, because verification algorithm 
need found only one CRL (OCSP) issued after required time and it does 
not need to wait the whole caution (grace) period.

Under the optional requirements:

I recommend that certificate in the CRL (OCSP) can not be found in 
revocation reason certificateHold or removeFromCRL, thus its validity 
can not be stopped for certain period.
It eases verifying algorithms and enables to employ only final complete 
CRL and avoid SW application to collect all issued CRL to check if some 
certificate maybe has been in status certificateHold and removeFromCRL.

These CA practices are currently common in some countries as it was 
discussed with some participant at ETSI meeting in Sophia Antipolis in 
January and are useful in long term validation.

Best regards

Peter Rybar
National Security Authority of the Slovak Republic

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-22.txt 
Date: Mon, 23 Jan 2006 18:50: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		: Standard Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-22.txt
	Pages		: 82
	Date		: 2006-1-23
	
SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server.  The path construction or
   validation (e.g. making sure that none of the certificates in the
   path are revoked) is performed according to a validation policy,
   which contains one or more trust anchors.  It allows simplification
   of client implementations and use of a set of predefined validation
   policies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-22.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-scvp-22.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-scvp-22.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-scvp-22.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 23 Jan 2006 16:42:26 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Last Call on CMC
Sender: [email-masked]

I am initiating a two-week last call period for the most recent version of CMC:

draft-ietf-pkix-cmc-trans-04.txt

Please direct any comments to the list before February 6, 2006.

Thanks,
Steve

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST R  34.11-94 algorithms with the Internet X.509 Public Key Infrastructure  Certificate and CRL Profile.' to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Fri, 20 Jan 2006 17:19:50 -0500
Sender: [email-masked]

The IESG has received a request from the Public-Key Infrastructure (X.509) WG 
to consider the following document:

- 'Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 algorithms 
   with the Internet X.509 Public Key Infrastructure Certificate and CRL 
   Profile. '
   <draft-ietf-pkix-gost-cppk-05.txt> as a Proposed Standard

This document contains a "downref."  That is, there is a normative dependency
in this document on an Informational RFC.  This is not uncommon when the
Informational RFC contains details of cryptographic algorithms, as is the
case here.  This document contains a normative reference to:

- Popov, V., Kurepkin, I., and S. Leontiev, "Additional
  Cryptographic Algorithms for Use with GOST 28147-89,
  GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
  Algorithms", RFC 4357, January 2006.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-02-03.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-05.txt

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-srvsan-01.txt 
Date: Fri, 20 Jan 2006 15:50: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		: Internet X.509 Public Key Infrastructure 
                          Subject Alternative Name for expression of service name
	Author(s)	: S. Santesson
	Filename	: draft-ietf-pkix-srvsan-01.txt
	Pages		: 9
	Date		: 2006-1-20
	
This document defines a new name form for inclusion in the otherName
   filed of an X.509 Subject Alternative Name extension which allows a
   certificate subject to be associated with the service name and domain
   name components of a DNS Service Resource Record.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-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-srvsan-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-srvsan-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-srvsan-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-srvsan-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: RE: The new High Assurance SSL Certificates
Date: Fri, 20 Jan 2006 06:27:43 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Jeffrey I. Schiller" <[email-masked]>, "Aisenberg, Michael" <[email-masked]>
Cc: "Joel S. Kazin" <[email-masked]>, "Anders Rundgren" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Jeffrey I. Schiller

> So If I were to incorporate AO1 Computers as my legitimate 
> business name and obtain the domain name AO1.COM (this is 
> hypothetical, I'm sure its not available :-) ), A High 
> Assurance CA would deny me a certificate because it looks too 
> much like an AOL certificate?
> 
> Is that really right?

No, there are some domains that you SHOULD be denied, AOL.com as an
international domain with the 0 from the Martian code set circle of
harmony. &ct.

However it is impossible to enumerate all the possible rules in advance
and EVEN WITHOUT international domain names there is a major business
detecting lookalike and cousin domains just in the ASCII character set.
Phishing gangs register names like security-bizybank.com.

> How do you decide which domains are "famous" enough to 
> deserve this protection? What constitutes a domain name that 
> looks too much like a famous domain?

It's a permissions based security approach - enumerate all the possible
failures in advance and try to stop them. Not a practical or effective
strategy in an open system with a billion users.

> On the other hand. If I obtain a high assurance certificate 
> and then use it to confuse consumers into believing my site 
> is AOL (it looks like AOL's, it abuses their trademarked 
> logos etc.) I am clearly acting in bad faith. If a High 
> Assurance CA had previously issued me a certificate, it would 
> be justified in revoking it. This is why I believe revocation 
> is a critical technology to making progress.

Revocation is critical. But revocation is not just a technical process,
there has to be a process to make the decision to revoke. That will
inevitably have to be human driven and is going to take some time, hours
rather than minutes. All owners of major trademarks like AOL will have a
trademark protection company monitoring its domain, the CA does not need
to be the only party detecting abuse.

Revocation is one aspect of an accountability scheme but where we need
to do more than deny the attempted fraudster their entry fee. We need to
hold someone accountable for the attempt, either the fraudster
themselves or the agent who set up their false corporate identity.

> It is easier to detect bad actors (and deal with them) then 
> assume someone *might* be a bad actor ahead of time and deny 
> them access to commerce by denying them a high assurance 
> certificate up front.

The real issue here is scope. The origins of the high assurance project
was with the people who still think that the function of a CA is to
establish identity, it isn't. The job of the CA in this environment is
to make it safe for the consumer by ensuring that the certificate
subject is accountable.

I would prefer to be discussing High Accountability SSL Certificates.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: RE: The new High Assurance SSL Certificates
Date: Sat, 21 Jan 2006 02:29:31 +1300
Sender: [email-masked]

"Marc Poulaud" <[email-masked]> writes:

>In the UK, if you try to incorporate a company with a similar name to
>another, your application will be turned down citing the similarity to avoid
>a AO1 type of problem.

You wouldn't need to do that, just get a "trading-as" certificate (a DBA cert
in the US) for (say) aolsecure.co.uk and get a cert for that (I'm using that
particular form because of existing precdent set by the visa-secure.com SSL'd
phishing site, but you can insert your name variant of choice).  Or create a
self-signed cert with all the high-assurance decorations in it.  Either is
fine for phishing purposes.

Peter.

From: "Marc Poulaud" <[email-masked]>
To: <[email-masked]>
Subject: RE: The new High Assurance SSL Certificates
Date: Fri, 20 Jan 2006 10:29:58 -0000
Sender: [email-masked]

My 2 euro cents...

Depends on what the perceived role of the HACA is and what expectation users
might have. Let's face it, users will probably ignore any
guidance/disclaimers/warnings/T&Cs.

In the UK, if you try to incorporate a company with a similar name to
another, your application will be turned down citing the similarity to avoid
a AO1 type of problem.

IMHO, unless there was this type of control by the HACA, acceptance by users
and technology to enforce this on the user PC, it would seem unlikely to get
any real traction.

Marc.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jeffrey I. Schiller
Sent: 20 January 2006 05:15
To: Aisenberg, Michael
Cc: Joel S. Kazin; Anders Rundgren; [email-masked]
Subject: Re: The new High Assurance SSL Certificates

So If I were to incorporate AO1 Computers as my legitimate business name
and obtain the domain name AO1.COM (this is hypothetical, I'm sure its
not available :-) ), A High Assurance CA would deny me a certificate
because it looks too much like an AOL certificate?

Is that really right?

How do you decide which domains are "famous" enough to deserve this
protection? What constitutes a domain name that looks too much like a
famous domain?

On the other hand. If I obtain a high assurance certificate and then use
it to confuse consumers into believing my site is AOL (it looks like
AOL's, it abuses their trademarked logos etc.) I am clearly acting in
bad faith. If a High Assurance CA had previously issued me a
certificate, it would be justified in revoking it. This is why I believe
revocation is a critical technology to making progress.

It is easier to detect bad actors (and deal with them) then assume
someone *might* be a bad actor ahead of time and deny them access to
commerce by denying them a high assurance certificate up front.

			-Jeff
- --
============================================================================
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[email-masked]
============================================================================

Date: Fri, 20 Jan 2006 00:14:42 -0500
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
To: "Aisenberg, Michael" <[email-masked]>
CC: "Joel S. Kazin" <[email-masked]>, Anders Rundgren <[email-masked]>, [email-masked]
Subject: Re: The new High Assurance SSL Certificates
OpenPGP: id=F414952B
Sender: [email-masked]

So If I were to incorporate AO1 Computers as my legitimate business name
and obtain the domain name AO1.COM (this is hypothetical, I'm sure its
not available :-) ), A High Assurance CA would deny me a certificate
because it looks too much like an AOL certificate?

Is that really right?

How do you decide which domains are "famous" enough to deserve this
protection? What constitutes a domain name that looks too much like a
famous domain?

On the other hand. If I obtain a high assurance certificate and then use
it to confuse consumers into believing my site is AOL (it looks like
AOL's, it abuses their trademarked logos etc.) I am clearly acting in
bad faith. If a High Assurance CA had previously issued me a
certificate, it would be justified in revoking it. This is why I believe
revocation is a critical technology to making progress.

It is easier to detect bad actors (and deal with them) then assume
someone *might* be a bad actor ahead of time and deny them access to
commerce by denying them a high assurance certificate up front.

			-Jeff
- --
=============================================================================
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[email-masked]
============================================================================

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: AW: The new High Assurance SSL Certificates
Date: Thu, 19 Jan 2006 15:53:48 +1300
Sender: [email-masked]

[email-masked] writes:

>Ooops... the level of assurance depends on the amount of money I am willing
>to pay for?

Sure.  You know that someone who pays $495 for a cert is more serious about it
than someone who pays $9.95, in the same way that someone who buys a $1995
stereo is more serious than someone who buys a $199 one.

(Well, either that or they don't know that you can get $9.95 certs that behave
 identically to $495 certs.  I got private mail from someone else saying that
 a rule of thumb is that the more you pay, the less you know.  I guess this
 holds for hifi gear as it does for certs).

So we don't really need "high-assurnace policy OIDs" (or whatever), all we
need is an extension indicating how much the owner paid for it, and the
problem is solved.

Peter.

Date: Wed, 18 Jan 2006 18:20:02 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-02.txt
Sender: [email-masked]

[email-masked] wrote:

> 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-02.txt
> Pages :       140
> Date :         2006-1-13
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-02.txt

I have posted two "diff" files on the NIST Web site: one showing the 
differences between 3280bis-01 and 3280bis-02 and one showing the 
differences between RFC 3280 and 3280bis-02.  They are available at:

http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-01todraft3280bis-02_diff.html

and

http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-02_diff.html

While I would encourage people to review the "diff" files to see what 
changes have been made, here is a list summarizing some of the changes 
that were made between draft -01 and draft -02:

1) Text has been added to section 4.2.1.6 (Subject Alternative Name) to 
make it clear that a certificate must either include a non-empty subject 
field or a subjectAltName extension that is marked critical.

2) References to any RFCs that have been updated were changed to refer 
to the current RFC.

3) A new section has been added (section 5.2.7) to specify the use of 
the authorityInfoAccess extension in a CRL (i.e., 3280bis now 
incorporates RFC 4325).

4) The references section has been divided into Normative and 
Informative sections.

5) Appendix D, which described the privateKeyUsagePeriod extension, has 
been removed.

Dave

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-gost-cppk-05.txt 
Date: Wed, 18 Jan 2006 15:50: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		: Using the GOST R 34.10-94, GOST R 34.10-2001 
                          and GOST R 34.11-94 algorithms with the 
                          Internet X.509 Public Key Infrastructure 
                          Certificate and CRL Profile.
	Author(s)	: S. Leontiev, et al.
	Filename	: draft-ietf-pkix-gost-cppk-05.txt
	Pages		: 19
	Date		: 2006-1-18
	
This document supplements RFC 3279. It describes encoding formats,
   identifiers and parameter formats for the algorithms GOST R 34.10-94,
   GOST R 34.10-2001 and GOST R 34.11-94 for use in Internet X.509
   Public Key Infrastructure (PKI).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-05.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-gost-cppk-05.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-gost-cppk-05.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-lightweight-ocsp-profile-03.txt 
Date: Wed, 18 Jan 2006 15:50: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		: Lightweight OCSP Profile for High Volume Environments
	Author(s)	: R. Hurst, A. Deacon
	Filename	: draft-ietf-pkix-lightweight-ocsp-profile-03.txt
	Pages		: 19
	Date		: 2006-1-18
	
This specification defines a profile of the Online Certificate 
   Status Protocol (OCSP) that addresses the scalability issues 
   inherent when using OCSP in large scale (high volume) PKI 
   environments and/or PKI environments that require a lightweight 
   solution to minimize bandwidth and client side processing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-03.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-lightweight-ocsp-profile-03.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-lightweight-ocsp-profile-03.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-lightweight-ocsp-profile-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-lightweight-ocsp-profile-03.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: RE: The new High Assurance SSL Certificates
Date: Wed, 18 Jan 2006 08:22:37 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Aisenberg, Michael" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of 
> [email-masked]

> Ooops... the level of assurance depends on the amount of 
> money I am willing to pay for?

The level of authentication is certainly constrained by cost. It is hard
to see what authentication can be done at the bargain basement rates
some charge. Checking the credit card clears perhaps?

Providing effective revocation mechanisms such as OCSP also costs money.

The 'seriousness' effect Peter refers to might be significant in some
contexts, certainly if there is an effective revocation mechanism that
closes down a certificate used fraudulently in days it would be harder
for a criminal to make a profit on an expensive cert than a cheapie.
That is not the mechanism intended here.

Content-class: urn:content-classes:message
Subject: RE: AW: The new High Assurance SSL Certificates
Date: Wed, 18 Jan 2006 09:32:31 -0500
From: "Aisenberg, Michael" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61C3C.03E6A917
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

No. It depends on the amount of info the subscriber wishes to provide to =
rhe CA.

 -----Original Message-----
From: 	[email-masked] =
[mailto:[email-masked]]
Sent:	Wed Jan 18 07:00:42 2006
To:	[email-masked]; [email-masked]; Aisenberg, Michael; =
[email-masked]
Subject:	AW: The new High Assurance SSL Certificates

Ooops... the level of assurance depends on the amount of money I am =
willing
to pay for?

Best regards

Thomas =20

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von=20
> [email-masked]
> Gesendet: Mittwoch, 18. Januar 2006 10:23
> An: [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: The new High Assurance SSL Certificates
>=20
>=20
> Paul Hoffman <[email-masked]> writes:
>=20
> >What is the difference between VeriSign high assurance and=20
> VeriSign low=20
> >assurance certificates? If a developer can't answer the=20
> question, then=20
> >the app doesn't need to differentiate.
>=20
> With the HA certs you have a high level of assurance that the=20
> cert owner paid more for them, thus indicating that they were=20
> more serious about obtaining a cert than a LA cert owner.
>=20
> Peter.
>=20
>=20

------_=_NextPart_001_01C61C3C.03E6A917
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>RE: AW: The new High Assurance SSL Certificates</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>No. It depends on the amount of info the subscriber =
wishes to provide to rhe CA.<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:thomas.beckmann@ato=
sorigin.com</A>]<BR>
Sent:&nbsp;&nbsp; Wed Jan 18 07:00:42 2006<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]; =
[email-masked]; Aisenberg, Michael; [email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AW: The new High =
Assurance SSL Certificates<BR>
<BR>
<BR>
Ooops... the level of assurance depends on the amount of money I am =
willing<BR>
to pay for?<BR>
<BR>
Best regards<BR>
<BR>
Thomas&nbsp;<BR>
<BR>
&gt; -----Urspr=FCngliche Nachricht-----<BR>
&gt; Von: [email-masked]<BR>
&gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>] Im Auftrag von<BR>
&gt; [email-masked]<BR>
&gt; Gesendet: Mittwoch, 18. Januar 2006 10:23<BR>
&gt; An: [email-masked]; [email-masked]; =
[email-masked]<BR>
&gt; Betreff: Re: The new High Assurance SSL Certificates<BR>
&gt;<BR>
&gt;<BR>
&gt; Paul Hoffman &lt;[email-masked]&gt; writes:<BR>
&gt;<BR>
&gt; &gt;What is the difference between VeriSign high assurance and<BR>
&gt; VeriSign low<BR>
&gt; &gt;assurance certificates? If a developer can't answer the<BR>
&gt; question, then<BR>
&gt; &gt;the app doesn't need to differentiate.<BR>
&gt;<BR>
&gt; With the HA certs you have a high level of assurance that the<BR>
&gt; cert owner paid more for them, thus indicating that they were<BR>
&gt; more serious about obtaining a cert than a LA cert owner.<BR>
&gt;<BR>
&gt; Peter.<BR>
&gt;<BR>
&gt;<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C61C3C.03E6A917--

From: [email-masked]
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: AW: The new High Assurance SSL Certificates
Date: Wed, 18 Jan 2006 11:51:45 +0100
Sender: [email-masked]

Well,... okay, this seems clear... but... does my seriousity depend on the
amount of money?

> -----Urspr�ngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Beckmann, Thomas
> Gesendet: Mittwoch, 18. Januar 2006 11:42
> An: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Betreff: AW: The new High Assurance SSL Certificates
> 
> 
> Ooops... the level of assurance depends on the amount of 
> money I am willing to pay for?
> 
> Best regards
> 
> Thomas  
> 
> > -----Urspr�ngliche Nachricht-----
> > Von: [email-masked]
> > [mailto:[email-masked]] Im Auftrag von 
> > [email-masked]
> > Gesendet: Mittwoch, 18. Januar 2006 10:23
> > An: [email-masked]; [email-masked]; 
> [email-masked]
> > Betreff: Re: The new High Assurance SSL Certificates
> > 
> > 
> > Paul Hoffman <[email-masked]> writes:
> > 
> > >What is the difference between VeriSign high assurance and
> > VeriSign low
> > >assurance certificates? If a developer can't answer the
> > question, then
> > >the app doesn't need to differentiate.
> > 
> > With the HA certs you have a high level of assurance that the cert 
> > owner paid more for them, thus indicating that they were 
> more serious 
> > about obtaining a cert than a LA cert owner.
> > 
> > Peter.
> > 
> > 
> 
> 

From: [email-masked]
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: AW: The new High Assurance SSL Certificates
Date: Wed, 18 Jan 2006 11:42:22 +0100
Sender: [email-masked]

Ooops... the level of assurance depends on the amount of money I am willing
to pay for?

Best regards

Thomas  

> -----Urspr�ngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von 
> [email-masked]
> Gesendet: Mittwoch, 18. Januar 2006 10:23
> An: [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: The new High Assurance SSL Certificates
> 
> 
> Paul Hoffman <[email-masked]> writes:
> 
> >What is the difference between VeriSign high assurance and 
> VeriSign low 
> >assurance certificates? If a developer can't answer the 
> question, then 
> >the app doesn't need to differentiate.
> 
> With the HA certs you have a high level of assurance that the 
> cert owner paid more for them, thus indicating that they were 
> more serious about obtaining a cert than a LA cert owner.
> 
> Peter.
> 
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: The new High Assurance SSL Certificates
Date: Wed, 18 Jan 2006 22:23:08 +1300
Sender: [email-masked]

Paul Hoffman <[email-masked]> writes:

>What is the difference between VeriSign high assurance and VeriSign low
>assurance certificates? If a developer can't answer the question, then the
>app doesn't need to differentiate.

With the HA certs you have a high level of assurance that the cert owner paid
more for them, thus indicating that they were more serious about obtaining a
cert than a LA cert owner.

Peter.

Content-class: urn:content-classes:message
Subject: RE: The new High Assurance SSL Certificates
Date: Tue, 17 Jan 2006 16:43:58 -0500
From: "Kemp David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Displaying the CA logo is a helpful step, but is not sufficient.  CA
assurance levels need to be commoditized (to at least a binary level -
"UL Listed" or not), if only to solve the revocation problem.

There must be a way for a browser and a user to distinguish between
the large number of CAs in a trust list (for which the only
qualification is "we adhere to whatever claims, if any, we put
in our CPS"), and the smaller number of CAs that adhere to
industry consensus practices for HA organizational authentication.
How would that consensus be bootstrapped into existence? I don't
know, but I think a consortium like IMC or OATH would have a
better chance of gaining mindshare as the "Good Housekeeping"
of HA authentication than would any single CA operating alone.
There would have to be some general principles in the HA charter,
such as no CA could buy their way in by becoming a Platinum
level sponsor, and no CA could be excluded for reasons unrelated
to the assurance of their issuing practices, but beyond that
the listing criteria could be fairly informal ("we know HA
when we see it") and accountability-based ("two strikes and
you're out"), at least initially.

Technically, the HA could issue a list of approved root certificate
fingerprints signed along with the HA logo and the distribution
URL for the next list update.  Browsers could be modified to install
the HA authority signature key, download and validate the HA list,
and display the HA seal along with the SSL server logo whenever
the SSL cert can be validated back to a root on the HA fingerprint
list.  Would users benefit from or be confused by seeing three
logos (HA Seal, CA brand and SSL server)?  Who knows.

Is it better to invent a brand new structure (signed good-guy
list with logo) than to reuse existing structures (augment
the trust list with an HA root, HA issues CA certs and an ARL
for the previous roots)?  Probably, because otherwise there is
nothing to prevent a non-HA-listed CA from issuing a self-signed
cert with a logo identical or suspiciously close to the HA seal,
just as there is nothing to prevent a low assurance root from
claiming a high assurance CP OID.  Presumably users would have
an easier time managing 1 (or 2 or 3) HA approvers separately
from 150 root CAs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, January 17, 2006 10:41 AM
To: Anders Rundgren; [email-masked]
Subject: RE: The new High Assurance SSL Certificates

> 2. I may be wrong here, but is there actually anything that 
> prevents a low- assurance certificate issuer to include high 
> assurance policy identifiers?

I think that you identify the real problem here. The system today lacks
mechanisms to hold CAs accountable for untrustworthy certificate
practices.

The problem is made worse by the SSL user interface which gives only 1
bit of information and a pretty irrelevant one. All the padlock icon
actually means is 'this communication is encrypted'. Users are misled to
believe that it means 'this transaction is secure and I can trust that
the other party can be held accountable in case of default'.

The first problem can be solved using a self signed certificate. The
problem with the current situation is that all a CA needs to do to get
in the root store is to describe their issue practices and be audited.
It is entirely possible for a CA to essentially state that they do not
authenticate at all and still meet this criteria.

The high assurance CA project is one proposal to try to address the
problem. The question that has to be asked here is whether it is
sufficient to try to define a new bar. 

One area where it is certain that a higher bar is required is if
logotype certificates (Secure Internet Lettehead) are to be issued.
Logotypes are potentially a way to avoid the problem of domain name
attacks such cousin domain. They provide a means of providing the user
with an unambiguous proof of the subject identity but only if backed by
stringent authentication techniques that effectively prevent fraudulent
registrations.

The real key to solving this problem is to change the nature of the
business so that there is a positive incentive for all CAs to apply
stringent assurance practices. Holding the CA accountable by displaying
the ca logo as well as the subject logo creates a situation which is
effectively self-policing. The ca is required to put their own brand on
the line each time they issue a cert. Any CA that issues a bogus
certificate to the bank of england is going to be on the front page of
the new york times. 

Content-class: urn:content-classes:message
Subject: RE: The new High Assurance SSL Certificates
Date: Tue, 17 Jan 2006 07:41:19 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> 2. I may be wrong here, but is there actually anything that 
> prevents a low- assurance certificate issuer to include high 
> assurance policy identifiers?

I think that you identify the real problem here. The system today lacks
mechanisms to hold CAs accountable for untrustworthy certificate
practices.

The problem is made worse by the SSL user interface which gives only 1
bit of information and a pretty irrelevant one. All the padlock icon
actually means is 'this communication is encrypted'. Users are misled to
believe that it means 'this transaction is secure and I can trust that
the other party can be held accountable in case of default'.

The first problem can be solved using a self signed certificate. The
problem with the current situation is that all a CA needs to do to get
in the root store is to describe their issue practices and be audited.
It is entirely possible for a CA to essentially state that they do not
authenticate at all and still meet this criteria.

The high assurance CA project is one proposal to try to address the
problem. The question that has to be asked here is whether it is
sufficient to try to define a new bar. 

One area where it is certain that a higher bar is required is if
logotype certificates (Secure Internet Lettehead) are to be issued.
Logotypes are potentially a way to avoid the problem of domain name
attacks such cousin domain. They provide a means of providing the user
with an unambiguous proof of the subject identity but only if backed by
stringent authentication techniques that effectively prevent fraudulent
registrations.

The real key to solving this problem is to change the nature of the
business so that there is a positive incentive for all CAs to apply
stringent assurance practices. Holding the CA accountable by displaying
the ca logo as well as the subject logo creates a situation which is
effectively self-policing. The ca is required to put their own brand on
the line each time they issue a cert. Any CA that issues a bogus
certificate to the bank of england is going to be on the front page of
the new york times. 

From: "Kuhn, Sebastien" <[email-masked]>
To: Tom Gindin <[email-masked]>, Richard Levitte - VMS Whacker <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: pathLenConstraint
Date: Tue, 17 Jan 2006 14:13:43 +0100
Sender: [email-masked]

Thank you very much for your responses.
Best Regards,

Sebastien Kuhn.

-----Message d'origine-----
De : Tom Gindin [mailto:[email-masked]]
Envoy� : mardi 17 janvier 2006 04:29
� : Richard Levitte - VMS Whacker
Cc : [email-masked]; Kuhn, Sebastien
Objet : Re: pathLenConstraint

        If the verifier follows RFC 3280 6.1.4 steps L and M, 
pathLengthConstraint seems to have real effect in an intermediate 
certificate either only if it is less than the previous value of the 
length constraint minus one.  Step M suggests that pathLengthConstraint 
should be ignored if this is not the case.  The algorithm assumes that the 
length constraint is initialized to a non-negative integer, although it 
can be a large one.
        Sebastien's suggested setup is fine, of course.

                Tom Gindin

Richard Levitte - VMS Whacker <[email-masked]>
Sent by: [email-masked]
01/16/2006 08:36 AM
 
        To:     [email-masked]
        cc:     [email-masked]
        Subject:        Re: pathLenConstraint

In message 
<[email-masked]> on Fri, 
13 Jan 2006 16:24:49 +0100, "Kuhn, Sebastien" <[email-masked]> 
said:

sebastien.kuhn> Could you confirm that the attribute
sebastien.kuhn> "pathLenConstraint" (included in the extension
sebastien.kuhn> "BasicConstraints") can have no limit in a Root CA
sebastien.kuhn> certificate and a finite value in a CA certificate
sebastien.kuhn> subordinate to the Root CA ?

Yes, as far as I understand.  I can't really imagine why it shouldn't

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         [email-masked]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                 -- C.S. Lewis

Content-class: urn:content-classes:message
Subject: Re: The new High Assurance SSL Certificates
Date: Tue, 17 Jan 2006 07:59:27 -0500
From: "Aisenberg, Michael" <[email-masked]>
To: "Jeffrey I. Schiller" <[email-masked]>, "Joel S. Kazin" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Jeff
I believe you have described one of the core issues motivating browser =
publishers--combatting spam and other consumer abuses not presently =
remedied by some flavors of organizational SSL certs that require only =
minimum vetting of identity/legitimacy attributes of corporate/business =
subscribers.  The point is to deny the "AOL1" cert to anyone other than =
AOL to the extent this can be contributed to by a stronger Organization =
SSL cert.  It won't eliminate fraudsters getting organization certs, but =
it cuts it down.  Those of us in the CA community who already require =
more than an organization name and email address have already set a =
higher bar in practice.  The browsers are now proposing to serve =
consumers by differentiating.
 =20

 -----Original Message-----
From: 	Jeffrey I. Schiller [mailto:[email-masked]]
Sent:	Mon Jan 16 15:33:53 2006
To:	Joel S. Kazin
Cc:	Anders Rundgren; [email-masked]
Subject:	Re: The new High Assurance SSL Certificates

Joel S. Kazin wrote:
> As discussed at the October 2005 ABA ISC meeting, a HCA does not =
address
> the handling of a consumer's personal information.

Well, I wasn't at the meeting, so I cannot comment about what went on. I
can understand why it won't address how an organization handles personal
information. But it *should* address how a consumer can *know* they are
giving their information to whom they believe they giving their
information. Thus my example about differentiating AOL.COM from AO1.COM.

Bottom line: If this doesn't improve consumer confidence, then it is a
worthless exercise. My take on it is that private key protection is not
the problem we have. Phishing is what it is about and phishing doesn't
require stealing the private key of the legitimate site. It requires
fooling the consumer into thinking they are at the legitimate site when
in fact they are not. The goal should be to address (or solve) this
problem. I original message was to point out that this is more about
policy of certificate issuance then private key protection and that the
key piece of technology we need is really working revocation, something
we do not have today (at least in deployed technologies).

			-Jeff

P.S. What was the junk on the end of your message, looks like the dump
of some random Window's settings file!

- --
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[email-masked]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: The new High Assurance SSL Certificates</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Jeff<BR>
I believe you have described one of the core issues motivating browser =
publishers--combatting spam and other consumer abuses not presently =
remedied by some flavors of organizational SSL certs that require only =
minimum vetting of identity/legitimacy attributes of corporate/business =
subscribers.&nbsp; The point is to deny the &quot;AOL1&quot; cert to =
anyone other than AOL to the extent this can be contributed to by a =
stronger Organization SSL cert.&nbsp; It won't eliminate fraudsters =
getting organization certs, but it cuts it down.&nbsp; Those of us in =
the CA community who already require more than an organization name and =
email address have already set a higher bar in practice.&nbsp; The =
browsers are now proposing to serve consumers by differentiating.<BR>
&nbsp;<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Jeffrey I. Schiller [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent:&nbsp;&nbsp; Mon Jan 16 15:33:53 2006<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Joel S. Kazin<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; Anders Rundgren; [email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: The new High =
Assurance SSL Certificates<BR>
<BR>
<BR>
-----BEGIN PGP SIGNED MESSAGE-----<BR>
Hash: SHA1<BR>
<BR>
Joel S. Kazin wrote:<BR>
&gt; As discussed at the October 2005 ABA ISC meeting, a HCA does not =
address<BR>
&gt; the handling of a consumer's personal information.<BR>
<BR>
Well, I wasn't at the meeting, so I cannot comment about what went on. =
I<BR>
can understand why it won't address how an organization handles =
personal<BR>
information. But it *should* address how a consumer can *know* they =
are<BR>
giving their information to whom they believe they giving their<BR>
information. Thus my example about differentiating AOL.COM from =
AO1.COM.<BR>
<BR>
Bottom line: If this doesn't improve consumer confidence, then it is =
a<BR>
worthless exercise. My take on it is that private key protection is =
not<BR>
the problem we have. Phishing is what it is about and phishing =
doesn't<BR>
require stealing the private key of the legitimate site. It requires<BR>
fooling the consumer into thinking they are at the legitimate site =
when<BR>
in fact they are not. The goal should be to address (or solve) this<BR>
problem. I original message was to point out that this is more about<BR>
policy of certificate issuance then private key protection and that =
the<BR>
key piece of technology we need is really working revocation, =
something<BR>
we do not have today (at least in deployed technologies).<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -Jeff<BR>
<BR>
P.S. What was the junk on the end of your message, looks like the =
dump<BR>
of some random Window's settings file!<BR>
<BR>
- --<BR>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D<BR>
Jeffrey I. Schiller<BR>
MIT Network Manager<BR>
Information Services and Technology<BR>
Massachusetts Institute of Technology<BR>
77 Massachusetts Avenue&nbsp; Room W92-190<BR>
Cambridge, MA 02139-4307<BR>
617.253.0161 - Voice<BR>
[email-masked]<BR>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<BR>
-----BEGIN PGP SIGNATURE-----<BR>
Version: GnuPG v1.4.1 (GNU/Linux)<BR>
Comment: Using GnuPG with Thunderbird - <A =
HREF=3D"http://enigmail.mozdev.org">http://enigmail.mozdev.org</A><BR>
<BR>
iD8DBQFDy/NZ8CBzV/QUlSsRAsP8AJ4gAZkgdiCLgDBFR7gCbjk93gILOgCgsc6H<BR>
rkDibHfiPeMs1wBLfp+vEcY=3D<BR>
=3DxZxK<BR>
-----END PGP SIGNATURE-----<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C61B65.D9677BE3--

To: Richard Levitte - VMS Whacker <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: pathLenConstraint
From: Tom Gindin <[email-masked]>
Date: Mon, 16 Jan 2006 22:29:19 -0500
Sender: [email-masked]

        If the verifier follows RFC 3280 6.1.4 steps L and M, 
pathLengthConstraint seems to have real effect in an intermediate 
certificate either only if it is less than the previous value of the 
length constraint minus one.  Step M suggests that pathLengthConstraint 
should be ignored if this is not the case.  The algorithm assumes that the 
length constraint is initialized to a non-negative integer, although it 
can be a large one.
        Sebastien's suggested setup is fine, of course.

                Tom Gindin

Richard Levitte - VMS Whacker <[email-masked]>
Sent by: [email-masked]
01/16/2006 08:36 AM
 
        To:     [email-masked]
        cc:     [email-masked]
        Subject:        Re: pathLenConstraint

In message 
<[email-masked]> on Fri, 
13 Jan 2006 16:24:49 +0100, "Kuhn, Sebastien" <[email-masked]> 
said:

sebastien.kuhn> Could you confirm that the attribute
sebastien.kuhn> "pathLenConstraint" (included in the extension
sebastien.kuhn> "BasicConstraints") can have no limit in a Root CA
sebastien.kuhn> certificate and a finite value in a CA certificate
sebastien.kuhn> subordinate to the Root CA ?

Yes, as far as I understand.  I can't really imagine why it shouldn't

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         [email-masked]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                 -- C.S. Lewis

Content-class: urn:content-classes:message
Subject: RE: The new High Assurance SSL Certificates
Date: Mon, 16 Jan 2006 17:49:53 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, "Aisenberg, Michael" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Monday, January 16, 2006 2:58 PM
> To: Aisenberg, Michael; [email-masked]
> Subject: Re: The new High Assurance SSL Certificates
> 
> 
> At 11:01 AM -0500 1/16/06, Aisenberg, Michael wrote:
> >Another "process" ("labour") is the intra industry saga of reaching 
> >consensus on How and Where to do this (standards body, industry
> >assn.) and then doing it...Promptly.
> 
> I will repeat my earlier question, maybe a bit more pointed 
> at the VeriSign folks on the list:
> 
> What is the difference between VeriSign high assurance and 
> VeriSign low assurance certificates? If a developer can't 
> answer the question, then the app doesn't need to differentiate.

There are no VeriSign 'low assurance' certificates.

The basic principle is that all the information in the cert is assured,
the question is what information is there. In some Thawte branded
certificates there is only a domain name and only the domain name has
been authenticated. All the VeriSign branded SSL certificates (including
those off the old RSA root) are class 3 which requires authentication of
the subject identifier as well as the domain name.

The full details of the VeriSign assurance levels are given in the CPS.

If you want to connect up to an ISP to read you email or post to the
acne sufferers blog then all you need to be assured is the domain name.

If on the other hand what you want to do is to establish a commercial
relationship with a previously unknown entity then you need to be
assured that the party you are dealling with can be held legally and if
necessary criminally liable if the need arises.

> That is, if the developer cannot describe to the user what 
> the difference between two types of certificates is, the 
> application should not differentiate them to the user. Making 
> one "green" and one "not green" is a particularly bad method 
> without an explanation.

I think that the idea of comoditising trust levels is somewhat broken.
What the process is really about here is accountability. The purpose of
a ca process is to hold someone accountable. If the certificate holder
cannot be held accountable then lets hold the CA accountable in their
place.

The best way to do that is to show the CA who issued the certificate.
The real failure in the Shmoo group homologue cert was that the CA
should never have issued the certificate, I am somewhat disappointed
that the Shmoo paper never mentioned the CA concerned (not VeriSign).

Show the CA brand in place of the silly padlock icon and the problem of
inadequate assurance processes goes away. There will still be CAs who
attempt to compete to offer the minimum level of trust, most CAs however
will be looking to establish themselves as premium trust providers and
being the most careful and exclusive accreditors.

Content-class: urn:content-classes:message
Subject: RE: The new High Assurance SSL Certificates
Date: Mon, 16 Jan 2006 16:54:41 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Jeffrey I. Schiller" <[email-masked]>, "Joel S. Kazin" <[email-masked]>
Cc: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> [mailto:[email-masked]] On Behalf Of Jeffrey I. Schiller

> Thus my example about differentiating AOL.COM 
> from AO1.COM.
> 
> Bottom line: If this doesn't improve consumer confidence, 
> then it is a worthless exercise.

Lets add 'justifiably' in there.

I think that we need to forget the AOL.com AO1.com issue which is really
a geek-centric subset of the cases that affect consumers, it is merely
one example of the ways in which the reasonable expectations of the
consumer is betrayed. 

Jeff is giving one example of a more general problem: it is very easy to
make an authentication process that is 'failure proof' if we allow a
useless definition of failure. The only measures that really matter here
are consumer frauds and consumer confidence.

It is also a problem if someone goes to a site that has AOL graphics
plastered all over it and there is no way to quickly and reliably
determine whether or not it is the authorized AOL.

> My take on it is that 
> private key protection is not the problem we have. Phishing 
> is what it is about and phishing doesn't require stealing the 
> private key of the legitimate site.

The problem here is that private key hardware is something that is
objectively and empirically measurable. Quality of authentication
process is not.

What we need to do here is to look at the security of the system as a
whole. It is not just the authentication process that matters, it is the
control and feedback processes.

For example there is no way that any CA can test for honesty of the
certificate holder. The point of the original class 3 certification
process was not to assure the consumer that they were really dealling
with company X, it was to assure the consumer that if X defaulted for
any reason that there was a high degree of probability that the
perpetrators could be identified and face the relevant consequences.

Trusted Third Party services provide accountability based security, it
is a mistake to analyze them as if they were a permission based scheme. 

Permission based security, access control lists, kerberos etc, works
well in closed, tightly controlled environments where the set of rules
is known in advanceand all the security system is required to do is to
enforce the rules. It is not a feasible strategy in a system with a
billion users.

To take the Ao1.com example, the verisign class3 process ensures that
there is an authenticated contact address on file. If ao1.com attempts
to pass itself off as aol they can expect an immediate lawsuit. All
corporations that have strong trusted consumer brands are aware of the
need to protect them. The point about accountability is that it is not
just limited to anticipated abuses, it works also for fredonline.com if
they attempt to pass themselves off as aol by stealling their trade
dress.

Life has inherrent risk. There can never be absolute guarantees. There
is always a finite chance of being hit by a meteor. There is always a
risk that an assurance process will fail - especially if the underlying
government or commercial authentication processes that are relied on are
also fallible. 

There are three separate concerns here, 1) what is the probability of an
authentication failure, 2) what measures are in place to detect and
prevent repeat 3) to what extent can the consequences be mitigated?

Ultimately criminals respond to economics. There is no point in
obtaining a $x certificate fraudulently unless they can expect to
realize a gain of $x+$y where $y is large enough to justify the effort
involved and the risk of being caught.

Realtime revocation mechanisms such as OCSP are likely to pay much
better dividends in a high assurance certification system than some of
the processes being proposed. No authentication process however good
would have denied a certificate to Enron.

Content-class: urn:content-classes:message
Subject: RE: pathLenConstraint
Date: Mon, 16 Jan 2006 23:42:10 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Richard Levitte - VMS Whacker" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Sebastien,

Technically, all extensions in a Root certificate can be ignored by the
relying party since they are not used as input to the path validation
process.

Section 6.1.1. of RFC 3280 states the input from the selected trust
anchor:

      (d)  trust anchor information, describing a CA that serves as a
      trust anchor for the certification path.  The trust anchor
      information includes:

         (1)  the trusted issuer name,
         (2)  the trusted public key algorithm,
         (3)  the trusted public key, and
         (4)  optionally, the trusted public key parameters associated
         with the public key.

It can be debatable however if this is good or bad. The practice of our
(Microsoft) implementation is to by default process the extensions of
the root certificate (they probably was put there for some reason so we
honor them). In either case, your setup would work just fine.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Richard Levitte - VMS Whacker
Sent: den 16 januari 2006 05:37
To: [email-masked]
Cc: [email-masked]
Subject: Re: pathLenConstraint

In message
<[email-masked]> on Fri,
13 Jan 2006 16:24:49 +0100, "Kuhn, Sebastien" <[email-masked]>
said:

sebastien.kuhn> Could you confirm that the attribute
sebastien.kuhn> "pathLenConstraint" (included in the extension
sebastien.kuhn> "BasicConstraints") can have no limit in a Root CA
sebastien.kuhn> certificate and a finite value in a CA certificate
sebastien.kuhn> subordinate to the Root CA ?

Yes, as far as I understand.  I can't really imagine why it shouldn't

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         [email-masked]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
						-- C.S. Lewis

Date: Mon, 16 Jan 2006 11:57:42 -0800
To: "Aisenberg, Michael" <[email-masked]>, <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: The new High Assurance SSL Certificates
Sender: [email-masked]

At 11:01 AM -0500 1/16/06, Aisenberg, Michael wrote:
>Another "process" ("labour") is the intra industry saga of reaching 
>consensus on How and Where to do this (standards body, industry 
>assn.) and then doing it...Promptly.

I will repeat my earlier question, maybe a bit more pointed at the 
VeriSign folks on the list:

What is the difference between VeriSign high assurance and VeriSign 
low assurance certificates? If a developer can't answer the question, 
then the app doesn't need to differentiate.

That is, if the developer cannot describe to the user what the 
difference between two types of certificates is, the application 
should not differentiate them to the user. Making one "green" and one 
"not green" is a particularly bad method without an explanation.

--Paul Hoffman, Director
--VPN Consortium

Date: Mon, 16 Jan 2006 14:26:20 -0500
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
To: "Joel S. Kazin" <[email-masked]>
CC: Anders Rundgren <[email-masked]>, [email-masked]
Subject: Re: The new High Assurance SSL Certificates
OpenPGP: id=F414952B
Sender: [email-masked]

Joel S. Kazin wrote:
> As discussed at the October 2005 ABA ISC meeting, a HCA does not address
> the handling of a consumer's personal information.

Well, I wasn't at the meeting, so I cannot comment about what went on. I
can understand why it won't address how an organization handles personal
information. But it *should* address how a consumer can *know* they are
giving their information to whom they believe they giving their
information. Thus my example about differentiating AOL.COM from AO1.COM.

Bottom line: If this doesn't improve consumer confidence, then it is a
worthless exercise. My take on it is that private key protection is not
the problem we have. Phishing is what it is about and phishing doesn't
require stealing the private key of the legitimate site. It requires
fooling the consumer into thinking they are at the legitimate site when
in fact they are not. The goal should be to address (or solve) this
problem. I original message was to point out that this is more about
policy of certificate issuance then private key protection and that the
key piece of technology we need is really working revocation, something
we do not have today (at least in deployed technologies).

			-Jeff

P.S. What was the junk on the end of your message, looks like the dump
of some random Window's settings file!

- --
=============================================================================
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[email-masked]
============================================================================

Content-class: urn:content-classes:message
Subject: Re: The new High Assurance SSL Certificates
Date: Mon, 16 Jan 2006 11:01:43 -0500
From: "Aisenberg, Michael" <[email-masked]>
To: "Joel S. Kazin" <[email-masked]>, "Jeffrey I. Schiller" <[email-masked]>, "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C61AB6.24F5412B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Joel
Thanks for pointing out that this discussion is around Organizational =
certs, obtained from C/As by entities seeking to do business over the =
Net with consumers. Mediated by the browsers, these engagements are the =
ones where the consumers' understanding of the assurances being made (by =
the organization itelf,  by the  C/A, and (transitively ?) by the =
browser-chrome) are what is "at issue".  Under discussion in the C/A =
community is the ? of the means to best express a strong (more paper =
world-like) level of CA dilligence regarding the  identity attributes of =
the organizational subjects of these SSL certificates.  This is a =
process ...really, 2 processes. 1) attribute vetting by the CAs and 2) =
attribute display ("communication") in the browser, discernable and =
understandable to the consumer/user.  Another "process" ("labour") is =
the intra industry saga of reaching consensus on How and Where to do =
this (standards body, industry assn.) and then doing it...Promptly.

Michael

 -----Original Message-----
From: 	Joel S. Kazin [mailto:[email-masked]]
Sent:	Mon Jan 16 10:49:09 2006
To:	Jeffrey I. Schiller; Anders Rundgren
Cc:	[email-masked]
Subject:	Re: The new High Assurance SSL Certificates

As discussed at the October 2005 ABA ISC meeting, a HCA does not address =

the handling of a consumer's personal information.

----System Information
Platform: Windows 2000
Machine Type: Intel
System Version: 5.00.2195
Processor: Pentium II or III Model 8, Stepping 6
Physical RAM Installed: 261532 Kb
Eudora: Version 5.1
Mode: Sponsored Mode
Registration #:
MSHTML Version: 6.00
WININET Version: 6.00

At 04:37 PM 1/14/2006 -0500, Jeffrey I. Schiller wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I apologize, as I am joining this thread a little late.... and I =
haven't
>had time to read every single message.
>
>That said, I believe the issue of a High Assurance CA (HCA) isn't
>ensuring that private keys are properly protected (not that it isn't
>important), but ensuring that when consumers go to a site signed by a
>High Assurance CA, that they know they can trust it to properly handle
>their personal information. This is a much broader problem.
>
>To me this means that when AOL.COM goes to a HCA to obtain a =
certificate
>they get it. But when AO1.COM attempts to apply for one they are =
denied.
>
>The trick is how do you do this. If I start a company named ?AO1
>Vacuums? and have the legal right to use ?AO1? in my name, how can
>another company (or oligarchy) deny me the right to have my customers
>trust my website? Perhaps what is needed is legal language that let's
>AO1.COM obtain a certificate provided they agree to not intentionally
>attempt to confuse people into believing that they are AOL.COM. I'll
>leave it to the lawyers to figure out the language that accomplishes
>this goal.
>
>So now the real problem is revocation. If AO1.COM obtains a HCA
>certificate and turns out to be a bad actor, there needs to be an
>effective way of revoking their certificate. We don't have a deployed
>mechanism today. Perhaps this is what we need from a technical =
perspective.
>
>                         -Jeff
>
>- --
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>Jeffrey I. Schiller
>MIT Network Manager
>Information Services and Technology
>Massachusetts Institute of Technology
>77 Massachusetts Avenue  Room W92-190
>Cambridge, MA 02139-4307
>617.253.0161 - Voice
>[email-masked]
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDyW7+8CBzV/QUlSsRAkqYAKDWtkD0OQ6UDGCKGUz3buS6z2OdfgCg5W0H
>Dhey/w4/bCR1dvDqjduKpzo=3D
>=3DmED5
>-----END PGP SIGNATURE-----

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com

------_=_NextPart_001_01C61AB6.24F5412B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: The new High Assurance SSL Certificates</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Joel<BR>
Thanks for pointing out that this discussion is around Organizational =
certs, obtained from C/As by entities seeking to do business over the =
Net with consumers. Mediated by the browsers, these engagements are the =
ones where the consumers' understanding of the assurances being made (by =
the organization itelf,&nbsp; by the&nbsp; C/A, and (transitively ?) by =
the browser-chrome) are what is &quot;at issue&quot;.&nbsp; Under =
discussion in the C/A community is the ? of the means to best express a =
strong (more paper world-like) level of CA dilligence regarding =
the&nbsp; identity attributes of the organizational subjects of these =
SSL certificates.&nbsp; This is a process ...really, 2 processes. 1) =
attribute vetting by the CAs and 2) attribute display =
(&quot;communication&quot;) in the browser, discernable and =
understandable to the consumer/user.&nbsp; Another &quot;process&quot; =
(&quot;labour&quot;) is the intra industry saga of reaching consensus on =
How and Where to do this (standards body, industry assn.) and then doing =
it...Promptly.<BR>
<BR>
Michael<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Joel S. Kazin [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
m</A>]<BR>
Sent:&nbsp;&nbsp; Mon Jan 16 10:49:09 2006<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Jeffrey I. Schiller; Anders Rundgren<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: The new High =
Assurance SSL Certificates<BR>
<BR>
As discussed at the October 2005 ABA ISC meeting, a HCA does not =
address<BR>
the handling of a consumer's personal information.<BR>
<BR>
----System Information<BR>
Platform: Windows 2000<BR>
Machine Type: Intel<BR>
System Version: 5.00.2195<BR>
Processor: Pentium II or III Model 8, Stepping 6<BR>
Physical RAM Installed: 261532 Kb<BR>
Eudora: Version 5.1<BR>
Mode: Sponsored Mode<BR>
Registration #:<BR>
MSHTML Version: 6.00<BR>
WININET Version: 6.00<BR>
<BR>
At 04:37 PM 1/14/2006 -0500, Jeffrey I. Schiller wrote:<BR>
<BR>
&gt;-----BEGIN PGP SIGNED MESSAGE-----<BR>
&gt;Hash: SHA1<BR>
&gt;<BR>
&gt;I apologize, as I am joining this thread a little late.... and I =
haven't<BR>
&gt;had time to read every single message.<BR>
&gt;<BR>
&gt;That said, I believe the issue of a High Assurance CA (HCA) =
isn't<BR>
&gt;ensuring that private keys are properly protected (not that it =
isn't<BR>
&gt;important), but ensuring that when consumers go to a site signed by =
a<BR>
&gt;High Assurance CA, that they know they can trust it to properly =
handle<BR>
&gt;their personal information. This is a much broader problem.<BR>
&gt;<BR>
&gt;To me this means that when AOL.COM goes to a HCA to obtain a =
certificate<BR>
&gt;they get it. But when AO1.COM attempts to apply for one they are =
denied.<BR>
&gt;<BR>
&gt;The trick is how do you do this. If I start a company named ?AO1<BR>
&gt;Vacuums? and have the legal right to use ?AO1? in my name, how =
can<BR>
&gt;another company (or oligarchy) deny me the right to have my =
customers<BR>
&gt;trust my website? Perhaps what is needed is legal language that =
let's<BR>
&gt;AO1.COM obtain a certificate provided they agree to not =
intentionally<BR>
&gt;attempt to confuse people into believing that they are AOL.COM. =
I'll<BR>
&gt;leave it to the lawyers to figure out the language that =
accomplishes<BR>
&gt;this goal.<BR>
&gt;<BR>
&gt;So now the real problem is revocation. If AO1.COM obtains a HCA<BR>
&gt;certificate and turns out to be a bad actor, there needs to be =
an<BR>
&gt;effective way of revoking their certificate. We don't have a =
deployed<BR>
&gt;mechanism today. Perhaps this is what we need from a technical =
perspective.<BR>
&gt;<BR>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; -Jeff<BR>
&gt;<BR>
&gt;- --<BR>
&gt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<BR>
&gt;Jeffrey I. Schiller<BR>
&gt;MIT Network Manager<BR>
&gt;Information Services and Technology<BR>
&gt;Massachusetts Institute of Technology<BR>
&gt;77 Massachusetts Avenue&nbsp; Room W92-190<BR>
&gt;Cambridge, MA 02139-4307<BR>
&gt;617.253.0161 - Voice<BR>
&gt;[email-masked]<BR>
&gt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<BR>
&gt;-----BEGIN PGP SIGNATURE-----<BR>
&gt;Version: GnuPG v1.4.1 (GNU/Linux)<BR>
&gt;Comment: Using GnuPG with Thunderbird - <A =
HREF=3D"http://enigmail.mozdev.org">http://enigmail.mozdev.org</A><BR>
&gt;<BR>
&gt;iD8DBQFDyW7+8CBzV/QUlSsRAkqYAKDWtkD0OQ6UDGCKGUz3buS6z2OdfgCg5W0H<BR>
&gt;Dhey/w4/bCR1dvDqjduKpzo=3D<BR>
&gt;=3DmED5<BR>
&gt;-----END PGP SIGNATURE-----<BR>
<BR>
<BR>
Joel S. Kazin CPA, CISA, CISSP, CISM<BR>
Senior Consultant<BR>
Atos Origin<BR>
40 Old Sleepy Hollow Road<BR>
Pleasantville, New York 10570-3802<BR>
USA<BR>
Phone&nbsp; +1 914-769-8780<BR>
Mobile&nbsp; +1 914-564-1484<BR>
email&nbsp;&nbsp;&nbsp; [email-masked]<BR>
www.atosorigin.com<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C61AB6.24F5412B--

Date: Mon, 16 Jan 2006 09:13:18 -0500
To: "Jeffrey I. Schiller" <[email-masked]>, Anders Rundgren <[email-masked]>
From: "Joel S. Kazin" <[email-masked]>
Subject: Re: The new High Assurance SSL Certificates
Cc: [email-masked]
Sender: [email-masked]

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

As discussed at the October 2005 ABA ISC meeting, a HCA does not address 
the handling of a consumer's personal information.

----System Information
Platform: Windows 2000
Machine Type: Intel
System Version: 5.00.2195
Processor: Pentium II or III Model 8, Stepping 6
Physical RAM Installed: 261532 Kb
Eudora: Version 5.1
Mode: Sponsored Mode
Registration #:
MSHTML Version: 6.00
WININET Version: 6.00

At 04:37 PM 1/14/2006 -0500, Jeffrey I. Schiller wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I apologize, as I am joining this thread a little late.... and I haven't
>had time to read every single message.
>
>That said, I believe the issue of a High Assurance CA (HCA) isn't
>ensuring that private keys are properly protected (not that it isn't
>important), but ensuring that when consumers go to a site signed by a
>High Assurance CA, that they know they can trust it to properly handle
>their personal information. This is a much broader problem.
>
>To me this means that when AOL.COM goes to a HCA to obtain a certificate
>they get it. But when AO1.COM attempts to apply for one they are denied.
>
>The trick is how do you do this. If I start a company named ?AO1
>Vacuums? and have the legal right to use ?AO1? in my name, how can
>another company (or oligarchy) deny me the right to have my customers
>trust my website? Perhaps what is needed is legal language that let's
>AO1.COM obtain a certificate provided they agree to not intentionally
>attempt to confuse people into believing that they are AOL.COM. I'll
>leave it to the lawyers to figure out the language that accomplishes
>this goal.
>
>So now the real problem is revocation. If AO1.COM obtains a HCA
>certificate and turns out to be a bad actor, there needs to be an
>effective way of revoking their certificate. We don't have a deployed
>mechanism today. Perhaps this is what we need from a technical perspective.
>
>                         -Jeff
>
>- --
>=============================================================================
>Jeffrey I. Schiller
>MIT Network Manager
>Information Services and Technology
>Massachusetts Institute of Technology
>77 Massachusetts Avenue  Room W92-190
>Cambridge, MA 02139-4307
>617.253.0161 - Voice
>[email-masked]
>============================================================================
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDyW7+8CBzV/QUlSsRAkqYAKDWtkD0OQ6UDGCKGUz3buS6z2OdfgCg5W0H
>Dhey/w4/bCR1dvDqjduKpzo=
>=mED5
>-----END PGP SIGNATURE-----

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com

--=====================_1928603==_
Content-Type: text/plain; charset="us-ascii"

[Settings]
NC=1
Code=NC
NeverRegister=1
DontShowUpdates=1
DontShowAudit=1
WarnLaunchExtentions=exe|com|bat|cmd|pif|htm|do|xl|reg|lnk|vbs|
TabooHeaders=Received,Status,X-,In-Reply,Mime-Version,Content-,Resent-Message,References,Return,X400,X,Mail-System,Errors-To,Delivery,Disposition,Precedence
Mode=0
UserSignatures=1
SeenIntro=1
POPAccount=[email-masked]
RealName=Joel S. Kazin
SMTPServer=usarx006.namerica.na.int.atosorigin.com
ReturnAddress=[email-masked]
ACAPServer=
ACAPUserID=
PopServer=usarx006.namerica.na.int.atosorigin.com
LoginName=JKazin
LastOptionsCategory=0
AutoReceiveAttachmentsDirectory=D:\Documents\Mail\Attach
MailboxPreviewPane=1
MailboxSuperclose=1
WarnMapiAutoSend=1
NetworkCaching=0
EmptyTrashOnQuit=1
Commercial32Version=16
AdToolbarFloat=0
AdToolbarDock=2
MainWindowState=3
NGBase1=972453254
NGLast1=972453254
NGBase2=972453254
NGLast2=972453254
NGBase3=972453254
NGLast3=972453254
NGBase4=972453254
NGLast4=972453254
NGBase5=972453254
NGLast5=972453254
UseBidentAlways=1
LastWindowMax=0
Signature=Joel S. Kazin
MAPIUseNever=1
MAPIUseEudora=0
AutoExpandNicknames=1
DomainQualifier=
ImapDirectoryPrefix=
Stationery=
LeaveOnServerDays=0
BigMessageThreshold=40960
IMAPMaxDownloadSize=0
TrashMailboxName=Trash
CheckMailByDefault=1
LeaveMailOnServer=0
AuthenticateKerberos=0
AuthenticateAPOP=0
UseWinSock=1
AuthenticateRPA=0
UsesIMAP=0
UsesPOP=1
AuthenticatePassword=1
DeleteMailFromServer=0
ServerDelete=0
SkipBigMessages=0
IMAPMinDownload=1
IMAPOmitAttachments=0
TransferToTrashOnDelete=0
MarkAsDeleted=1
SmtpAuthAllowed=1
SuccessfulSend=1
CurrentTipOfTheDay=31
CheckForMailEvery=10
DontCheckUnconnected=1
TaskStatusStateWidth=120
TaskStatusStatusWidth=182
TaskStatusProgressWidth=133
NicknameLastActivePropertyPage=0
NicknameViewByIndex=6
FindMsgsCriteria1=Anywhere;contains;bank
FindMsgsCriteria2=Anywhere;contains;
FindMsgsCriteria3=Anywhere;contains;
FindMsgsCriteria4=Anywhere;contains;
FindMsgsCriteria5=Anywhere;contains;
FileBrowserNameWidth=100
FileBrowserTypeWidth=80
FileBrowserSizeWidth=45
FileBrowserModifiedWidth=120
PersonaViewNameWidth=90
PersonaViewAccountWidth=200
SearchResultsDateWidth=167
SearchResultsSubjectWidth=357
FindMsgsCriteriaCount=1
WarnDefaultMailto=0
RegistrationFlag=-1
CompactMailbox=10
CompactDisk=10
WarnExternalLaunchAttach=0
RegFirstNamePro=
RegLastNamePro=SiteLicense
RegCodePro=
SeenPlugins=x515x
SSLReceiveUse=0
SSLSendUse=0
LastTextColor=12
CompleterListHeight=41
ShowTipOfTheDay=0
AutoOK=1
Alert=0
WarnQueueStyledText=0
TaskMgrWaitTime=0
TaskStatusShowColDetails=1
TaskStatusDetailsWidth=320
NetworkBufferSize=409600
OfflineLinkAction=1
FetchInlineCOntent=0
RunHtmlCode=1
EasyOpen=1
LinkHistoryNameWidth=100
LinkHistoryDateVisitedWidth=140
LinkHistoryTypeWidth=50
ShowMailboxLines=1
MessageWidth=133
Profile=d0320018b4349321bc6558d4c0854c6c
WarnDeleteUnread=0

[Mappings]
out=txt,ttxt,TEXT,text,plain
both=doc,MSWD,,application,msword
out=mcw,MSWD,WDBN,application,msword
in=xls,XCEL,,,
out=xls,XCEL,XLS4,,
both=xlc,XCEL,XLC3,,
both=xlm,XCEL,XLM3,,
both=xlw,XCEL,XLW,,
both=ppt,PPT3,SLD3,,
both=wav,SCPL,WAVE,audio,microsoft-wave
both=grp,,,application,microsoft-group
both=wri,,,application,microsoft-write
both=cal,,,application,microsoft-calendar
both=zip,pZIP,pZIP,application,zip
both=rtf,MSWD,TEXT,application,rtf
both=pdf,,,application,pdf
both=ps,,,application,postscript
in=eps,,EPSF,,
out=eps,dPro,EPSF,application,postscript
both=jpg,JVWR,JPEG,image,jpeg
out=jpeg,JVWR,JPEG,image,jpeg
both=jfif,JFIF,JPEG,image,jpeg
both=gif,JVWR,GIFf,image,gif
both=tif,JVWR,TIFF,image,tiff
both=mpg,mMPG,MPEG,video,mpeg
both=mpeg,mMPG,MPEG,video,mpeg
both=mov,TVOD,MooV,video,quicktime
both=qt,TVOD,MooV,video,quicktime
both=png,,PNGf,image,png
both=htm,,,text,html
out=html,,,text,html
out=1st,ttxt,TEXT,text,plain
both=aif,SCPL,AIFF,,
both=arc,arc*,mArc,,
both=arj,DArj,BINA,,
out=asc,ttxt,TEXT,text,plain
out=asm,ttxt,TEXT,text,plain
both=au,SCPL,ULAW,,
out=bas,ttxt,TEXT,text,plain
out=bat,ttxt,TEXT,text,plain
out=bga,JVWR,BMPp,,
both=bmp,JVWR,BMPp,,
out=c,ttxt,TEXT,text,plain
both=cgm,GKON,CGMm,,
out=cmd,ttxt,TEXT,text,plain
out=com,mdos,BINA,,
out=cp,ttxt,TEXT,text,plain
out=cpp,ttxt,TEXT,text,plain
both=cpt,CPCT,PACT,,
out=csv,XCEL,TEXT,,
both=cvs,DAD2,drw2,,
out=dif,XCEL,TEXT,,
both=dl,GKON,DLdI,,
both=dvi,OTEX,ODVI,,
out=exe,mdos,BINA,,
out=faq,ttxt,TEXT,text,plain
out=flc,GKON,FLI,,
both=fli,GKON,FLI,,
both=fm,FMPR,FMPR,,
out=for,ttxt,TEXT,text,plain
both=gl,AnVw,,,
both=gz,Gzip,Gzip,,
out=h,ttxt,TEXT,text,plain
both=hqx,BnHq,TEXT,application,mac-binhex40
both=ico,GKON,ICO,,
both=iff,GKON,ILBM,,
both=ima,dCpy,dImg,,
both=img,GKON,IMGg,,
out=ini,ttxt,TEXT,text,plain
both=lbm,GKON,ILBM,,
both=lha,LARC,LHA,,
both=lzh,LARC,LHA,,
out=m3,ttxt,TEXT,text,plain
both=mac,dPro,PICT,,
out=mak,ttxt,TEXT,text,plain
out=me,ttxt,TEXT,text,plain
both=mod,SCPL,STrk,,
both=msp,GKON,MSPp,,
out=out,ttxt,TEXT,text,plain
out=p,ttxt,TEXT,text,plain
both=PAC,GKON,STAD,,
out=pas,ttxt,TEXT,text,plain
both=pbm,GKON,PPGM,,
both=pcs,GKON,PICS,,
both=pct,ttxt,PICT,,
both=pcx,GKON,PCXx,,
both=pgm,GKON,PPGM,,
both=pic,ttxt,PICT,,
both=pit,UPIT,PIT,,
both=plt,GKON,HPGL,,
both=pm,GKON,PMpm,,
both=pm3,ALD3,ALB3,,
both=pm4,ALD4,ALB4,,
both=pm5,ALD5,ALB5,,
both=pntg,SPNT,PNTG,,
both=ppm,GKON,PPGM,,
out=prn,ttxt,TEXT,text,plain
both=psd,8BIM,8BPS,,
both=qxd,XPRS,XDOC,,
both=rif,GKON,RIFF,,
both=rle,GKON,RLE,,
both=shp,GKON,SHPp,,
both=sit,SITx,SIT!,,
both=sit,SITx,SITD,,
both=slk,XCEL,TEXT,,
both=spc,GKON,Spec,,
both=sr,GKON,SUNn,,
both=sun,GKON,SUNn,,
both=sup,GKON,SCRN,,
both=svx,SCPL,8SVX,,
both=tar,TAR,TARF,,
both=tex,OTEX,TEXT,,
both=tga,8BIM,TPIC,,
both=tga,GKON,TARG,,
out=tx8,ttxt,TEXT,text,plain
out=vga,JVWR,BMPp,,
both=wks,L123,WKS,,
both=wmf,GKON,WMF,,
both=wp,WPC2,.WP5,application,wordperfect5.1
both=wp5,WPC2,.WP5,application,wordperfect5.1
both=z,LZIV,ZIVU,,
both=zoo,Booz,Zoo,,
both=qcp,Blad,celp,audio,vnd.qcelp

[]
CompactMailbox%25=10
CompactDisk%25=10

[Labels]
LabelCount=7
Label1=255,128,0,Label 1
Label2=255,0,0,Label 2
Label3=255,0,255,Label 3
Label4=0,128,255,Label 4
Label5=0,0,255,Label 5
Label6=0,128,0,Label 6
Label7=128,64,64,Label 7

[ToolBar-Bar0]
BarID=59393
Style=32768
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=1000000
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0

[ToolBar-Bar1]
BarID=318
Visible=0
XPos=0
YPos=0
MRUWidth=192
Docking=1
MRUDockID=59422
MRUDockLeftPos=1
MRUDockTopPos=5
MRUDockRightPos=1025
MRUDockBottomPos=608
MRUFloatStyle=8192
MRUFloatXPos=318
MRUFloatYPos=314
Style=8069
ExStyle=3889
PrevFloating=0
MDIChild=0
PctWidth=1000000
MRUFloatCX=192
MRUFloatCY=591
MRUHorzDockCX=1024
MRUHorzDockCY=603
MRUVertDockCX=228
MRUVertDockCY=643
MRUDockingState=61440
DockingStyle=61440
TypeID=0

[ToolBar-Bar10]
BarID=59423
Horz=0
Floating=1
XPos=4
YPos=64
Bars=3
Style=0
ExStyle=0
PrevFloating=0
MDIChild=1
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=319
Bar#2=0

[ToolBar-Bar2]
BarID=319
Visible=0
XPos=237
YPos=0
MRUWidth=722
Docking=1
MRUDockID=0
MRUDockLeftPos=5
MRUDockTopPos=-2
MRUDockRightPos=185
MRUDockBottomPos=500
MRUFloatStyle=4
MRUFloatXPos=312
MRUFloatYPos=312
Style=8069
ExStyle=3889
PrevFloating=0
MDIChild=0
PctWidth=1000000
MRUFloatCX=722
MRUFloatCY=475
MRUHorzDockCX=300
MRUHorzDockCY=180
MRUVertDockCX=180
MRUVertDockCY=502
MRUDockingState=0
DockingStyle=61440
TypeID=0

[ToolBar-Bar3]
BarID=320
Visible=0
XPos=-2
YPos=-2
MRUWidth=821
Docking=1
MRUDockID=59422
MRUDockLeftPos=1
MRUDockTopPos=5
MRUDockRightPos=1025
MRUDockBottomPos=105
MRUFloatStyle=8192
MRUFloatXPos=107
MRUFloatYPos=234
Style=12165
ExStyle=3889
PrevFloating=0
MDIChild=0
PctWidth=1000000
MRUFloatCX=821
MRUFloatCY=177
MRUHorzDockCX=1024
MRUHorzDockCY=100
MRUVertDockCX=180
MRUVertDockCY=180
MRUDockingState=61440
DockingStyle=0
TypeID=0

[ToolBar-Bar4]
BarID=316
XPos=-2
YPos=-2
Docking=1
MRUDockID=59422
MRUDockLeftPos=752
MRUDockTopPos=-11
MRUDockRightPos=1776
MRUDockBottomPos=164
MRUFloatStyle=8192
MRUFloatXPos=819
MRUFloatYPos=506
Style=12163
ExStyle=769
PrevFloating=0
MDIChild=0
PctWidth=1000000
MRUFloatCX=300
MRUFloatCY=180
MRUHorzDockCX=165
MRUHorzDockCY=156
MRUVertDockCX=165
MRUVertDockCY=643
MRUDockingState=61440
DockingStyle=0
TypeID=0

[ToolBar-Bar5]
BarID=59419
Bars=6
Style=0
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=59392
Bar#2=59424
Bar#3=0
Bar#4=65854
Bar#5=0

[ToolBar-Bar6]
BarID=59422
Bars=7
Style=0
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=65854
Bar#2=0
Bar#3=65856
Bar#4=0
Bar#5=65852
Bar#6=0

[ToolBar-Bar7]
BarID=59420
Bars=5
Style=0
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=65852
Bar#2=0
Bar#3=65854
Bar#4=0

[ToolBar-Bar8]
BarID=59421
Bars=5
Style=0
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=65852
Bar#2=0
Bar#3=65855
Bar#4=0

[ToolBar-Bar9]
BarID=59392
MRUWidth=734
Docking=1
MRUDockID=59419
MRUDockLeftPos=-1
MRUDockTopPos=-1
MRUDockRightPos=733
MRUDockBottomPos=42
MRUFloatStyle=8196
MRUFloatXPos=-2147483648
MRUFloatYPos=0
Style=12212
ExStyle=780
PrevFloating=0
MDIChild=0
PctWidth=500000
MRUFloatCX=734
MRUFloatCY=43
MRUHorzDockCX=734
MRUHorzDockCY=43
MRUVertDockCX=43
MRUVertDockCY=693
MRUDockingState=0
DockingStyle=61440
TypeID=14946
Title=Toolbar
Buttons=FCAIAAAAAAAAAAAAAAAAIBAIAAAAAAJBAIAAAAAAAAAAAAAAAAEAAIAAAAAAAAAAAAAAAANBAIAAAAAAHFAIAAAAAAIFAIAAAAAAPBAIAAAAAAAAAAAAAAAAFOAIAAAAAAGOAIAAAAAAAAAAAAAAAAECAIAAAAAAAAAAAAAAAAKAAIAAAAAAAAAAAAAAAAMDAIAAAAAAAAAAAAAAAAHABOAAAAAAAAAAAAAAAAFEBOAAAAAAAAAAAAAAAA

[ToolBar-BarID59392]
btn0=32805
btn1=0
btn2=32792
btn3=32793
btn4=0
btn5=32772
btn6=0
btn7=32797
btn8=32855
btn9=32856
btn10=32799
btn11=0
btn12=32997
btn13=32998
btn14=0
btn15=32804
btn16=0
btn17=32778
btn18=0
btn19=32828
btn20=0
btn21=57607
btn22=0
btn23=57669
btn24=0
CustomButtonCount=0

[ToolBar-Summary]
Bars=14
ScreenCX=1024
ScreenCY=768

[ToolBar-ToolBarManager]
ToolTips=1
CoolLook=1
LargeButtons=1

[Window Position]
AdToolbarWindowPosition=927,39,1024,82
MainWindowPosition=306,77,551,717
NicknamesWindowSplitterPosition=247
FindMsgsWindowPosition=22,22,686,374
StatisticsWindowPosition=0,0,670,528
ProgressWindowPosition=252,526,702,631
FiltersWindowSplitterPosition=252
TextFileWindowPosition=0,0,600,27
CheckSpellingWindowPosition=60,84,467,257

[DirectoryServices]
OldKeepOnTopConverted=1
TopPaneY=134
BottomPaneY=187
PanesX=281
LeftPaneX=254
RightPaneX=423
PanesY=420
KeepOnTop=0
Finger:Qualcomm Finger Server=0
LDAP:Big Foot=0
LDAP:Switch Board=0
LDAP:Four11=0
LDAP:InfoSpace=0
LDAP:InfoSpace Business=0
LDAP:Atos LDAP replica - Summary=1
LDAP:SLB LDAP all attributes=1
LDAP:SLB LDAP Europe summary=1
LDAP:SLB LDAP Europe all attributes=1
LDAP:Who Where=0
Ph:SLB Ph interface to LDAP=0
Ph:SLB Ph server=0
Ph:BigFoot=0
Ph:Qualcomm=0
Eudora Address Book:Eudora Nicknames=0

[ToolBar-Bar11]
BarID=59423
Horz=1
Floating=1
XPos=111
YPos=254
Bars=3
Style=0
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=320
Bar#2=0

[ToolBar-Bar12]
BarID=59423
Horz=0
Floating=1
XPos=10
YPos=66
Bars=3
Style=0
ExStyle=0
PrevFloating=0
MDIChild=1
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=318
Bar#2=0

[ToolBar-Bar13]
BarID=59423
Horz=1
Floating=1
XPos=823
YPos=526
Bars=3
Style=0
ExStyle=0
PrevFloating=0
MDIChild=0
PctWidth=0
MRUFloatCX=0
MRUFloatCY=0
MRUHorzDockCX=0
MRUHorzDockCY=0
MRUVertDockCX=0
MRUVertDockCY=0
MRUDockingState=0
DockingStyle=0
TypeID=0
Bar#0=0
Bar#1=316
Bar#2=0
[Open Windows]
OpenWindow1=2,1,Out.mbx,Out
OpenWindow2=2,3,In.mbx,In
[WazooBars]
WazooBarIds=318,319,320
WazooBar318=16,CMboxWazooWnd,CFileBrowseWazooWnd,CSignatureWazooWnd,CStationeryWazooWnd,CPersonalityWazooWnd
WazooMDI318=6,2,118,29,1,0
WazooBar319=16,CNicknamesWazooWnd,DirectoryServicesWazooWndNew,CFiltersWazooWnd,CFilterReportWazooWnd,CLinkHistoryWazooWnd
WazooMDI319=0,0,112,27,1,0
WazooBar320=64,CTaskStatusWazooWnd,CTaskErrorWazooWnd
[Recent File List]
File1=C:\Program Files\Qualcomm\Eudora\A
File2=D:\Documents\Pfizer\A
File3=D:\Documents\My Pictures\2004-11-12\A
File4=D:\Documents\ChevronTexaco\A

--=====================_1928603==_--

Date: Mon, 16 Jan 2006 14:36:50 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: pathLenConstraint
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Fri, 13 Jan 2006 16:24:49 +0100, "Kuhn, Sebastien" <[email-masked]> said:

sebastien.kuhn> Could you confirm that the attribute
sebastien.kuhn> "pathLenConstraint" (included in the extension
sebastien.kuhn> "BasicConstraints") can have no limit in a Root CA
sebastien.kuhn> certificate and a finite value in a CA certificate
sebastien.kuhn> subordinate to the Root CA ?

Yes, as far as I understand.  I can't really imagine why it shouldn't

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         [email-masked]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
						-- C.S. Lewis

From: "Kuhn, Sebastien" <[email-masked]>
To: [email-masked]
Subject: pathLenConstraint
Date: Fri, 13 Jan 2006 16:24:49 +0100
Sender: [email-masked]

Hello,

Could you confirm that the attribute "pathLenConstraint" (included in the
extension "BasicConstraints") can have no limit in a Root CA certificate and
a finite value in a CA certificate subordinate to the Root CA ?

Thank you in advance.

Sebastien.

Reply-To: "todd glassey" <[email-masked]>
From: "todd glassey" <[email-masked]>
To: <[email-masked]>, "Paul Hoffman" <[email-masked]>
Subject: Re: The new High Assurance SSL Certificates
Date: Sat, 14 Jan 2006 14:58:48 -0800
Sender: [email-masked]

Paul, if I may, one of the problems that this group is running into is
whether there is a mechanical process that High-Reliability requires or
whether the issuance and maintenance models are sufficient with these new
'reliance models' to support the proposed use models, and personally its all
about how they are used that should force the stratification between
high-reliance and low-dollar value transactions...

Todd Glassey

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, January 14, 2006 1:46 PM
Subject: Re: The new High Assurance SSL Certificates

>
> At 12:05 PM -0800 1/14/06, Mark wrote:
> >Applications need to have mechanisms embedded into them to
> >distinguish between high assurance and other certificates.
>
> Applications only need that if there is a difference that is
> noticeable to the user.
>
> Question: what is the difference between VeriSign high assurance and
> VeriSign low assurance certificates? If a developer can't answer the
> question, then the app doesn't need to differentiate.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

Date: Sat, 14 Jan 2006 13:46:34 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: The new High Assurance SSL Certificates
Sender: [email-masked]

At 12:05 PM -0800 1/14/06, Mark wrote:
>Applications need to have mechanisms embedded into them to 
>distinguish between high assurance and other certificates.

Applications only need that if there is a difference that is 
noticeable to the user.

Question: what is the difference between VeriSign high assurance and 
VeriSign low assurance certificates? If a developer can't answer the 
question, then the app doesn't need to differentiate.

--Paul Hoffman, Director
--VPN Consortium

Date: Sat, 14 Jan 2006 16:37:04 -0500
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
To: Anders Rundgren <[email-masked]>
CC: [email-masked]
Subject: Re: The new High Assurance SSL Certificates
OpenPGP: id=F414952B
Sender: [email-masked]

I apologize, as I am joining this thread a little late.... and I haven't
had time to read every single message.

That said, I believe the issue of a High Assurance CA (HCA) isn't
ensuring that private keys are properly protected (not that it isn't
important), but ensuring that when consumers go to a site signed by a
High Assurance CA, that they know they can trust it to properly handle
their personal information. This is a much broader problem.

To me this means that when AOL.COM goes to a HCA to obtain a certificate
they get it. But when AO1.COM attempts to apply for one they are denied.

The trick is how do you do this. If I start a company named ?AO1
Vacuums? and have the legal right to use ?AO1? in my name, how can
another company (or oligarchy) deny me the right to have my customers
trust my website? Perhaps what is needed is legal language that let's
AO1.COM obtain a certificate provided they agree to not intentionally
attempt to confuse people into believing that they are AOL.COM. I'll
leave it to the lawyers to figure out the language that accomplishes
this goal.

So now the real problem is revocation. If AO1.COM obtains a HCA
certificate and turns out to be a bad actor, there needs to be an
effective way of revoking their certificate. We don't have a deployed
mechanism today. Perhaps this is what we need from a technical perspective.

			-Jeff

- --
=============================================================================
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[email-masked]
============================================================================

Date: Sat, 14 Jan 2006 12:05:38 -0800
From: Mark <[email-masked]>
Subject: Re: The new High Assurance SSL Certificates
To: Anders Rundgren <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

I agree with your two points.  Applications need to have mechanisms 
embedded into them to distinguish between high assurance and other 
certificates.  One of the standards I'm currently working on that may 
help is looking at using XML to classify documents.  I know that it 
does not directly relate to high assurance SSL server certificates and 
I will get to that point later.  There must be a way to distinguish how 
information and assets are differentiated by applications.  One of the 
ways is to enable a policy based management of information and 
certificates.  Using information classification you can set up policies 
to manage how that information is treated when it is sent or received.  
It still depends very much on the applications being able to 
differentiate the information.  However in looking at standards and how 
we could use PKI to provide a layer of security to further protect 
sensitive information and transactions we need some standards around 
how information is classified to improve interoperability.

On the second point it boils down to an organization issuing the high 
assurance certificates.  Somehow there needs to be a way to authorize 
and authenticate the certificate using existing methods.  We already 
deal with SSL certificates and can check revocation.  If several 
organizations are authorized and accredited to issue high assurance 
certificates, then applications can check CRLs or whatever the 
organization uses to validate high assurance certificates.  Now what 
organization should authorize and accredit organizations issuing high 
assurance certificates?  It should be not be government.

Sorry for getting a bit off-topic on the XML and information 
classification but I believe that there are a number of pieces to this 
issue and it gets down to business automation and there is a connection 
between using XML and PKI to enable policy based management of 
transactions and information.  I'd like to hear from others if I'm off 
base or this resonates with people.

Cheers

On 14-Jan-06, at 3:16 AM, Anders Rundgren wrote:

>
> Apparently a number of commercial issuers of certificates are
> currently considering creating a new class of "High Assurance"
> (HA) SSL server-certificates, in order to improve the somewhat
> bad reputation associated with the current scheme.
>
> In a recent Mozilla blob, it was suggested that Firefox in order to
> recognize that it is really dealing with a high assurance certificate
> (and presumably showing that to the user in some way), should rely on
> a specific set of agreed-upon RFC 3280 policy identifiers.  This is
> in my opinion not a particularly good idea for two reasons:
>
> 1.  SSL server-certificates are extensively used for other 
> applications, both
> in server-mode and in client-mode (as signature certificates).  Few if
> any of these applications, are currently "trained" to rely on anything
> but root anchors.   If you roll your own certs which is quite common
> in local installations, current instructions on how to use SSL such as
> featured in IIS, OpenSSL, Tomcat, JDK etc. never go into policy
> identifiers.
>
> 2. I may be wrong here, but is there actually anything that prevents a 
> low-
> assurance certificate issuer to include high assurance policy 
> identifiers?
>
> That is, the new HA certificates should preferably support the 
> following
> policy scheme:
>
>        CA_root => Implicit Policy + Explicit Policy
>
> ======================================================================
> Commercial issuers should seriously consider the liability issues
> associated with having a single root for different kinds of
> certificates.  It can in such a scheme hardly be the relying party
> who is responsible for unintentionally accepting "wrong" certificates.
> ======================================================================
>
> Note that this should not be interpreted as that there should not be
> any HA policy identifiers, it is just the idea to FORCE their usage
> on applications that I believe would in fact only complicate rollout.
>
> Comments?
>
> Anders Rundgren
>
> Disclaimer: The views expressed in this message are solely the
> author's and should not be attributed to his employer or their clients
>

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: The new High Assurance SSL Certificates
Date: Sat, 14 Jan 2006 12:16:50 +0100
Sender: [email-masked]

Apparently a number of commercial issuers of certificates are
currently considering creating a new class of "High Assurance"
(HA) SSL server-certificates, in order to improve the somewhat
bad reputation associated with the current scheme.

In a recent Mozilla blob, it was suggested that Firefox in order to
recognize that it is really dealing with a high assurance certificate
(and presumably showing that to the user in some way), should rely on
a specific set of agreed-upon RFC 3280 policy identifiers.  This is
in my opinion not a particularly good idea for two reasons:

1.  SSL server-certificates are extensively used for other applications, both
in server-mode and in client-mode (as signature certificates).  Few if
any of these applications, are currently "trained" to rely on anything
but root anchors.   If you roll your own certs which is quite common
in local installations, current instructions on how to use SSL such as
featured in IIS, OpenSSL, Tomcat, JDK etc. never go into policy
identifiers.

2. I may be wrong here, but is there actually anything that prevents a low-
assurance certificate issuer to include high assurance policy identifiers?

That is, the new HA certificates should preferably support the following
policy scheme:

       CA_root => Implicit Policy + Explicit Policy

======================================================================
Commercial issuers should seriously consider the liability issues
associated with having a single root for different kinds of
certificates.  It can in such a scheme hardly be the relying party
who is responsible for unintentionally accepting "wrong" certificates.
======================================================================

Note that this should not be interpreted as that there should not be
any HA policy identifiers, it is just the idea to FORCE their usage
on applications that I believe would in fact only complicate rollout.

Comments?

Anders Rundgren

Disclaimer: The views expressed in this message are solely the
author's and should not be attributed to his employer or their clients

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-02.txt 
Date: Fri, 13 Jan 2006 18:50:01 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 
                          Certificate and Certificate Revocation List (CRL) Profile
	Author(s)	: D. Cooper, et al.
	Filename	: draft-ietf-pkix-rfc3280bis-02.txt
	Pages		: 140
	Date		: 2006-1-13
	
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-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-rfc3280bis-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-rfc3280bis-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-rfc3280bis-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rfc3280bis-02.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: RE: I-D ACTION:draft-ietf-pkix-ecc-pkalgs-02.txt 
Date: Fri, 13 Jan 2006 22:13:01 -0000
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

There is a problem with this latest draft submission.
If you download it, it appears as a .zip file, but it is not.

If you just rename it as a regular text file then you can open it as
usual.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: den 6 januari 2006 15:50
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ecc-pkalgs-02.txt 

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-02.txt
	Pages		: 25
	Date		: 2006-1-6
	
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-02.txt

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

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

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ecc-pkalgs-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.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ecc-pkalgs-02.txt 
Date: Fri, 06 Jan 2006 18:50:01 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Additional Algorithms and Identifiers for use of Elliptic Curve Cryptography with PKIX
	Author(s)	: D. Brown
	Filename	: draft-ietf-pkix-ecc-pkalgs-02.txt
	Pages		: 25
	Date		: 2006-1-6
	
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-02.txt

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

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

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

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

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

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

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

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ecc-pkalgs-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, 02 Jan 2006 23:16:39 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Certificate Validity Problem
Sender: [email-masked]

santosh chokhani wrote:
> If the cryptanalysis or compromise of expired keys is not a concern, one
> could do cumulative CRL using an X.509 extension (3280 does not have this)
> stating that the CRL contains expired certificates.
>   
I'm replying a bit late, but IMO that extension from X.509 (2005) 
(expiredCertsOnCRL) would be a very useful addition to rfc 3280bis.

If the motivation for not including it is to keep the document small, I 
can make a list of much less needed elements to remove :-)