Subject: surprise

From: [email-masked]
Date: Thu, 31 Mar 2005 09:42:05 -0700

FROM: THE DIRECTOR
EUROPEAN PRIZE AWARD DEPT.
REF:EL3/9318/04
BATCH:8/163/EL.
  
Dear Sir/Madam,
  
We are pleased to inform you of the result of the Lottery Winners
International programs held on
the   29/01/2005.
  
Your e-mail address attached to ticket number:EL-23133 with serial
Number: EL-123542, batch number: 8/163/EL-35,lottery Ref number: EL-9318
and drew lucky
numbers 7-1-8-36-4-22 which consequently won in the 1st category, you have
therefore been approved for a
lump sum pay out of US$1,500,000.00 (One Million,Five Hundred Thousand
United States dollars)
  
CONGRATULATIONS!!!
  
Due to mix up of some numbers and names, we ask that you keep your Winning
information confidential
until your claims has been Processed and your money Remitted to you. This
is part of our Security
protocol to avoid double claiming and unwarranted abuse of This program by
some participants. All
participants were selected through a computer ballot system drawn from over
40,000 company and
20,000,000 individual email addresses and names from all over the world.
  
This promotional program takes place every year. This lottery was Promoted
and sponsored by a
group of successful electronic dealers. we hope with part of your winning,
you will take part in our next
year US$20 million international lottery. To file for your claim, please
Contact our paying officer:
Contact Person: Mr. Eric Van Brood(Lottery Director)
Eric Van Brood
Tel: +31-617-012-526
Email: [email-masked]
       [email-masked]
  
Remember, all winning must be claimed not later than 7th of March,
2005.After this date all unclaimed
funds will be included in the next stake.
  
Please note in order to avoid unnecessary delays and  complications Please
remember to quote your
reference number and batch numbers in all correspondence.
  
Furthermore, should there be any change of address do inform our agent as
soon as possible.
  
Congratulations once more from our members of staff and thank you for being
part of our promotional
program.
  
Note:
Anybody under the age of 18 is automatically disqualified.
  
yours Sincerely,

Mr. Eric Van Brood
Tel: +31-617-012-526
Email: [email-masked]
       [email-masked]

Content-class: urn:content-classes:message
Subject: Issue #5 - AIA in CRL draft
Date: Wed, 30 Mar 2005 12:50:41 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

All,

At IETF in Minneapolis it was decided to take presented issue #5,
regarding AIA in CRL draft, to the list before issuing a new draft for
WG last call.

This was the issue:

The AIA in CRL draft was submitted slightly before RFC3280bis and thus
the MUST and SHOULD support access methods for the AIA extension in
RFC3280bis has to be synchronized with the AIA in CRL draft.

RFC 3280bis requirements:
  - directoryName allowed (may be used for DAP or LDAP)
  - uniformResourceIdentifier allowed (may be used for, LDAP, HTTP, and
FTP)
  - When the id-ad-caIssuers accessMethod is used, at least one instance
    SHOULD specify an accessLocation that is an HTTP or LDAP URI

The AIA in CRL draft requirements:

  - All present accessLocation values MUST use the
uniformResourceIdentifier 
    [URI] form, and the values MUST use either the ldap scheme [LDAP] or
the 
    http scheme [HTTP/1.1].

Proposed resolution, preliminary agreed at the Minneapolis IETF, is to
use the rules defined in RFC 3280bis.

Unless I here some objections within the next couple of days I will
include this change in the new draft and re-submit for WG last call.

Stefan Santesson

To: [email-masked]
Subject: draft-ietf-pkix-scvp-18.txt comments
From: "Frank Balluffi" <[email-masked]>
Date: Tue, 29 Mar 2005 12:23:16 -0500
Sender: [email-masked]

Sorry for the late comments and if others have already made them.

1. Should ValidationPolicy's extendedKeyUsages include "SIZE (1..MAX)" -- 
section 3.2.4?

2. Why is the type ValidationAlg defined (section 3.2.4.2)? Why not use 
AlgorithmIdentifier?

3. CVRequest's requestorName is of type GeneralName [singular] (section 
3), yet CVResponse's requestorName is of type GeneralNames [plural] 
(section 4)? Is this intentional or a mistake?

4. In section 4.9.4, the status values 2 (Revocation Offline) and 3 
(Revocation Unavailable) imply that a path was built and validated, but 
the document does not explicitly state this. Should the document 
explicitly state this?

5. observation: The order of certificates in a CertBundle is least 
significant first (section 4.9.5), whereas Web Services Security's 
wsse:PKIPath is the opposite (most significant first) -- see 
WS-Security-Addendum200208.pdf. Too bad they are different.

6. typo: The first sentence of section 4.12 should say "the 
cvResponseExtensions item", not "the CVResponseExtensions item".

7. In section 6, should the following ValPolResponse items include "SIZE 
(1..MAX)":

validationPolices
validationAlgs
authPolicies
serverPublicKeys

Frank

From: "Paulette Rowell" <[email-masked]>
To: "'Ietf-pkix-archive'" <[email-masked]>
Subject: Tha new rawlex repliccas has finelly arrived bloodshot
Date: Mon, 28 Mar 2005 11:21:23 +0400

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

The new craze is finnally here - one of the bast
sites that can give you the things you've allways
wanted to get - watchees, repliccas to be correct,
of the bast brand s in the world! Impress you're lady
with tag heur, roleex, and more. You naame it - We
got it for you!

mmmmm show me more :-)
http://aldehyde.pqer.com/r/erika/ct.htm

conditions causing symptom foot symptoms including possible skin on toes bumps on toes d diabetes foot numbness foot diseases risks feedback symptom foot.
if this x box live link works for you then you do not have to go elsewhere this x box live site is just what you re looking for it s right up there with the best net information on x box live.
effects of arthritis exercise programs on functional fitness and perceived activities of daily living measures in older adults with arthritis.
oh yeah my old roommate andrew rathweg married the former courtney chesnut in fort lauderdale this past november it was a hell of a time and she s a great addition to the family.
- de som �lskar att prata om kvinnomisshandel borde en enda g�ng avsl�ja hur full fart �r incest i svekja.
divorce form from divorce and file as a pro se litigant pro se means to represent oneself illinois no-fault divorce legal form kit indiana no-fault divorce.
fy - madonna jesus cristo manukov eu tenho vários ídolos uns são eternos outros se revelam durante uma temporada e somem depois.
max no because it s the egyptian goddess bast the goddess who comprehends all goddesses eye of ra protector avenger destroyer giver of life who lives forever.
good evening major the major evening mrs fawlty melbury is glancing at some coins in a display case basil brings him his drink.
with evidence that geographically bounded city growth actually creates more construction jobs than sprawled growth who d a thunk it nbsp.
a wave of joy sweeps over her face at once she helps belden to crawl into her room once safely inside she quickly shuts and locks the door.
he collapsed so they stripped him and poured cold water over him they brought a man who was wearing a hood they pulled it off the son was shocked to see it was his father and collapsed.
thanks so much for the page the post cards bring back the memories that will never be forgotten one day i will return to the county but until then i always have the internet to remember it by.
however she could be the one off type of person who goes out not very often at all like me in which case it could work out.
to see just how pervasive this problem can be explore other resources as well including an essay on.
- d�rf�r varnar vetenskapsm�n oss att bevara m�nsklgheten af perversiteten medicin �r bara en liten del av denna omfattande handeln�.
so i hear i m the only member of it s a smiley not a u! how come? it would be such a cute clique for all those rabid texters around here go join it! just download the graphic from.
hey nice site i hope i win an award go to my site if you read this allen iverson net world!!!!!!!!!!!

----eoemdatse26944203cqvae--

Date: Wed, 23 Mar 2005 17:25:03 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: About RFC 3280bis
Cc: [email-masked]
Sender: [email-masked]

chapter 6.2 has the following phrase: 

   "An implementation that supports multiple trust anchors
   MAY augment the algorithm presented in section 6.1 to further limit
   the set of valid certification paths which begin with a particular
   trust anchor."

I suggest to change this into two independant sentences because
the second part of the sentence also applies if there is only
one trust anchor.   

   "An implementation MAY support multiple trust anchors
    with different sets of initialisation values for
    each trust anchor.

    An implementation MAY augment the algorithm presented in section 6.1
    to further limit the set of valid certification paths which begin 
    with a particular trust anchor."

A second suggestion is to add something like:

    In case of multiple trust anchors, an extended the algorithm
    MUST prohibit uncontrolled usage of different trust anchors
    for the validation of cert path, CRL paths or validation services
    paths.

    In many cases, path validation for the cert, the CRL or a 
    validation service use the same trust anchor, but an extended
    validation algorithm may use different but associated trust 
    anchors for each path.

Peter

Date: Mon, 21 Mar 2005 15:25:54 +0400
From: Michele Waddell <[email-masked]>
Subject: Get your hand clock repliacs todday crud
To: [email-masked]

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

The new craze is finnally here - one of the bast
sites that can give you the things you've allways
wanted to get - watchees, repliccas to be correct,
of the bast brand s in the world! Impress you're lady
with tag heur, roleex, and more. You naame it - We
got it for you!

mmmmm show me more
http://anise.ru6.net/r/erika/abandon.htm

i wish you all the best to establish amyloid toxicity in primary newronal cell cultures and developing assays for high through put screening.
have you had a problem with the dvd from the george harrison boxed set getting scratched? paul soper has written to emi who says they re looking into the problem we ll let you know the outcome.
kathy your poem is so descriptive you made me feel like i was right there nbsp realy good poem.
he still wants to build the civilian core as discussed in the presidential race i forgot the name he used i m tired and distracted.
received the information about your website from our son frank a ruta who lives in arlington frank is chef and owner of palena restaurant in washington on connecticut ave.
androgynous it is necessary that you have a clear photo of yourself as femme from.
big brother update the nominees up for eviction this week are katrina turkan damien my pick would be turkan.
this is a very good site and i have been very pl eased with the results so far thank you so much.
woah! i always thought that cheerleading is gayish but my experience today in church changed my thinking totally.
nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp updates when ever i obtain more information such as hyperlinks.
i lived for many years near the sea doing a business the seaside is the best place to spend time when one needs peace.
peter blake who designed the sgt pepper cover has created his first new portraits of the fabs since then for a new exhibit.
remember the question is should we pay for more rail transportation not if amtrak should be the operator.
sara o que est�o esperando! tirem esse pano! os elfos obedecem ela se volta para os alunos agora crian�as vamos ver se.
i felt from the very beginning the drug companies were covering up i felt from the very beginning that these drugs were dangerous.
nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp share all that we know and hopefully learn all that you know nbsp.
nesse momento um grupo de elfos dom�sticos entra carregando um grande espelho coberto por um pano o espelho � colocado no ch�o e dobby se adianta.
fill in the blanks below to add to our guestbook the only blanks that you have to fill in are the comments and name section thanks!

----VIMLTSLCA76271740QXOV--

Date: Mon, 21 Mar 2005 09:48:43 +0100
From: Denis Pinkas <[email-masked]>
To: pkix <[email-masked]>
Subject: Comments on SCVP
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<p class="MsoNormal"><span lang="EN-US"
 style="font-family: &quot;Courier New&quot;;"><!--[if !supportEmptyParas]-->To
the list (and Tim),<br>
<br>
A. I would like to mention upfront that I share the same concerns like <br>
Wen-Cheng on the validation algorithm which should be suppressed.<br>
<br>
<br>
B. I have the same concern like Sharon, but a solution different <br>
from the one she proposed.<br>
<br>
When there is a request to a service, the service MUST attempt to <br>
perform the request AND DO NO MORE.<br>
<br>
This golden rule SHALL not be changed. Changing it would face us with
major <br>
complications and would lead us to much complexity, in particular for <br>
clients having to process unwanted responses.<br>
<br>
So PLEASE, remove all text involving more processing by the client than
<br>
what is requested by the client.<br>
<br>
<br>
C. I would also like mention that the concept of default validation
policy <br>
is unnecessary. In a request when someone wants to use a default value,
<br>
then the value is simply omitted and there is no need to specify an OID
to <br>
say "this OID means the default". As an example, RFC 3161 is based in
that <br>
paradigm. Let us not use the statement "why make it simple, when it can
be <br>
complicated ? " Please suppress the OID of the default validation
policy. <br>
<br>
<br>
Hereafter are some revised comments, based on the previous e-mail.<br>
<br>
1. A new wording introduced in the document which is: "PKI policies".
This<br>
term is defined nowhere in RFC 3280, nor in this document. When it is<br>
used, it seems to mean "validation policy". Please delete everywhere
"PKI<br>
policy" and replace it with "validation policy".<br>
<br>
<br>
Tim: Both occurrences of "PKI policies" have been changed to
"validation <br>
policies" to align with 3379.&nbsp; (There were no occurrences of "PKI
policy".)<br>
<br>
Denis: Fine<br>
<br>
2. On page 7 the new term "basic certification path processing
algorithm"<br>
is introduced whereas RFC 3280 uses a different wording :<br>
<br>
&nbsp;- "certification path validation" (that is the title of section 6) and<br>
&nbsp;- "basic path validation" (that is the title of section 6.1).<br>
<br>
Please do not introduce a new term.<br>
<br>
Tim: The sentence will be revised as follows:<br>
<br>
SCVP defines a basic validation algorithm which implements the basic
path <br>
validation algorithm as defined in [PKIX-1], and permits the client to <br>
request additional information about the certificate to be validated. <br>
<br>
Denis: This does not work: the inputs to the certification path
validation <br>
algorithm used by SCVP are NOT those defined by [PKIX-1] in section
6.1.1 <br>
but those defined by section 6.2 which allow more than one trust anchor.<br>
<br>
SCVP MUST allow to perform the certification path validation from
section 6 <br>
and 6.2 and not simply the basic path validation from section 6.1. A <br>
validation policy includes more than one trust anchor. <br>
<br>
There can be no compromise on this issue: PKIX-compliant certification
path <br>
validation is NOT simply section 6.1 from RFC 3280.<br>
<br>
Furthermore there is no need to "permit the client to request
additional <br>
information about the certificate to be validated".<br>
<br>
<br>
3. The text refers to section 6.1.1 and it is said that one the input in<br>
section 6.1.1 is a "Set of Trust Anchors". This is not consistent with<br>
section 6.1.1 from RFC3280 which deals with a *single* trust anchor,<br>
while section 6.2 from RFC 3280 deals with multiple trust anchors.<br>
<br>
>From the introduction, "a validation policy contains one or more trust<br>
anchors". The protocol should allow, with a single request-response, to<br>
check if a certificate is valid against a validation policy which has<br>
more than one trust anchor. These checks should be done in accordance<br>
with section 6.2 from RFC 3280. The current ASN.1 is not conformant with<br>
section 6.1 from RFC 3280.<br>
<br>
Tim: The trust anchor text will be removed from the list associated
with <br>
6.1.1 and relegated to the following paragraph.&nbsp; The following
paragraph <br>
will state the options and use cases. <br>
<br>
&nbsp;&nbsp;&nbsp; The inputs to the basic certification path processing algorithm<br>
&nbsp;&nbsp;&nbsp; used by SCVP are defined by [PKIX-1] in section 6.1.1 and<br>
&nbsp;&nbsp;&nbsp; comprise:<br>
<br>
&nbsp;&nbsp;&nbsp; Certificate to be validated (by value or by reference);<br>
<br>
&nbsp;&nbsp;&nbsp; Validation time;<br>
<br>
&nbsp;&nbsp;&nbsp; The initial policy set;<br>
<br>
&nbsp;&nbsp;&nbsp; Initial inhibit policy mapping setting;<br>
<br>
&nbsp;&nbsp;&nbsp; Initial inhibit anyPolicy setting; and<br>
<br>
&nbsp;&nbsp;&nbsp; Initial require explicit policy setting.<br>
<br>
The basic certification path processing algorithm also supports <br>
specification of one or more Trust Anchors (by value or reference) as
an <br>
input.&nbsp; Where the client demands a certification originating with a <br>
specific CA, a single Trust Anchor is specified.&nbsp; Where the client is <br>
willing to accept paths beginning with any of several CAs, a set of
Trust <br>
anchors is specified.<br>
<br>
Denis: This is still incorrect. The basic certification path processing
<br>
algorithm DOES NOT support specification of one or more Trust Anchors
(by <br>
value or reference) as an input.<br>
<br>
For each Trust Anchor the set of parameters may be different. The
current <br>
ASN.1 structure would not allow for it. see a proposal further down in <br>
these comments.<br>
<br>
<br>
4. Section 1.4 is about a validation algorithm. Different rules may
apply<br>
to every trust anchor and to the CA certificates from the certification<br>
path under every trust anchor. The ASN.1 description of ValidationPolicy<br>
starting on page 17 does not allow the client to define CA related<br>
different parameters for every trust anchor.<br>
<br>
We currently have:<br>
<br>
ValidationPolicy ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; validationPolRef&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ValidationPolRef,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; validationAlg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [0] ValidationAlg OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; userPolicySet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [1] SEQUENCE SIZE (1..MAX) OF OBJECT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IDENTIFIER OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; inhibitPolicyMapping&nbsp; [2] BOOLEAN OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; requireExplicitPolicy [3] BOOLEAN OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; inhibitAnyPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [4] BOOLEAN OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; trustAnchors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [6] TrustAnchors OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; keyUsages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [7] KeyUsages OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extendedKeyUsages&nbsp;&nbsp;&nbsp;&nbsp; [8] SEQUENCE OF KeyPurposeId OPTIONAL}<br>
<br>
and<br>
<br>
ValidationAlg ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; valAlgId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT IDENTIFIER,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; parameters&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ANY DEFINED BY valAlgId OPTIONAL }<br>
<br>
If:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; trustAnchors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [6] TrustAnchors OPTIONAL,<br>
<br>
is changed into:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; trustAnchor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [6] TrustAnchor OPTIONAL,<br>
<br>
&nbsp;... then this would be conformant with the algorithm from section 6.1
of<br>
RFC 3280, but validation policies with multiple trust anchors and their<br>
own parameters could not be used.<br>
<br>
The conditions that apply to CA certificates may be very complicated and<br>
vary from one trust anchor to another. The goal if this document is to<br>
support section 6.2 from FRC 3280.<br>
<br>
Using your ASN.1, the client would need to repeat the request for each <br>
Trust Anchor.<br>
<br>
Tim: Using the current ASN.1, the client could use a single request for
<br>
each set of Trust Anchors that shared the set of parameters.&nbsp; If the
client <br>
wishes to specify different parameters, then the client must use
multiple <br>
requests.<br>
<br>
In my opinion, the current ASN.1 provides a reasonable compromise
between <br>
complexity and functionality.<br>
<br>
Denis: This is not acceptable. There cannot be such a "reasonable <br>
compromise". It would be unacceptable to ask for one call per Trust
Anchor. <br>
<br>
A validation policy could OPTIONALLY include several "target certificate<br>
specific parameters" as Wen-Cheng proposed, since they usually do not<br>
change from one trust anchor to another.<br>
<br>
This would also solve the problem that Wen-Cheng noticed about the "name<br>
validation algorithm".<br>
<br>
Note that, as Wen-Cheng proposed, "target certificate" seems to be a<br>
better term rather than "end certificate"<br>
<br>
It is obvious that for each certification path, the algorithm from
section <br>
6.1 of RFC 3280 is being used. The validationAlg parameter is not<br>
needed.<br>
<br>
We have already given the counter example (proxy certs) where this <br>
parameter *is* needed.<br>
<br>
Denis: No. A validation policy may have any set of parameters.
Suppressing <br>
the set of parameters of the validation algorithm would solve the issue.<br>
<br>
We could then simply have:<br>
<br>
ValidationPolicy ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; validationPolRef&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ValidationPolRef,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; keyUsages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [0] KeyUsages OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extendedKeyUsages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [1] SEQUENCE OF KeyPurposeId OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nameValidationAlgParms&nbsp;&nbsp; [2] NameValidationAlgParms OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; otherTests&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [3] OtherTests OPTIONAL<br>
&nbsp;&nbsp; }<br>
<br>
additionalTests could be used for example to test QCStatements
extensions<br>
presence and values, which would be very useful for Qualified<br>
Certificates.<br>
<br>
Tim: Other tests are currently supported in conjunction with the
validation <br>
algorithm.<br>
<br>
Denis: Once again the structure above is able to solve the issue: we
have <br>
to make the difference between the set of parameters which is related
to <br>
the CA hierarchy (up to one or more Trust Anchors) and the parameters
which <br>
are related to the target certificate. See an updated proposal further
down <br>
in this e-mail.<br>
<br>
<br>
5.Section 1.5 states: "However, revocation checking is an optional<br>
feature in [PKIX-1], ... " This is incorrect.<br>
<br>
RFC 3280 does not say that revocation checking is optional. Only CRLs <br>
processing is defined in RFC 3280 but we all know that OCSP is an <br>
alternative method. For DPV, revocation checking MUST be done to
validate a <br>
certification path, but this may be done using different means. This
means <br>
may be specified in the validation policy.<br>
<br>
Tim: First, I am not sure what change(s) you are advocating here.&nbsp; Is
the <br>
problem this sentence or are you advocating additional restrictions on
DPV <br>
services ?<br>
<br>
Second, I also do not agree with your interpretation of 3280.<br>
<br>
In RFC 3280, CAs are required to either issue CRLs or have another <br>
mechanism to distribute that information.&nbsp; (No restrictions are
specified <br>
on that mechanism so I presume publishing it in the New York Times
would be <br>
okay.)&nbsp; RFC 3280 does not explicitly impose these requirements on
relying <br>
parties.&nbsp; In fact, there are indications in both 3280 and 3647 that <br>
revocation checking need not be performed by relying parties. <br>
<br>
Denis: There is no such statements. See below <br>
<br>
>From the security considerations section in RFC 3280:<br>
<br>
Similarly, implementations of the certification path validation
mechanism <br>
described in section 6 that omit revocation checking provide less
assurance <br>
than those that support it.<br>
<br>
Denis: The reality is the following: if you want assurance then you
MUST <br>
perform revocation. If you do not want assurance or want less assurance
<br>
then you may do whatever tests you want: the less tests, the lower the <br>
assurance.<br>
<br>
RFC 3647, section 4.4.9 bullet 6 implies that revocation checking is <br>
optional:<br>
<br>
* The mechanisms, if any, that a relying party may use or must use in
order <br>
to check the status of certificates on which they wish to rely;<br>
<br>
Denis: A rewriting is anyway necessary. There is a major difference
between <br>
simply saying "OPTIONAL" without any explanations and saying "no
revocation <br>
test means no assurance or little assurance".<br>
<br>
This text corresponds to the heading "4.9.6 Revocation checking
requirement <br>
for relying parties" in the suggested outline.<br>
<br>
<br>
6. It should be remembered that RFC 3379 makes the separation between
DPV<br>
and DPD, while this document defines a single protocol for both of them.<br>
At the minimum the document should be profiled so that implementers may<br>
choose to support only DPV and not be forced to support also DPD.<br>
<br>
Tim: We will change section 3.2.2 so that DPV servers need not support
the <br>
id-stc-build-pkc-path check. <br>
<br>
Conforming SCVP server implementations that support delegated path <br>
discovery (DPD) as defined in [RQMTS] MUST support the id-stc-build-pkc-<br>
path check. <br>
<br>
We will change section 3.2.3 to clearly delineate the wantBacks that
must <br>
be supported by DPD and DPV server implementations.<br>
<br>
Denis: this would not be sufficient. If someone is interested in DPV
only, <br>
how will it be possible to easily know what to implement or not ? Are
you <br>
going to provide a table which provide only the necessary options ?<br>
<br>
All conforming SCVP server implementations MUST support the
id-swb-pkc-cert <br>
and id-swb-pkc-public-key-info wantBacks.<br>
<br>
Conforming SCVP server implementations that support delegated path <br>
discovery (DPD) as defined in [RQMTS] MUST support the id-swb-pkc-best-<br>
cert-path and id-swb-pkc-revocation-info wantBacks.<br>
<br>
Conforming SCVP server implementations that support delegated path <br>
validation (DPV) as defined in [RQMTS] MUST support the id-swb-pkc-cert-<br>
status wantBack.<br>
<br>
Denis: Would this summarize all the differences ? I guess the answer is
no.<br>
<br>
<br>
7. "SCVP" is a not a good name when the request is to only build a<br>
certification path - with or without revocation status (i.e. DPD,
leaving<br>
the validation to the client). The certificate is not VALIDATED by the<br>
server, and even if it would, the client would not trust it. If someone<br>
says : "I support SCVP", how could it make clear that it only supports<br>
the DPV variant of it ?<br>
<br>
Better names would be:<br>
<br>
&nbsp;- DPVP: Delegated Path Validation Protocol, and<br>
&nbsp;- DPDP: Delegated Path Discovery Protocol.<br>
<br>
Tim: Regardless of the mode (DPD vs. DPV) the goal is to simplify <br>
certificate validation.&nbsp; In one case we offload path discovery and
perform <br>
validation locally.&nbsp; In the second case, both processes are offloaded
to <br>
the server.<br>
<br>
It is not so hard to clarify which services are supported.&nbsp; They could
say <br>
"Our DPV server (client) implements SCVP as specified in RFC WXYZ".&nbsp;&nbsp;
This <br>
is not new or too difficult.&nbsp; When ever there are optional features in
a <br>
standard, the simple statement ("I support RFC 3280/2560/whatever") is <br>
insufficient. <br>
<br>
Denis: This does not solve the issue cat all. Implementers should be
able <br>
to implement only DPV and be able to say "I am RFC XXX conformant". <br>
Currently this is not possible.<br>
<br>
<br>
8. The text correctly states on page 6: "An SCVP request needs only to<br>
contain the certificate to be validated, the referenced validation<br>
policy, and any run-time parameters for the request".<br>
<br>
It would be very beneficial to be able to have implementations that only<br>
support the above requirements for DPV, leaving the security protection<br>
(i.e. integrity) to the communication link (i.e. using TLS) and not<br>
supporting other parameters (with the exception of the above optional<br>
"target certificate specific parameters" as Wen-Cheng proposed). It is<br>
currently not straightforward to derive from the current document a<br>
profile for this.<br>
<br>
It is suggested to revise the document so that this goal can be achieved<br>
and that conformance clauses are added to be able to say that a given<br>
implementation is conformant to this aspect only.<br>
<br>
Additional comments (up to page 8 only) follow.<br>
<br>
Tim: Are you suggesting that userPolicySet and trustAnchors fields of
the <br>
request should be optional to support?<br>
<br>
Denis: I am suggesting something different. In fact, for every
trustAnchor, <br>
the userPolicySet parameter may be different. In the proposal they are
both <br>
"hidden" under the validation policy, so the complexity is not visible
from <br>
the client side.<br>
<br>
Tim: It is certainly possible to draft a useful profile of SCVP that
does <br>
not make use of all the mandatory to support features.&nbsp; (For example,
David <br>
Cooper has drafted a profile for the FPKI that does not require the use
of <br>
several of the mandatory to implement features, including these two <br>
fields.)&nbsp; However, in many environments it may be preferable to have
the <br>
client specify these values rather than attempting to define a separate
<br>
validation policy for every possible combination that may be needed for
<br>
every relying party for every application.<br>
<br>
Denis: While for DPD the client may want to specify these values and
work <br>
Trust Anchor by Trust Anchor (as you may easily guess, I am not
interested <br>
in DPD due to its complexity), this is not the case for DPV where the <br>
client simply wants to specify a validation policy and MAY want in
addition <br>
to specify some specific "certificate target parameters", IF they are
not <br>
already specified in the validation policy.<br>
<br>
This is simple. Default parameters on the server side that could be
changed <br>
by the client would add complexity.<br>
<br>
This would mean that the client would only be allowed to specify in its
<br>
request parameters that the server is able to process under the
specified <br>
validation policy.<br>
<br>
As already said, there a interest to be able to separate the parameters
<br>
which relate to the algorithm described in section 6.2 of RFC 3280 (I
did <br>
say 6.2, not 6.1) from the parameters which relate to the test to be <br>
accomplished on the target certificate.<br>
<br>
However they are both parameters from the validation policy.<br>
<br>
We could define in this specification (but we do not need to) some
useful <br>
set of parameters that could be used by specific validation policies.<br>
<br>
We could also define in this specification (but we do not need to) some
<br>
useful validation policies.<br>
<br>
Separating the section to define these specific validation policies
would <br>
also add clarity. <br>
<br>
ValidationPolicy ::= SEQUENCE { <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; valPolicyId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT IDENTIFIER, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; parameters&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ANY DEFINED BY valPolicyId OPTIONAL } <br>
<br>
A nice structure to import for certification path validation would be:<br>
<br>
CertificationPathValidationParameters ::= <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SEQUENCE OF BasicPathVvalidationParameters<br>
<br>
with :<br>
<br>
BasicPathVvalidationParameters ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; trustAnchor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TrustAnchor,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; userPolicySet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [1] SEQUENCE SIZE (1..MAX) OF <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT IDENTIFIER OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; inhibitPolicyMapping&nbsp; [2] BOOLEAN OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; requireExplicitPolicy [3] BOOLEAN OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; inhibitAnyPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [4] BOOLEAN OPTIONAL }<br>
<br>
A nice structure to import for the target certificate properties would
be:<br>
<br>
CertificateTargetParameters ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; keyUsages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [0] KeyUsages OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; extendedKeyUsages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [1] SEQUENCE OF KeyPurposeId OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nameValidationAlgParms&nbsp;&nbsp; [2] NameValidationAlgParms OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; otherTests&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [3] OtherTests OPTIONAL }<br>
<br>
<br>
9. Page 5. Section 1. Second paragraph. The text states:<br>
<br>
&nbsp;&nbsp; The first class of applications wants just two things: confirmation<br>
&nbsp;&nbsp; that the public key belongs to the identity named in the certificate<br>
&nbsp;&nbsp; and confirmation that the public key can be used for the intended<br>
&nbsp;&nbsp; purpose.<br>
<br>
This is not the main goal. Rephrase as:<br>
<br>
&nbsp;&nbsp; The first class of applications wants just confirmation<br>
&nbsp;&nbsp; that the certificate is valid according a given validation policy.<br>
<br>
Tim: Your text implies that validating the certificate is the ultimate <br>
goal.&nbsp; The current text indicates that validating the certificate is a <br>
necessary step towards achieving the goal - to use the key in a
certificate <br>
for an intended purpose.&nbsp; Your text is simpler, but I don't think it
gets <br>
to the heart of the matter.<br>
<br>
Denis: It does, since the validation policy MAY mandate that the key in
the <br>
target certificate is for an intended purpose.<br>
<br>
<br>
10. Page 5. Section 1. Second paragraph. The text states:<br>
<br>
&nbsp;&nbsp; The second class of applications can perform certification path<br>
&nbsp;&nbsp; validation, but they lack a reliable or efficient method of<br>
&nbsp;&nbsp; constructing a valid certification path.<br>
<br>
Rephrase as:<br>
<br>
&nbsp;&nbsp; The second class of applications can perform certification path<br>
&nbsp;&nbsp; validation, but they lack a reliable or efficient method of<br>
&nbsp;&nbsp; constructing a valid certification path and the associated<br>
&nbsp;&nbsp; revocation status information.<br>
<br>
Tim: Clients may wish to retrieve status information directly to ensure
<br>
freshness.&nbsp; It is simple to retrieve status information if the certs <br>
contain CDPs or AIAs that point to OCSP servers.<br>
<br>
Given that this is introductory information, I believe the current text
is <br>
acceptable.<br>
<br>
Denis: If you keep the sentence as it is, then it means that DPD
clients do <br>
not care for revocation checking. If so, remove all parameters for <br>
revocation checking in the case of DPD.<br>
<br>
<br>
11. Page 5. Section 1.1. Second paragraph.<br>
<br>
&nbsp;&nbsp; The primary goals of SCVP are to make it easier to deploy PKI-enabled<br>
&nbsp;&nbsp; applications and to allow central administration of PKI policies<br>
&nbsp;&nbsp; within an organization.<br>
<br>
Rephrase as:<br>
<br>
&nbsp;&nbsp; The primary goals of SCVP are to make it easier to deploy PKI-enabled<br>
&nbsp;&nbsp; applications and to allow a server to support one or more validation<br>
&nbsp;&nbsp; policies against which certificates can be tested by applications.<br>
<br>
Tim: First, central management of policies is a goal noted in 3379, so
I <br>
wouldn't want to delete it.<br>
<br>
How about:<br>
<br>
&nbsp;&nbsp; The primary goals of SCVP are to make it easier to deploy PKI-enabled<br>
&nbsp;&nbsp; applications by delegating path discovery and/or validation
processing<br>
&nbsp;&nbsp; to a server, and to allow central administration of validation
policies<br>
&nbsp;&nbsp; within an organization.<br>
<br>
Denis: This is a good compromise.<br>
<br>
<br>
12. Page 5. Section 1.1. Second paragraph.<br>
<br>
&nbsp;&nbsp; SCVP can be used by clients that do much of<br>
&nbsp;&nbsp; the certificate processing themselves but simply want an untrusted<br>
&nbsp;&nbsp; server to collect information for them.&nbsp; However, when the client has<br>
&nbsp;&nbsp; complete trust in the SCVP server, SCVP can be used to delegate the<br>
&nbsp;&nbsp; work of certification path construction and validation, and SCVP can<br>
&nbsp;&nbsp; be used to ensure that policies are consistently enforced throughout<br>
&nbsp;&nbsp; an organization.<br>
<br>
Rephrase as:<br>
<br>
&nbsp;&nbsp; SCVP, used for DPV, can be used by clients that have complete trust<br>
&nbsp;&nbsp; in a trusted DPV server. In such a case, the protocol can be used to<br>
&nbsp;&nbsp; delegate the work of certification path construction and validation.<br>
<br>
&nbsp;&nbsp; SCVP, used for DPD, can be used by clients that do much of<br>
&nbsp;&nbsp; the certificate processing themselves but simply want an untrusted<br>
&nbsp;&nbsp; DPD server to collect information for them.<br>
<br>
<br>
This is just a repeat of the introductory text in Section 1 above.&nbsp; We
have <br>
already introduced the concepts, and there is no reason to assume that
all <br>
servers fit into a single category.&nbsp; A DPV server might handle DPD
requests <br>
as well.<br>
<br>
Since the current text is accurate let's leave it as is.<br>
<br>
Denis: No. A DPV server handles DPV requests while a DP server handles
DPD <br>
requests. The same machine (not the same server) may do both. This
notion <br>
is fundamental so that the two services can be separated.<br>
<br>
This notion of separation goes well beyond these sentences ands should
be <br>
reflected within the document. I would like that we use two different
ports <br>
to address the requests: one for DPV and one for DPD. Once again, one
goal <br>
is to be able to only have a DPV compliant server.<br>
<br>
Denis<br>
<br>
<br>
<!--[endif]--><o:p></o:p></span></p>
</body>
</html>

From: [email-masked]
Date: Thu, 17 Mar 2005 17:23:17 EST
Subject: Fwd: RFC 3647 - CP vs CPS
To: [email-masked]
Sender: [email-masked]

--part1_f5.4d70731b.2f6b5d55_boundary
Content-Type: multipart/alternative;
	boundary="-----------------------------1111098197"

-------------------------------1111098197
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Santosh, thanks for your great response. This means that there can be a CPS 
without CP  Your comments about cross-certification make sense. If there is no 
cross certification requirement, then it appears that the policies would be 
included as part of the CPS.

Also, while the RFC talks about CP's usage for cross-certification, it doesnt 
state that a CPS alone can be sufficient in such cases (as far as I can 
tell)...

-------------------------------1111098197
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<META charset=3DUS-ASCII http-equiv=3DContent-Type content=3D"text/html; cha=
rset=3DUS-ASCII">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; BACKGROUND-COLOR: #fffff=
f">
<DIV>Santosh, thanks for your great response. This means that there can be a=
 CPS without CP&nbsp; Your comments about cross-certification make sense. If=
 there is no cross certification requirement, then it appears that the polic=
ies would be included as part of the CPS.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Also, while the RFC talks about CP's usage for cross-certification, it=20=
doesnt state that a CPS alone can be sufficient in such cases (as far as I c=
an tell)...</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

-------------------------------1111098197--

--part1_f5.4d70731b.2f6b5d55_boundary
Content-Type: message/rfc822
Content-Disposition: inline

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC 3647 - CP vs CPS
Date: Thu, 17 Mar 2005 13:34:13 -0500
Importance: Normal
Sender: [email-masked]

------=_NextPart_000_005D_01C52AF6.056FC6A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

You should always have a CPS so that your procedures are detailed.  The CPS
can also provide a baseline to audit against.  You may be able to use the
sections of the CPS for relying parties and subscribers.
=20
Whether you need a CP as well and OID (OID can be assigned based on CPS
alone) depends on whether you plan to cross certify and whether the cross
certifying party is willing to perform policy mapping based on the CPS or
not.   Same question you need to ask yourself.  Will you be able to use your
procedures and perform mapping to some one else's CP which is at
requirement/what level and not at procedures level.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kazin, Joel
Sent: Thursday, March 17, 2005 9:14 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: RFC 3647 - CP vs CPS

No you don't need a CP and CPS if you have a single issuing CA with a self
signed root certificate as your PKI.  Section 3.7 describes a Set of
Provisions as "A set of provisions is a collection of practice and/or policy
statements, spanning a range of standard topics for use in expressing a CP
or CPS employing the approach described in this framework ..."  Just call
your document a Set of Provisions (SoP). However, unless your PKI is small
and does not need to be very secure, I wouldn't use just a single CA in a
PKI.  A off-line self signed root and a Issuing CA is a more suitable
design. Typically, you would have three documents the SoP for the Root, a CP
and CPS for the Issuing CA.     =20

At 07:41 AM 3/17/2005 -0600, [email-masked] wrote:

The RFC outlines the various aspects of CP vs CPS. For a self-signed CA
signing and issuing certificates,  is there a need for both documents, or
one document outlining both policies and practices would suffice?=20
=20
I have checked RFC 3647 - specifically Sections 3.4, 3.5 and 3.6. It does
not directly address this approach. It talks of a CPS summary and of having
combined Subscriber and RP Agreements.
=20
Are there any examples some one is aware of where a single document has been
used?
=20
Thanks in advance,
=20
Vijay
=20
Vijay Ahuja Ph.D.
President
Cipher Solutions, Inc.
[email-masked]
O: 919 848 3040
C: 919 349 0549
www.CipherSolutions.com <http://www.ciphersolutions.com/>=20
Suite C, 6070 Six Forks Road
Raleigh NC 27609
"Security is our Passion"

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 <http://www.atosorigin.com/>=20

------=_NextPart_000_005D_01C52AF6.056FC6A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2604" name=3DGENERATOR></HEAD>
<BODY>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN  class=3D6851=
22918-17032005>You should always have a CPS so that your procedures=20
are detailed.&nbsp; The CPS can also provide a baseline to audit against.&nb=
sp;=20
You may be able to use the sections of the CPS for relying parties and=20
subscribers.</SPAN></FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN  class=3D6851=
22918-17032005></SPAN></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN  class=3D6851=
22918-17032005>Whether you need a CP as well and OID (OID can be=20
assigned based on CPS alone) depends on whether you plan to cross certify an=
d=20
whether the cross certifying party is willing to perform policy mapping base=
d on=20
the CPS or not.&nbsp;&nbsp; Same question you need to ask yourself.&nbsp; Wi=
ll=20
you be able to use your procedures and perform mapping to some one else's CP=
=20
which is at requirement/what level and not at procedures=20
level.</SPAN></FONT></STRONG></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft><FON=
T    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] <B>On=20
  Behalf Of </B>Kazin, Joel<BR><B>Sent:</B> Thursday, March 17, 2005 9:14=20
  AM<BR><B>To:</B> [email-masked]; [email-masked]<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> Re: RFC 3647 - CP vs=20
  CPS<BR><BR></FONT></DIV>No you don't need a CP and CPS if you have a singl=
e=20
  issuing CA with a self signed root certificate as your PKI.&nbsp; Section=20=
3.7=20
  describes a Set of Provisions as "A set of provisions is a collection of=20
  practice and/or policy statements, spanning a range of standard topics for=
 use=20
  in expressing a CP or CPS employing the approach described in this framewo=
rk=20
  ..."&nbsp; Just call your document a Set of Provisions (SoP). However, unl=
ess=20
  your PKI is small and does not need to be very secure, I wouldn't use just=
 a=20
  single CA in a PKI.&nbsp; A off-line self signed root and a Issuing CA is=20=
a=20
  more suitable design. Typically, you would have three documents the SoP fo=
r=20
  the Root, a CP and CPS for the Issuing CA.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  <BR><BR><BR>At 07:41 AM 3/17/2005 -0600, [email-masked] wrote:<BR>
  <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite">The RFC outlines the vari=
ous=20
    aspects of CP vs CPS. For a self-signed CA signing and issuing=20
    certificates,&nbsp; is there a need for both documents, or one document=20
    outlining both policies and practices would suffice? <BR>&nbsp;<BR>I hav=
e=20
    checked RFC 3647 - specifically Sections 3.4, 3.5 and 3.6. It does not=20
    directly address this approach. It talks of a CPS summary and of having=20
    combined Subscriber and RP Agreements.<BR>&nbsp;<BR>Are there any exampl=
es=20
    some one is aware of where a single document has been=20
    used?<BR>&nbsp;<BR>Thanks in advance,<BR>&nbsp;<BR>Vijay<BR>&nbsp;<BR><F=
ONT      face=3Darial size=3D2>Vijay Ahuja Ph.D.<BR>President<BR>Cipher Solu=
tions,=20
    Inc.<BR>[email-masked]<BR>O: 919 848 3040<BR>C: 919 349=20
    0549<BR><A      href=3D"http://www.ciphersolutions.com/">www.CipherSolut=
ions.com</A><BR>Suite=20
    C, 6070 Six Forks Road<BR>Raleigh NC 27609<BR><B><I>"Security is our=20
    Passion"</I></B></FONT></BLOCKQUOTE><X-SIGSEP>
  <P></X-SIGSEP><BR>Joel S. Kazin CPA, CISA, CISSP, CISM<BR>Senior=20
  Consultant<BR>Atos Origin<BR>40 Old Sleepy Hollow Road<BR>Pleasantville, N=
ew=20
  York 10570-3802<BR>USA<BR>Phone&nbsp; +1 914-769-8780<BR>Mobile&nbsp; +1=20
  914-564-1484<BR>email<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB>=20
  [email-masked]<BR><A href=3D"http://www.atosorigin.com/"    eud=
ora=3D"autourl">www.atosorigin.com<BR></A></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_005D_01C52AF6.056FC6A0--

--part1_f5.4d70731b.2f6b5d55_boundary--

To: "Sean P. Turner" <[email-masked]>
Cc: PKIX <[email-masked]>
Subject: Re: RFC 3279: ECDSA and ECDH keyUsage Text
From: Daniel Brown <[email-masked]>
Date: Thu, 17 Mar 2005 16:31:28 -0500
Sender: [email-masked]

Sean P. Turner wrote on 03/17/2005 03:13:14 PM:

> 
> I'm a little confused by the keyUsage paragraphs (3.2.5) in RFC 3279. 
> It seems like the current text on applies to CAs and CRL issuers.  I 
> believe the text needs to be modified as follows to address end 
entities:
> 
> replace (before the list of digitalSignature, nonRepudiation, and 
> keyAgreement) "If the keyUsage extension is present in a CA or CRL 
> issuer certificate" with "If the keyUsage extension is present in an end 

> entity certificate."
> 
> and
> 
> replace (before the list of digitalSignature, nonRepudiation, 
> keyAgreement, keyCertSign, and cRLSign) "If the keyUsage extension is 
> present in a CA certificate" with "If the keyUsage extension is present 
> in a CA or CRL issuer certificate."

These replacements seem reasonable.

> 
> I think this was just a cut and paste error.  Sorry for the spam if 
> somebody else already caught this.
> 
> spt
> 

Date: Thu, 17 Mar 2005 15:13:14 -0500
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: PKIX <[email-masked]>
Subject: RFC 3279: ECDSA and ECDH keyUsage Text
Sender: [email-masked]

I'm a little confused by the keyUsage paragraphs (3.2.5) in RFC 3279.  
It seems like the current text on applies to CAs and CRL issuers.  I 
believe the text needs to be modified as follows to address end entities:

replace (before the list of digitalSignature, nonRepudiation, and 
keyAgreement) "If the keyUsage extension is present in a CA or CRL 
issuer certificate" with "If the keyUsage extension is present in an end 
entity certificate."

and

replace (before the list of digitalSignature, nonRepudiation, 
keyAgreement, keyCertSign, and cRLSign) "If the keyUsage extension is 
present in a CA certificate" with "If the keyUsage extension is present 
in a CA or CRL issuer certificate."

I think this was just a cut and paste error.  Sorry for the spam if 
somebody else already caught this.

spt

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: RFC 3647 - CP vs CPS
Date: Thu, 17 Mar 2005 13:34:13 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_005D_01C52AF6.056FC6A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

You should always have a CPS so that your procedures are detailed.  The =
CPS
can also provide a baseline to audit against.  You may be able to use =
the
sections of the CPS for relying parties and subscribers.
=20
Whether you need a CP as well and OID (OID can be assigned based on CPS
alone) depends on whether you plan to cross certify and whether the =
cross
certifying party is willing to perform policy mapping based on the CPS =
or
not.   Same question you need to ask yourself.  Will you be able to use =
your
procedures and perform mapping to some one else's CP which is at
requirement/what level and not at procedures level.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Kazin, Joel
Sent: Thursday, March 17, 2005 9:14 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: RFC 3647 - CP vs CPS

No you don't need a CP and CPS if you have a single issuing CA with a =
self
signed root certificate as your PKI.  Section 3.7 describes a Set of
Provisions as "A set of provisions is a collection of practice and/or =
policy
statements, spanning a range of standard topics for use in expressing a =
CP
or CPS employing the approach described in this framework ..."  Just =
call
your document a Set of Provisions (SoP). However, unless your PKI is =
small
and does not need to be very secure, I wouldn't use just a single CA in =
a
PKI.  A off-line self signed root and a Issuing CA is a more suitable
design. Typically, you would have three documents the SoP for the Root, =
a CP
and CPS for the Issuing CA.     =20

At 07:41 AM 3/17/2005 -0600, [email-masked] wrote:

The RFC outlines the various aspects of CP vs CPS. For a self-signed CA
signing and issuing certificates,  is there a need for both documents, =
or
one document outlining both policies and practices would suffice?=20
=20
I have checked RFC 3647 - specifically Sections 3.4, 3.5 and 3.6. It =
does
not directly address this approach. It talks of a CPS summary and of =
having
combined Subscriber and RP Agreements.
=20
Are there any examples some one is aware of where a single document has =
been
used?
=20
Thanks in advance,
=20
Vijay
=20
Vijay Ahuja Ph.D.
President
Cipher Solutions, Inc.
[email-masked]
O: 919 848 3040
C: 919 349 0549
www.CipherSolutions.com <http://www.ciphersolutions.com/>=20
Suite C, 6070 Six Forks Road
Raleigh NC 27609
"Security is our Passion"

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 <http://www.atosorigin.com/>=20

------=_NextPart_000_005D_01C52AF6.056FC6A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2604" name=3DGENERATOR></HEAD>
<BODY>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D685122918-17032005>You should always have a CPS so that your =
procedures=20
are detailed.&nbsp; The CPS can also provide a baseline to audit =
against.&nbsp;=20
You may be able to use the sections of the CPS for relying parties and=20
subscribers.</SPAN></FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D685122918-17032005></SPAN></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D685122918-17032005>Whether you need a CP as well and OID (OID =
can be=20
assigned based on CPS alone) depends on whether you plan to cross =
certify and=20
whether the cross certifying party is willing to perform policy mapping =
based on=20
the CPS or not.&nbsp;&nbsp; Same question you need to ask =
yourself.&nbsp; Will=20
you be able to use your procedures and perform mapping to some one =
else's CP=20
which is at requirement/what level and not at procedures=20
level.</SPAN></FONT></STRONG></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Kazin, Joel<BR><B>Sent:</B> Thursday, March 17, 2005 =
9:14=20
  AM<BR><B>To:</B> [email-masked]; [email-masked]<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> Re: RFC 3647 - CP vs=20
  CPS<BR><BR></FONT></DIV>No you don't need a CP and CPS if you have a =
single=20
  issuing CA with a self signed root certificate as your PKI.&nbsp; =
Section 3.7=20
  describes a Set of Provisions as "A set of provisions is a collection =
of=20
  practice and/or policy statements, spanning a range of standard topics =
for use=20
  in expressing a CP or CPS employing the approach described in this =
framework=20
  ..."&nbsp; Just call your document a Set of Provisions (SoP). However, =
unless=20
  your PKI is small and does not need to be very secure, I wouldn't use =
just a=20
  single CA in a PKI.&nbsp; A off-line self signed root and a Issuing CA =
is a=20
  more suitable design. Typically, you would have three documents the =
SoP for=20
  the Root, a CP and CPS for the Issuing =
CA.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  <BR><BR><BR>At 07:41 AM 3/17/2005 -0600, [email-masked] wrote:<BR>
  <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite">The RFC outlines the =
various=20
    aspects of CP vs CPS. For a self-signed CA signing and issuing=20
    certificates,&nbsp; is there a need for both documents, or one =
document=20
    outlining both policies and practices would suffice? <BR>&nbsp;<BR>I =
have=20
    checked RFC 3647 - specifically Sections 3.4, 3.5 and 3.6. It does =
not=20
    directly address this approach. It talks of a CPS summary and of =
having=20
    combined Subscriber and RP Agreements.<BR>&nbsp;<BR>Are there any =
examples=20
    some one is aware of where a single document has been=20
    used?<BR>&nbsp;<BR>Thanks in =
advance,<BR>&nbsp;<BR>Vijay<BR>&nbsp;<BR><FONT=20
    face=3Darial size=3D2>Vijay Ahuja Ph.D.<BR>President<BR>Cipher =
Solutions,=20
    Inc.<BR>[email-masked]<BR>O: 919 848 3040<BR>C: 919 349=20
    0549<BR><A=20
    =
href=3D"http://www.ciphersolutions.com/">www.CipherSolutions.com</A><BR>S=
uite=20
    C, 6070 Six Forks Road<BR>Raleigh NC 27609<BR><B><I>"Security is our =

    Passion"</I></B></FONT></BLOCKQUOTE><X-SIGSEP>
  <P></X-SIGSEP><BR>Joel S. Kazin CPA, CISA, CISSP, CISM<BR>Senior=20
  Consultant<BR>Atos Origin<BR>40 Old Sleepy Hollow =
Road<BR>Pleasantville, New=20
  York 10570-3802<BR>USA<BR>Phone&nbsp; +1 914-769-8780<BR>Mobile&nbsp; =
+1=20
  914-564-1484<BR>email<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB>=20
  [email-masked]<BR><A href=3D"http://www.atosorigin.com/"=20
  =
eudora=3D"autourl">www.atosorigin.com<BR></A></P></BLOCKQUOTE></BODY></HT=
ML>

------=_NextPart_000_005D_01C52AF6.056FC6A0--

From: "Kazin, Joel" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RFC 3647 - CP vs CPS
Date: Thu, 17 Mar 2005 08:13:43 -0600
Sender: [email-masked]

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

------_=_NextPart_001_01C52AFB.5A59C47C
Content-Type: text/plain;
	charset="iso-8859-1"

No you don't need a CP and CPS if you have a single issuing CA with a self
signed root certificate as your PKI.  Section 3.7 describes a Set of
Provisions as "A set of provisions is a collection of practice and/or policy
statements, spanning a range of standard topics for use in expressing a CP
or CPS employing the approach described in this framework ..."  Just call
your document a Set of Provisions (SoP). However, unless your PKI is small
and does not need to be very secure, I wouldn't use just a single CA in a
PKI.  A off-line self signed root and a Issuing CA is a more suitable
design. Typically, you would have three documents the SoP for the Root, a CP
and CPS for the Issuing CA.      

At 07:41 AM 3/17/2005 -0600, [email-masked] wrote:

The RFC outlines the various aspects of CP vs CPS. For a self-signed CA
signing and issuing certificates,  is there a need for both documents, or
one document outlining both policies and practices would suffice? 
 
I have checked RFC 3647 - specifically Sections 3.4, 3.5 and 3.6. It does
not directly address this approach. It talks of a CPS summary and of having
combined Subscriber and RP Agreements.
 
Are there any examples some one is aware of where a single document has been
used?
 
Thanks in advance,
 
Vijay
 
Vijay Ahuja Ph.D.
President
Cipher Solutions, Inc.
[email-masked]
O: 919 848 3040
C: 919 349 0549
www.CipherSolutions.com <http://www.ciphersolutions.com/> 
Suite C, 6070 Six Forks Road
Raleigh NC 27609
"Security is our Passion"

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 <http://www.atosorigin.com/> 

------_=_NextPart_001_01C52AFB.5A59C47C
Content-Type: text/html;
	charset="iso-8859-1"

<html>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
No you don't need a CP and CPS if you have a single issuing CA with a
self signed root certificate as your PKI.&nbsp; Section 3.7 describes a
Set of Provisions as &quot;A set of provisions is a collection of
practice and/or policy statements, spanning a range of standard topics
for use in expressing a CP or CPS employing the approach described in
this framework ...&quot;&nbsp; Just call your document a Set of
Provisions (SoP). However, unless your PKI is small and does not need to
be very secure, I wouldn't use just a single CA in a PKI.&nbsp; A
off-line self signed root and a Issuing CA is a more suitable design.
Typically, you would have three documents the SoP for the Root, a CP and
CPS for the Issuing CA.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br><br>
<br>
At 07:41 AM 3/17/2005 -0600, [email-masked] wrote:<br>
<blockquote type=cite class=cite cite>The RFC outlines the various
aspects of CP vs CPS. For a self-signed CA signing and issuing
certificates,&nbsp; is there a need for both documents, or one document
outlining both policies and practices would suffice? <br>
&nbsp;<br>
I have checked RFC 3647 - specifically Sections 3.4, 3.5 and 3.6. It does
not directly address this approach. It talks of a CPS summary and of
having combined Subscriber and RP Agreements.<br>
&nbsp;<br>
Are there any examples some one is aware of where a single document has
been used?<br>
&nbsp;<br>
Thanks in advance,<br>
&nbsp;<br>
Vijay<br>
&nbsp;<br>
<font face="arial" size=2>Vijay Ahuja Ph.D.<br>
President<br>
Cipher Solutions, Inc.<br>
[email-masked]<br>
O: 919 848 3040<br>
C: 919 349 0549<br>
<a href="http://www.ciphersolutions.com/">www.CipherSolutions.com</a><br>
Suite C, 6070 Six Forks Road<br>
Raleigh NC 27609<br>
<b><i>&quot;Security is our Passion&quot;</i></b></font></blockquote>
<x-sigsep><p></x-sigsep>
<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<x-tab>&nbsp;&nbsp;&nbsp;</x-tab> [email-masked]<br>
<a href="http://www.atosorigin.com/" eudora="autourl">www.atosorigin.com<br>
</a></html>

------_=_NextPart_001_01C52AFB.5A59C47C--

From: [email-masked]
Date: Thu, 17 Mar 2005 08:41:20 EST
Subject: RFC 3647 - CP vs CPS
To: [email-masked]
CC: [email-masked]
Sender: [email-masked]

-------------------------------1111066880
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

The RFC outlines the various aspects of CP vs CPS. For a self-signed CA 
signing and issuing certificates,  is there a need for both documents, or one 
document outlining both policies and practices would suffice? 

I have checked RFC 3647 - specifically Sections 3.4, 3.5 and 3.6. It does not 
directly address this approach. It talks of a CPS summary and of having 
combined Subscriber and RP Agreements.

Are there any examples some one is aware of where a single document has been 
used?

Thanks in advance,

Vijay

Vijay Ahuja Ph.D.
President
Cipher Solutions, Inc.
[email-masked]
O: 919 848 3040
C: 919 349 0549
www.CipherSolutions.com
Suite C, 6070 Six Forks Road
Raleigh NC 27609
"Security is our Passion"

-------------------------------1111066880
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<META charset=3DUS-ASCII http-equiv=3DContent-Type content=3D"text/html; cha=
rset=3DUS-ASCII">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; BACKGROUND-COLOR: #fffff=
f">
<DIV>The RFC outlines the various aspects of CP vs CPS. For a self-signed CA=
 signing and issuing&nbsp;certificates,&nbsp; is there a need for both docum=
ents, or one document outlining both policies and practices would suffice? <=
/DIV>
<DIV>&nbsp;</DIV>
<DIV>I have checked RFC 3647 - specifically Sections 3.4, 3.5 and 3.6. It do=
es not directly address this approach. It talks of a CPS summary and of havi=
ng combined Subscriber and RP Agreements.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Are there any examples some one is aware of where a single document has=
 been used?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks in advance,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Vijay</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT lang=3D0 face=3DArial size=3D2 FAMILY=3D"SANSSERIF" PTSIZE=3D"10"=
>Vijay Ahuja Ph.D.<BR>President<BR>Cipher Solutions, Inc.<BR>vijay@CipherSol=
utions.com<BR>O: 919 848 3040<BR>C: 919 349 0549<BR><A href=3D"http://www.ci=
phersolutions.com/">www.CipherSolutions.com</A><BR>Suite C, 6070 Six Forks R=
oad<BR>Raleigh NC 27609<BR><B><I>"Security is our Passion"</B></I></FONT></D=
IV></BODY></HTML>

-------------------------------1111066880--

From: "Carey Gray" <[email-masked]>
To: "Owner-ietf-fax" <[email-masked]>
Subject: Want to get the rollax you've dreamt of? curbside
Date: Tue, 15 Mar 2005 08:49:14 -0700

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

Hello. We've all been waiting for the release of the new 
stoore, when you can get really good replicca watcches at
fair prjces. 
http://allotting.seikos.net/r/erika/cress

Our main motto is why not to give you the stuff you need
if we can do it? Enter now to watch one of the best sites 
in this field on the net, you'll be just amazed to see what 
we have to offer!

http://allotting.seikos.net/r/erika/cress 
Take me now

http://allotting.seikos.net/r.php - nah  compunction
areawide anthem corrodible chickweed award annuli. adieu az allis air bert. computation callahan bogeymen chaperon anticipate. 
crowberry benedictine chute. botany ascetic chaos bowdoin. bela contemplate backscatter breadboard age betrothal. 
barb commentary anastigmatic adelaide accra bongo. avid associable complementarity coplanar. china curio absorptive corruption abernathy apollonian. 
arouse barley benedictine cacm amber. beckon coxcomb arabesque cheyenne adrian. afterlife bouquet coventry bremsstrahlung acquaint. 
anagram cattle crank convoke biharmonic abo. ariadne afoot brandenburg cyrus. benjamin blackmail blame bon bator. 
ammonia abnormal bemuse cigarette anderson. cowbird cogent alexei. 

----wgtj53055rvmlps--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc2511bis-09.txt
Date: Tue, 15 Mar 2005 10:13:05 -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 
			  Request Message Format (CRMF)
	Author(s)	: J. Schaad
	Filename	: draft-ietf-pkix-rfc2511bis-09.txt
	Pages		: 33
	Date		: 2005-3-11
	
This document describes the Certificate Request Message Format (CRMF) 
   syntax and semantics.  This syntax is used to convey a request for a 
   certificate to a Certification Authority (CA), possibly via a 
   Registration Authority (RA), for the purposes of X.509 certificate 
   production.  The request will typically include a public key and 
   associated registration information.  This document does not define a 
   certificate request protocol

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

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

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

--OtherAccess--

--NextPart--

Date: Fri, 11 Mar 2005 10:15:52 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft meeting minutes
Sender: [email-masked]

Folks,

Here is the first draft of the meeting minutes. Please get 
comments/corrections to me by 3/21.

Thanks,

Steve
------

PKIX WG Meeting 3/8/05

Edited by Steve Kent

Chairs: Stephen Kent <[email-masked]> & Tim Polk <[email-masked]>

The PKIX WG met once during the 62nd IETF. A total of approximately 
45 individuals participated in the meeting.

Document status - Tim Polk (NIST)
	Five documents in RFC Editor's queue. One document just 
approved by IESG, several more in the IESG queue for review & 
approval. Several documents stalled.

PKIX WG Document Presentations

Simple Certificate Validation Protocol (SCVP) - David Cooper (NIST)
	Significant progress has been made towards rough consensus 
through the two drafts submitted since the last meeting. These drafts 
represent been submitted with significant enhancements. At this stage 
(rev 18) the editors are trying to determine if the remaining 
comments suggesting changes have wide support and thus need to be 
accommodated. David noted some confusion re the semantics of the 
default validation policy part of the spec, which needs to be 
discussed on the list to resolve some ambiguities. Several "sense of 
the room" polls were taken, but the questions will be brought to the 
list for resolution.

3280bis - David Cooper (NIST)
	A design team met in January to develop a -00 draft from a 
issues list complied from PKIX mail messages and mail to the RFC 3280 
editors.  Draft -00 incorporates a number of clarifications and small 
changes designed to align with ISO and remove ambiguities, and a new 
section on comparing internationalized names. See the next 
presentation for details on internationalization of names. A question 
was raised as to whether this document should be used by an 
application to guide name matching rules, if the application makes 
use of a name from a certificate to make an access control decision 
or analogous determination. To first order, this document addresses 
matching rules only for name comparisons relative to path validation, 
e.g., for certificate chaining and for applications of name 
constraints.

UTF8String Deployment and Migration - Akira Kanaoka (Secom/JNSA PKI 
Challenge Project)
       This presentation reported on feedback received from a 
questionnaire on UTF8String deployment in Asia, i.e., to determine 
the extent to which CAs in Asia followed the RFC 3280 guidance on 
this topic, guidance that was rescinded in 3280bis! The survey was 
sent to Asia PKI Forum members in 9 countries, but got replies from 
11 CAs in 3 only countries. All of the CAs that replied were 
government-funded, not private CAs. Responses indicate that most CAs 
use UTF8 when they need to represent names in other than their local 
character set. Another survey looked at MS Windows root certificate 
stores, as a measure of commercial CA migration, and here none of the 
root CAs had UTF8 encodings! Given the commercial CA situation, need 
a migration plan. Suggestion is to create an individual submission, 
Informational RFC to describe whatever migration strategy is 
developed, test cases, etc.

CRL Signer Certificates and AIA - Stefan Santesson (Microsoft)
	Draft -00 of this new PKIX document was published after the 
last meeting. There has been moderate discussion on the list about 
this draft. About 5 major issues were identified. Responses have been 
proposed for each issue and, where appropriate, will be reflected in 
the next draft. One issue (choice of recommended referral methods) 
still remains, and will be addressed on the list.

Update on CRMF, CMC documents - Jim Schaad (Soaring Hawk)
       This presentation reviewed the state of several related drafts 
and highlight the controversies that remain. CRMF was forwarded to 
the RFC editor a bit earlier that Jim had anticipated. Two OID 
assignments need to be changed, and the plan is to use the 48-hour 
author's review period to make these changes, after confirmation on 
the WG list. CMC-based and transport documents are ready, will go out 
soon. CMC compliance document will go out very soon. CMC archive has 
one issue to be resolved, dealing with packaging of multiple keys 
retrieved from an escrow agent. Nonetheless, this document also will 
be republished and ready for last call very shortly.

Related Specifications & Liaison Presentations

LDAP schema definitions - Kurt Zeilenga (OpenLDAP)
	The author of this individual submission has requested that 
the WG review and comment upon this draft.  He intends to make a 
decision by the end of IETF#62 whether to recommend this revision for 
IESG consideration as a Proposed Standard. This document is intended 
to be published at the same time as the revised LDAP TS being 
developed by the LDAPBIS WG.

OCSP Data Interchange Format - John Hines (Tumbleweed)
       The presenter will be submitting an individual draft defining a 
data interchange format for OCSP servers. The presentation described 
the problems that inspired this draft and invites WG participation, 
even though the document will not be a PKIX document. The goal is to 
eventually make this a standard, and Russ Housley explained the 
procedure for doing this via the individual submission path.

Date: Thu, 10 Mar 2005 13:41:40 -0600
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: Tom Gindin <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Re: 3280bis: OtherName "health warning"
Sender: [email-masked]

I'm NOT advocating adding any othername forms to 3280bis.  I'm asking if 
we should put in a health warning that says something to the effect of 
"if you want applications to do any kind of name matching based on your 
othername field you'd better define them in your document."

spt

Tom Gindin wrote:

>        Sean:
>
>        The only OTHER-NAME form that PKIX has created, AFAIK, is 
>Permanent Identifier.  Ways of specifying matching rules inside a PI were 
>specified in earlier drafts but then taken out in the approved version. 
>However, there are still rules on matching specified for each major case 
>(assigner present and absent, identifierValue present and absent). 
>
>                Tom Gindin
>
>
>
>
>
>
>"Sean P. Turner" <[email-masked]>
>Sent by: [email-masked]
>03/09/2005 02:38 PM
> 
>        To:     PKIX <[email-masked]>
>        cc: 
>        Subject:        3280bis: OtherName "health warning"
>
>
>
>Should we add a note in the Subject Alternative Name section to say 
>something like - when an othername form is created matching rules for 
>said othername name form must also be specified?
>
>spt
>
>
>
>  
>

Date: Thu, 10 Mar 2005 14:31:07 -0500
To: Tom Gindin <[email-masked]>, "Sean P. Turner" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: 3280bis: OtherName "health warning"
Cc: PKIX <[email-masked]>
Sender: [email-masked]

OIDs have been assigned for five in the PKIX arc, but one of them has been 
deprecated.  I know that Kerberos is assigning another one.

See http://www.imc.org/ietf-pkix/pkix-oid.asn

Russ

At 07:21 AM 3/10/2005, Tom Gindin wrote:

>         Sean:
>
>         The only OTHER-NAME form that PKIX has created, AFAIK, is
>Permanent Identifier.  Ways of specifying matching rules inside a PI were
>specified in earlier drafts but then taken out in the approved version.
>However, there are still rules on matching specified for each major case
>(assigner present and absent, identifierValue present and absent).
>
>                 Tom Gindin
>
>
>
>
>
>
>"Sean P. Turner" <[email-masked]>
>Sent by: [email-masked]
>03/09/2005 02:38 PM
>
>         To:     PKIX <[email-masked]>
>         cc:
>         Subject:        3280bis: OtherName "health warning"
>
>
>
>Should we add a note in the Subject Alternative Name section to say
>something like - when an othername form is created matching rules for
>said othername name form must also be specified?
>
>spt

To: "Sean P. Turner" <[email-masked]>
Cc: PKIX <[email-masked]>
Subject: Re: 3280bis: OtherName "health warning"
From: Tom Gindin <[email-masked]>
Date: Thu, 10 Mar 2005 07:21:13 -0500
Sender: [email-masked]

        Sean:

        The only OTHER-NAME form that PKIX has created, AFAIK, is 
Permanent Identifier.  Ways of specifying matching rules inside a PI were 
specified in earlier drafts but then taken out in the approved version. 
However, there are still rules on matching specified for each major case 
(assigner present and absent, identifierValue present and absent). 

                Tom Gindin

"Sean P. Turner" <[email-masked]>
Sent by: [email-masked]
03/09/2005 02:38 PM
 
        To:     PKIX <[email-masked]>
        cc: 
        Subject:        3280bis: OtherName "health warning"

Should we add a note in the Subject Alternative Name section to say 
something like - when an othername form is created matching rules for 
said othername name form must also be specified?

spt

Reply-To: "Reva Rosado" <[email-masked]>
From: "Reva Rosado" <[email-masked]>
To: <[email-masked]>
Subject: Ackquire all the me ds you need in one place! bookie
Date: Thu, 10 Mar 2005 08:18:11 -0200

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

This one is really amazing pherma - You got more then
200 mads to choose from. Additionally, you get rock-bottom 
deeals, because we are here for you! 

Come on now! 
http://winery.czxugs.com

clip gallstone r's bosch wolves adulterous idiosyncrasy wherewithal. provocative brainstorm ark operon crematory councilman degassing peppermint waveform. 
cutout blowup pickman lampblack niche della anachronism catapult. gullible victorious bosch steve vainglorious. 
occident skywave plastisol sacred porte basilisk. climate wed crematory continuum criss metamorphosis. 
butyrate lousy patagonia haggard laminar tampon. prior sacred cease bedford agrimony. 
playhouse poland aphelion bosch blithe utterance colombo lawgiving crossbar. hyperbola nebula haggard clockwork metalliferous. devote haggard gaberones dey. kiowa crematory cockle byproduct tuba moot. withdrew drumhead haggard collie champaign. 
auger ha broach ulcerate crematory bingham chine picky. workshop default croquet crematory hash carp adrenaline. classificatory herculean bloomfield bosch cowgirl thiocyanate teleprocessing. buses beer irritate droop harpoon ingestion. depressor bloodroot bosch vicar contravariant dismissal douglass ovenbird. 

----QXQFZJ42463518TONKVAT--

From: "Wen-Cheng Wang" <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments to SCVP ID 17
Date: Thu, 10 Mar 2005 11:56:07 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

(I do not know why the ML server won't accept my email in HTML
format. Therefore, I change the format to plaintext. This is my second
try to send this email. I am sorry if you receieve this email more than
once.)

David,

When I re-read section 3.2.4.2.1, I incidentally found
the term "identity certificates" undefined. I suggest
change it to "public key certificates".

Please also read my comments to your answers below.

>David A. Cooper wrote:
>>Wen-Cheng Wang wrote:
>>Believe me, I understand the refinement relationship.
>>I simply feel that it is odd to say a "name validation
>>algorithm" is a refinement of a path validation algorithm.
>>I believe that most people will not associate path
>>validation with the term "name validation". Maybe you
>>should name it "the basic validation algorithm with
>>name checking".
>I am hesitant to change the name of the algorithm, since
>this would seem to require making changes to the ASN.1.  However,
>we can certainly re-word the first sentence of section 3.2.4.2.3
>to remove the word "refinement".

I am not sure whether the word "refinement" should be removed.
What I concern is that the name "name validation algorithm" is
misleading. At the first glance, I was under the impression that
it is an algorithm defining the string matching rules for
certificate name chaining, but finally I realized that it is
actually the basic validation algorithm supplemented with
checking the subject name of the target certificate.

>>>While name validation could have been implemented in a similar
>>>manner to the verification of keyUsage and extendedKeyUsage,
>>>specifying name validation as a different validation algorithm
>>>works just as well.  Changing the ASN.1 to group name checking
>>>with keyUsages and extendedKeyUsages would simply be a styistic
>>>change that would have no real effect on the protocol.  While Tim
>>>and I made changes to the ASN.1 to clean up the tagging since so
>>>many people insisted that they wanted the change, we really need
>>>to get this document finished, and so I think we should try to
>>>avoid making changes to the protocol that are unnecessary.
>>I still believe that it is better to group "name
>>checking", "key usage checking" and "extended key usage
>>checking" into the category of "end/target certificate
>>requirements". This is not a simply a stylistic change. It
>>is a matter of logicalness of the protocol design. However,
>>if we are really running out of time, I can live with
>>"the basic validation algorithm with name validation".
>OK.  I believe that it is very important that we get this document
>finished.  The -00 draft of SCVP was announced on June 28, 1999 and
>I know several people who are anxious to see this document completed.
>We could argue forever about the best way to format the request, but
>the changes that you propose would have no effect on the information
>that the client could send to the server or that the server could
>return to the client.  It would just shuffle the bits.

As a matter of fact, the changes I propose is not just a shuffle
of the bits. The difference is that my proposal makes "subject name
checking" orthogonal to the "path validation algorithm". It is analogy
to that the "key usage checking" is orthogonal to the "path validation
algorithm". The current SCVP draft forces that "subject name checking"
can only be appended to the "basic validation algorithm", it is
impossible to adopt a more restricted validation algorithm and perform
"subject name checking" at the same time. For example, a validation
policy might want to adopt a path validation algorithm that additionally
checks criticality flags of several certificate extensions, while the
policy might also want to perform "subject name checking". With current
SCVP draft, it is impossible to do that. Obviously, keeping them
orthogonal will provide more flexibility.

This is another advantage of my proposal, in addition to the logicalness
of the protocol design I mentioned. Therefore, please think about this
advantage before you say "no" to the changes I proposed.

Well, I have done my best to try to convince you to improve the protocol
design. If the answer is still "no", then as I said I can livewith "the
basic validation algorithm with name validation" but of course it is a
pity we have no time to improve the protocol design further.

>>>The "default validation policy" really is the default validation policy for the organiztion;
>>>it is not a "global" validation policy.
>>>
>>>Section 3.2.4.1.1 states that the default validation policy MUST use
>>>the basic validation algorithm as its default validation algorithm,
>>>but each individual SCVP server is free to set the default values for
>>>all other parameters (e.g., trust anchors) of the validation policy
>>>as it wishes.  The server specifies the default parameter values that
>>>it uses in its default validation policy in its validation policy
>>>response (in the defaultPolicyValues item).
>>Basically, I agree that the validation algorithm adopt by the server
>>MUST be based on the basic path validation algorithm defined by RFC
>>3280 or its descendant, but it is not necessary to force every
>>organization to accept that "basic path validation algorithm" as
>>the alogorithm of their organizational default validation policy. What
>>if the organization want to adopt an extended/refined version of 
>>path validation algorithm in their organizational default validation
>>policy? To allow organizations to define their own organizational
>>default validation policy, I still think it is better to name the
>>validation policy defined by the SCVP spec as "basic validation policy".
>>It is analogy to that RFC 3280 named its path validation algorithm
>>as "basic path validation algorithm" (not "default validation algorithm").
>>
>>The point is that SCVP should give freedom to organizations to
>>define their own organizational default validation policy. Nevertheless,
>>SCVP could ask organization to adopt PKIX-compliant validation
>>algorithm no mater if they define their own organizational
>>default validation policy.
>>
>>I understand that it is good if SCVP defines a validat policy and
>>its OID for the convenience of organization unwilling/unable to
>>define their own validat policy/OID. However, it should not be
>>"the default validation policy". It should simply be "a basic
>>validation policy".
>
>I would not agree to changing the name from "default validation
>policy" to "basic validation policy" since SCVP does not
>define the policy.  This is not the same as the "basic validation
>algorithm", since the "basic validation algorithm" is an actual
>algorithm.  That is, it is fully defined in SCVP.  SCVP has
>assigned an OID for the "default validation policy" but leaves
>it to each organization to define the validation policy that
>corresponds to that OID.  The only aspect of the "default validation
>policy" that SCVP defines is the "default validation algorithm".

Good clarification. How about adding this clarification to the
text? The clarification would be something like the following text:

A SCVP server MUST designate a validation policy as its default
validation policy. For alowing all SCVP clients to specify the
default validation policy of any SCVP server in an universal way,
SCVP defines the OID value id-svp-defaultValPolicy. If a SCVP
client specify the OID value id-svp-defaultValPolicy in its query,
it means that the client agrees the server to adopt its
default validation policy. Conforming implementations of SCVP
servers MUST recognize the OID value id-svp-defaultValPolicy. In
some cases, a SCVP server might assign a OID value other than
id-svp-defaultValPolicy as the reference to its default validation
policy. In other cases, a SCVP server might not assign any OID
value as the reference to its default validation policy. In any
case, once the SCVP client specify the OID value id-svp-defaultValPolicy
in its query, the SCVP server MUST perform it actions according
to its default validation policy.

Note that SCVP does not define the default validation policy
of any SCVP server. SCVP only assigns the OID value id-svp-defaultValPolicy
but leaves it to each SCVP server to define its default validation policy.

>I would have no objection to removing the requirement that the
>"default validation policy" MUST use the "basic validation algorithm" 
>as its default algorithm, but I'd need some evidence that this
>change would satisfy working group consensus.  I also think there
>would still need to be some restrictions imposed.  For example, it would
>make no sense to use the "name validation algorithm" as a default
>validation algorithm since the "name validation algorithm" requires
>a query-specific parameter.  Since the client would need to include
>the validation algorithm in its request in order to specify the
>algorithm parameter (the subject name(s) to look for), the "name
>validation algorithm" would not make an appropriate default.  A
>default validation algorithm for a validation policy should either be
>one that does not have any parameters or only has parameters for which
>reasonable default values can be defined.  The "basic validation
>algorithm" satisfies this.  I would guess that a "proxy certificate
>validation algorithm" might satisfy this requirement as well, but it
>seems very unlikely that one would want to use that as part of an
>organizational default validation policy.

I do not think it is necessary to impose the restrictions you
mentioned on the candidate of a default validation algorithm. For
example, it is quite natural for a SCVP server that only serves
IPsecVPN devices to use "the basic validation algorithm with
name validation" as the default validation algorithm of its
default validation policy, because it is important to check
whether the target certificate contains proper DNS name, IP Address,
or Email Address. In such environment, there is nothing wrong to use
"the basic validation algorithm with name validation" as the default
validation algorithm and require the SCVP client (the VPN device) to
specify query-specific target name checking parameter in each query.
This example also show that SCVP should remove the requirement that the
default validation policy" MUST use the "basic validation algorithm"
as its default algorithm.

>>I know that this is the way SCVP letting organizations overwrite
>>the globally defined "default validation policy". However, in the
>>situation where an organization only supports one validation policy
>>and naturally uses that validation policy as its default organizational
>>validation policy, isn't it superfluous to request all its clients
>>to specify the organizational validation policy OID? In such situation,
>>clients usually want to omit the validation polict item in their
>>request and let the server use its default policy. With current syntax,
>>it is impossible to do that.
>Yes.  As written, the client would need to include the validationPolicy
>item with validationPolRef specifying the default validation policy OID
>and with all other fields of the validationPolicy absent.  While this
>does add a few bits to the request over making this validation policy the
>default in an ASN.1 encoding sense, it doesn't actually make things more
>difficult for the organization since these are just implementation details
>that would be hidden from the organization.
>
>I also asked one of the other editors about this and was told that this
>issue was debated and that a decision was made to require the request to
>explicitly specify the validation policy it wanted the server to use.  
>So, I don't think this is something that I could change without evidence
>that there is a working group consensus in favor of the change.  Without
>that, I have to assume that the consensus is in favor of the current ASN.1.

I am not aware the consensus you mentioned. As far as I remenber, the
decision only requires that SCVP must allow the client to explicitly
specify a validation policy other than the default validation policy.
(Of course, the specified validation policy still need to be one that
supported by the SCVP server.) I do not think the decision require that
the client can not omit the validation policy reference in the query to
let the server adopt its default validation policy. The editors seemed
to over-interpret the decision.

Comparing to forcing the client to specify the OID value
id-svp-defaultValPolicy in each query, I am in favor of let the client
omit the validation policy reference in that query to express the intention
of agreeing the server to adopt its default validation policy, because
that is more economic.

However, if the clarification text for the default validation policy
OID is incorprated into the draft, I can live with the current ASN.1
syntax that defines validationPolicy as a non-optional item.

>>The question is what is the relationship between "validation policy" and
>>"validation algorithm"? Will it be normally one-to-one relationship or
>>one-to-many relationship? By one-to-one relationship, I mean one validation
>>policy can only support one validation algorithm. By one-to-many relationship,
>>I mean one validation policy can support multiple validation algorithms.
>>In one-to-many relationship, a client might need to select one of the multiple
>>validation algorithms supported by the validation policy it specifies in the
>>request. In one-to-one relationship, since the validation policy implies
>>the validation algorithm, it is superfluous to ask the client to specify
>>both of them.
>>
>>I believe that it is easier to adopt one-to-one relationship model, let one
>>validation policy imply a validation algorithm, and remove the validation
>>algorithm item from the syntax. With one-to-one relationship model, if
>>an organization want to support multiple validation algorithm, they can
>>define multiple validation policies and let each imply one validation algorithm
>>respectively.
>>
>>The point is a validation policy can imply a validation algorithm, and therefore
>>the notion of validation algorithm can be removed from SCVP.
>
>I do not understand the objection.  A validation policy MUST specify
>a default validation algorithm.  So, if there is a one-to-one relationship
>between policies and algorithms, the client would NEVER have to specify
>the validation algorithm.
>
>As the document is currently written, an SCVP server could mandate a
>one-to-one relationship between policies and algorithms.  If the server
>supported multiple algorithms, it could define multiple policies with
>each specifying a different default validation algorithm.  The server
>could also reject any requests that specified a non-default validation
>algorithm.  Removing validationAlg from the validationPolicy item would
>simply force this one-to-one relationship on all SCVP servers. Since the
>inclusion of validationAlg as an optional parameter of the validationPolicy
>does not preclude SCVP servers from having a one-to-one relationship between
>policies and algorithms, I don't see any benefit to preventing others
>from implementing a one-to-many relationship if they choose to do so.

Good clarification. I think it is important to clarify the relationship
between policies and algorithms. How about adding some text to clarify
that relationship between policies and algorithms can be one-to-one as
well as one-to-many?

In addition, since the one-to-many relationship has never been discussed
in the working group, I think it is better that other members of the
working group could express their opinions about whether it proper to
alow a one-to-many relationship between policies and algorithms. If the
working group consnesus say "yes", then I have no objection on having both
notions of "validation policy" and "validation algorithm" exist in SCVP.

>>The current SCVP syntax and semantics only support validating certificates
>>against a retrospective moment. Please not that it is not the same to say
>>"a certificate is valid at time t1" as to say "a certificate is valid
>>before time t1", because the validity of the certificate could be suspended
>>and then resumed before time t1. It is certainly different with "a certificate
>>is valid from time t2 to time t1".
>I would be against trying to add such a feature for two reasons.  First,
>there have been conflicting ideas about how certificate suspension should be
>interpreted.  In my opinion, if a certificate is suspended but then removed
>from suspension, then once it has been removed from suspension it can be
>treated as if it had always been good.  That is, one suspends a certificate if
>there is a question about the status of the certificate and then removes the
>certificate from suspension only if it turns out that there was no problem.  
>Since the conclusion was that there was no problem, there is no reason to
>suspect that the private key was misused.
>
>I understand that some view suspension differently.  In their view, even if
>a certificate is removed from suspension any use of the private key while
>the certificate was suspended should be considered invalid.

Exactly, this is my view of the validity of the use of the signing
private key while the certificate was suspended. In some countries, the
public-key certificate is issued with the citizen ID card. The law may
stipulate that if a citizen temporarily loses its civil rights
(e.g., due to crimial), then validity of the citizen ID card as well as
its certificate will be suspended until it regain its civil rights. In such
situation, any digital signature signed by the private key corresponding
to the suspended certificate should be considered invalid.

>Second, even if there was universal agreement that any use of the private
>key corresponding to a certificate while the certificate is suspended (on hold)
>is not legitimate, I don't believe that functionality you want could be
>implemented.  If the client provided the SCVP server with a certificate
>and a time interval, how could the server ensure that the certificate was
>never on hold during that time period?  Remember that if a certificate is
>on hold (suspended) then the CA includes it on the CRL, but once the
>certificate is removed from hold it is simply no longer included on any
>subsequently issued CRLs.  Since no CRL issued after (or before) the
>certificate was removed from suspension would indicate that the certificate
>had ever been suspended, the SCVP server would only know that the certificate
>had been suspended if it looked at a CRL that was issued during the time
>that the certificate was on hold.
>
>So, would the SCVP server be required to check every CRL issued in the
>interval [t2 ... t1] to verify that the certificate was not listed one any
>CRL during the interval?  If so, how could the SCVP server be sure that it
>really checked every CRL issued during that interval?  If not, how could
>the SCVP server be sure that the certificate had not been suspended at any
>point in the interval?

Yes, in that situation the SCVP server might need to check several CRLs to
verify that the validity of certificate was not suspended during the interval
[t2...t1]. By checking the thisUpdate and nextUpdate items of CRLs and
knowing the CA's policy of issuing CRLs, the SCVP server can determine
whether it has checked all CRLs that need to be checked. It might be
hard but it is possible to implement this feature.

Wen-Cheng Wang

Date: Wed, 9 Mar 2005 14:09:28 -0600
To: Stephen Farrell <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: 3280bis internationalization section
Cc: Russ Housley <[email-masked]>, [email-masked]
Sender: [email-masked]

At 7:39 PM +0000 3/9/05, Stephen Farrell wrote:
>Paul,
>
>Probably trivial nit with this:
>
>change:
>>     To accommodate internationalized names in email addresses using the
>>     current structure, conforming implementations MUST convert the
>>     addresses into an ASCII representation.
>
>To:
>
>To accommodate internationalized names in email addresses using the
>current structure, conforming implementations MUST, before creating
>the certificate, or comparing against a certificate field, convert
>the addresses into an ASCII representation.

That sounds better and clearer. Slight editorial weenie nit: no comma 
after "...creating the certificate".

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 09 Mar 2005 13:38:32 -0600
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: PKIX <[email-masked]>
Subject: 3280bis: OtherName "health warning"
Sender: [email-masked]

Should we add a note in the Subject Alternative Name section to say 
something like - when an othername form is created matching rules for 
said othername name form must also be specified?

spt

Date: Wed, 09 Mar 2005 19:39:47 +0000
From: Stephen Farrell <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: Russ Housley <[email-masked]>, [email-masked]
Subject: Re: 3280bis internationalization section
Sender: [email-masked]

Paul,

Probably trivial nit with this:

change:
 >    To accommodate internationalized names in email addresses using the
 >    current structure, conforming implementations MUST convert the
 >    addresses into an ASCII representation.

To:

To accommodate internationalized names in email addresses using the
current structure, conforming implementations MUST, before creating
the certificate, or comparing against a certificate field, convert
the addresses into an ASCII representation.

Since there was slight confusion in the meeting on this (or else,
it was me that was confused:-),
Stephen.

Paul Hoffman wrote:

> 
> At 11:57 AM -0500 3/9/05, Russ Housley wrote:
> 
>> Paul:
>>
>> I disagree that this section should be removed.
>>
>> I believe this also has an impact on S/MIME and OpenPGP.  How are the 
>> comparison of the email address in the certificate and the FROM field 
>> on the email message handled?  memcmp?
>>
>> Russ
>>
>>
>> At 01:04 PM 3/8/2005, Paul Hoffman wrote:
>>
>>> - Section 7.5 should be removed. There is nothing currently being 
>>> considered in the IETF that relates to this. If there is later an 
>>> IETF standard for internationalized left-hand-sides in email 
>>> addresses, that standard can also extend the PKIX format.
> 
> 
> Whoops, I stopped reading at the second paragraph. It is clear that some 
> of the section is still relevant, but assert some of it is not. For 
> example, the current text says:
> 
>    Where the local-part of the addr-spec contains an internationalized
>    name, ...
> 
> That is *not* allowed by any current RFC, nor of any actively-discussed 
> Internet draft that I know of. Internationalized characters can only 
> appear in the host-part as a full-fledged (and legal) IDN.
> 
> Thus, I propose that, instead of removing the section as I previously 
> suggested, it should be replaced with:
> 
> 7.5  Internationalized Electronic Mail Addresses
> 
>    Electronic Mail addresses may be included in certificates and CRLs in
>    the subjectAltName and issuerAltName extensions, the name constraints
>    extension, authority information access extension, subject
>    information access extension, or CRL distribution points extension.
>    Each of these extensions uses the GeneralName construct; GeneralName
>    includes the rfc822Name choice, which is defined as type IA5String.
>    To accommodate internationalized names in email addresses using the
>    current structure, conforming implementations MUST convert the
>    addresses into an ASCII representation.
> 
>    If the host-part (the domain of the addr-spec) contains an
>    internationalized name, the domain name MUST be converted from an IDN
>    to the ASCII Compatible Encoding (ACE) format as specified in section
>    7.2.
> 
>    Two email addresses are considered to match if:
> 
>       1) the local-part of each name is an exact match, AND
>       2) the host-part of each name matches using a case-insensitive
>       ASCII comparison.
> 
>    Implementations should convert internationalized email addresses
>    specified in these extensions to Unicode before display.
>    Specifically, conforming implementations should convert the
>    host-part in the adder-spec as described in section 7.2.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> 

Date: Wed,  9 Mar 2005 13:33:34 -0500
From: [email-masked]
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: 3280bis internationalization section
Sender: [email-masked]

Paul,

Thanks for the review.  I will be happy to make the suggested changes in 
Section 7.2.  

I am also concerned about the email address syntax, but my worries were focued 
on the local part.  I hadn't considered dropping the entire section 7.5, but 
that might be the safest course!  I had made some assumptions about handling 
the host part; incorrect assumptions would have a very bad result.

I hope to corner Patrik Falstrom to discuss this before leaving Minneapolis, 
and will report his opinions to the list.

Thanks,

Tim

Quoting Paul Hoffman <[email-masked]>:

> 
> Greetings again. The new section 7 on internationalization in 3280bis 
> is very good. A few comments:
> 
> - In 7.2, the bulleted lists make it seem like you don't have to do 
> step 2, which you do. New wording might be:
> 
>        * perform step 1 with the domain name treated as a "stored
>        string";
>        * perform step 2;
>        * perform step 3 with the flag called "UseSTD3ASCIIRules" set;
>        * perform step 4 by processing each label with the "ToASCII"
> operation;
>        * perform step 5 by changing all label separators to U+002E (full
> stop).
> ...and...
>        * perform step 1 with the domain name treated as a "stored
>        string";
>        * perform step 2;
>        * perform step 3 with the flag called "UseSTD3ASCIIRules" set;
>        * perform step 4 by processing each label with the "ToUnicode"
> operation;
>        * step 5 is not needed.
> 
> - Section 7.5 should be removed. There is nothing currently being 
> considered in the IETF that relates to this. If there is later an 
> IETF standard for internationalized left-hand-sides in email 
> addresses, that standard can also extend the PKIX format.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> 
> 
> 

Date: Wed, 9 Mar 2005 12:32:25 -0600
To: Russ Housley <[email-masked]>, [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: 3280bis internationalization section
Sender: [email-masked]

At 11:57 AM -0500 3/9/05, Russ Housley wrote:
>Paul:
>
>I disagree that this section should be removed.
>
>I believe this also has an impact on S/MIME and OpenPGP.  How are 
>the comparison of the email address in the certificate and the FROM 
>field on the email message handled?  memcmp?
>
>Russ
>
>
>At 01:04 PM 3/8/2005, Paul Hoffman wrote:
>>- Section 7.5 should be removed. There is nothing currently being 
>>considered in the IETF that relates to this. If there is later an 
>>IETF standard for internationalized left-hand-sides in email 
>>addresses, that standard can also extend the PKIX format.

Whoops, I stopped reading at the second paragraph. It is clear that 
some of the section is still relevant, but assert some of it is not. 
For example, the current text says:

    Where the local-part of the addr-spec contains an internationalized
    name, ...

That is *not* allowed by any current RFC, nor of any 
actively-discussed Internet draft that I know of. Internationalized 
characters can only appear in the host-part as a full-fledged (and 
legal) IDN.

Thus, I propose that, instead of removing the section as I previously 
suggested, it should be replaced with:

7.5  Internationalized Electronic Mail Addresses

    Electronic Mail addresses may be included in certificates and CRLs in
    the subjectAltName and issuerAltName extensions, the name constraints
    extension, authority information access extension, subject
    information access extension, or CRL distribution points extension.
    Each of these extensions uses the GeneralName construct; GeneralName
    includes the rfc822Name choice, which is defined as type IA5String.
    To accommodate internationalized names in email addresses using the
    current structure, conforming implementations MUST convert the
    addresses into an ASCII representation.

    If the host-part (the domain of the addr-spec) contains an
    internationalized name, the domain name MUST be converted from an IDN
    to the ASCII Compatible Encoding (ACE) format as specified in section
    7.2.

    Two email addresses are considered to match if:

       1) the local-part of each name is an exact match, AND
       2) the host-part of each name matches using a case-insensitive
       ASCII comparison.

    Implementations should convert internationalized email addresses
    specified in these extensions to Unicode before display.
    Specifically, conforming implementations should convert the
    host-part in the adder-spec as described in section 7.2.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 09 Mar 2005 11:57:37 -0500
To: Paul Hoffman <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: 3280bis internationalization section
Sender: [email-masked]

Paul:

I disagree that this section should be removed.

I believe this also has an impact on S/MIME and OpenPGP.  How are the 
comparison of the email address in the certificate and the FROM field on 
the email message handled?  memcmp?

Russ

At 01:04 PM 3/8/2005, Paul Hoffman wrote:
>- Section 7.5 should be removed. There is nothing currently being 
>considered in the IETF that relates to this. If there is later an IETF 
>standard for internationalized left-hand-sides in email addresses, that 
>standard can also extend the PKIX format.

Date: Tue, 8 Mar 2005 12:04:41 -0600
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: 3280bis internationalization section
Sender: [email-masked]

Greetings again. The new section 7 on internationalization in 3280bis 
is very good. A few comments:

- In 7.2, the bulleted lists make it seem like you don't have to do 
step 2, which you do. New wording might be:

       * perform step 1 with the domain name treated as a "stored
       string";
       * perform step 2;
       * perform step 3 with the flag called "UseSTD3ASCIIRules" set;
       * perform step 4 by processing each label with the "ToASCII" operation;
       * perform step 5 by changing all label separators to U+002E (full stop).
...and...
       * perform step 1 with the domain name treated as a "stored
       string";
       * perform step 2;
       * perform step 3 with the flag called "UseSTD3ASCIIRules" set;
       * perform step 4 by processing each label with the "ToUnicode" operation;
       * step 5 is not needed.

- Section 7.5 should be removed. There is nothing currently being 
considered in the IETF that relates to this. If there is later an 
IETF standard for internationalized left-hand-sides in email 
addresses, that standard can also extend the PKIX format.

--Paul Hoffman, Director
--VPN Consortium

Date: Tue, 8 Mar 2005 14:57:12 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SCVP Draft 17: Summary of changes
Cc: [email-masked]
Sender: [email-masked]

> >
> >Not only in mathematics a red herring may neither be red nor a herring. An empty
> >set trivially full fills any condition.
> >
> You asked me the reason that I encoded keyUsages the way that I did and 
> so I explained.  Just because you don't agree with my reasoning is no 
> reason to be insulting.

Insulting?  I do not intend to insult anyone here, but 
I forgot to mention that I cited from Morris Hirsch's book of 
differential topology.  

> Of course, if the working group indicates a preference for a different 
> encoding, I will change it, but I have not heard anyone else suggest 
> that this needs to be changed.

Tim and you have explicitly asked not to propose changes in ASN.1.
 
Did I ask to change it? I only made another explanation of a different
way to specify the same thing with a shorter encoding, but since the
semantics is equivalent ...

see also (*1*) below

> >I had actually been tempted to change requestorRef to be a sequence of 
> >GeneralName since GeneralName seemed to be more appropriate than OCTET 
> >STRING for something that was supposed to hold an identifier.  A side 
> >effect of this change is that it would have specified the encodings for 
> >the identifiers as well.  However, there was a comment submitted for 
> >draft 16 indicating a need to be able to use a hash value as an 
> >identifier in requestorRef, an option that would have been effectively 
> >precluded if OCTET STRING had been changed to GeneralName.  Since I 
> >could not justify preventing use of a hash value and one can easily 
> >encode any GeneralName value in an OCTET STRING, I left the syntax for 
> >requestorRef unchanged.
> >  
> >
> >
> >Since you could not justify it, well then, yes, that's important ... :) 
> >And, you didn't even feel that this would have been worth to be
> >discussed a little bit.
> >  
> >
> As I see it, my responsibility as an editor is to do my best to ensure 
> that the final document is technically correct and represents rough 
> working group consensus.  That means that I should not be making changes 
> to the protocol simply for stylistic reasons just because one person 
> would prefer to see the change made, even if that person is me.

'stylistic' is the important word here?

> >There is nothing in 3379 that requires that you must be able to encode
> >a hash value.
> >  
> >
> That's probably true, but not the point.  Its not as if I unilaterally 
> changed the protocol to enable the encoding of hash values in 
> requestorRef.  I'm just saying that I would have been in favor of making 
> such a change, but could not because I had reason to believe that some 
> members of the working group would be against such a change, whereas I 
> didn't know of anyone who felt that the change was needed.

The change from a octet string containing a sequence of zero terminated
octet string into a sequence of octet string was made by Trevor.

The message referenced below accnoledged that this was a first step,
BUT that the explanatary text contain useless restriction left
over from the previous version. The desire to code a hash is an example
to illustrate the error, not more.

The real point is that several times in the past I had asked exactly
what you had thought about, i.e. to use a construct that at
least allow GeneralName to represent participating entities.

> I am really confused by your argument that I should have made a 
> unilateral change simply because the option that I would have been 
> removing is not mandated by 3379.  First, as you have said before, just 
> because something is not mandated by 3379 does not mean that it can't be 
> included in SCVP.  Second, YOU are the one who expressed a desire to be 
> able to encode a hash value in requestorRef 
> (http://www.imc.org/ietf-pkix/mail-archive/msg01739.html). 

This was  a reference to the restrictions about the content,
i.e. no zeros. I could have said as well that any encoded value
needs an extra escaping rule to protect for hex 0. 

I had sugggested also at some time ago a 
sequence of choice { octet string , generalname }
as a compromise in order to avoid a potential problem with the
content of an octet string that might be required by someone.

- without any success
- but then a change to a sequence to octet strings, 
- then the introduction of one requestername
- then requesternames. 

If I am considered to be the only one who wants to
encode a hash value, I can do this without the need of
an octet string, so you can safely replace requesterRef by
a GeneralName.

> >>I think this is more of a theoretical concern than a practical concern.  
> >>The odds that two servers that are part of the same SCVP relay network 
> >>would select different identifiers for use in requestorRef, but that as 
> >>a result of using different encoding techniques the encoded versions of 
> >>their names are the same are extremely small.
> >>    
> >>
> >
> >There are also various ways to encode a hash value into a GeneralName,
> >so it is wrong that this has been effectively precluded. Waht IS actually
> >precluded is that these identifiers can have a structure following any
> >global name space and you have no collisions using encoding.
> >
> While it is trivial to convert something that would have been encoded as 
> GeneralName to an OCTET STRING (just place the DER encoding of the name 
> in the octet string), I am not aware of any currently defined method for 
> encoding a hash value in GeneralName.  Certainly one could define an 
> attribute for inclusion in a directoryName or one could define a new 
> name form to go in otherName, but that doesn't seem very practical.

Since it is a hash with an algo, one can use the well known
messageDigest which is roughly speaking close to an attribute which
you could formally put into a RDN.

> >> believe that SCVP already includes all of the basic fields needed to 
> >>support relay.  I don't believe that the base document needs to say any 
> >>more.  When a server implements relay, it sends out an CVRequest and 
> >>gets back a CVResponse just as a normal client would.  Guidance on what 
> >>queries a server should send and what it should do with the response is 
> >>just that.  Guidance on how to use a particular feature does not need to 
> >>be in the base standard, it can be in a separate informational 
> >>document.  If there is a desire for SCVP servers that implement relay to 
> >>exchange auxiliary information, that information can always be included 
> >>in non-critical response extensions.  So, I can not see any reason to 
> >>hold up the base standard.  There are too many people who need this 
> >>standard to be completed and who can use it even without guidance on how 
> >>to implement relay.
> >>    
> >>
> >
> >There is no exchange of AUXILIARY information. The requirements say
> >clearly that the client can request that the server returns ALL
> >information. The base text allows for relaying.
> >
> >The current text does not honor this requierement of 3379.
> >  
> >
> Please specify exactly where in 3379 there is a requirement that the 
> current text does not honor.  I do see the following in section 4.2:
> 
>    - 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
> 
> To me, this means that any information in the request or response that 
> is specific to relay MUST be auxiliary information in that the recipient 
> must be able to process the message even if this information is ignored.

The "third" "other" relying party is NOT a dpv client. The requester of
the dpv response is a client. It can process the result because all
what it does is to authenticate the result and see whether it is good.

> >what you are suggesting, is to totally ignore relaying in the base
> >document which is contrary to what had been announced by Trevor, i.e. 
> >to specify how a relay would act, nothing had been changed. 
> >After having discussed that this is needed several months ago, 
> >and with agreement from Trevor, it is really surprising that
> >you haven't made your observation earlier.
> >  
> >
> If Trevor agreed to make a change to the document that was not made, I 
> am not aware of it.  If there was a prior agreement to make a change to 
> the document and the change was not made, then I'll work with Trevor to 
> add the necessary text.  I am expressing my own opinions on this matter 
> based on my knowledge of the situation.

I include an excerpt from a message from 10th of december 2004, after
draft 16. And there is also a corresponding comment from Denis.

* > * > * Chapter 7: Denis is right that the spec does not describe how
* > relaying
* > * > is
* > * > * performed, i.e. how a response is created from a response
received
* > * > from
* > * > * another
* > * > * server by a 'proxy'.
* > * > [TF] What specifically are you looking for?
* > *
* > * A working specification that includes:
* > *
* > * - how a request received is transformed into a new request by a
relay,
* > *   which fields are copied, or not, or may.
* > * - how the response is transformed into a response to the original
* > request
* > *   there are SEVERAL options, in particulat the one that addresses
* > *   the requirement of allowing a response as part of another one.
* > [TF] OK. I will add that.
* good.
* 
* Would it be possible to send a draft to the list before it get graved
into
* electronic marble.

> >Thus, as you admit, the text does not at all contain information about how 
> >
> >- a relay should take a request from a client and transform it into
> >  a request to another server;
> >  At least it is already said one modification is to add the loop
> >  control.
> >  
> >
> Support for loop detection is mandated by 3379:
> 
>    - When a server supports a relay mechanism, a mechanism to detect
>      loops or repetition MUST be provided.
> 
> So, it is clear that this must be included in the protocol.  In SCVP, it 
> is included in such a way that it can be ignored by clients and servers 
> that do not support relay.
> 
> There no reason for the standard to state how to transform a request 
> from a client  into a request to another server.  The protocol already 

The text for loop control is a demonstration that the contrary is true.
The transformation may be simple, but still you have:

- A relaying server prepares a request by taking all parameters from
  the received request, and:
  - modifies the loop control parms
  - modifies the requesterName (sets itself, or not?)

> specifies the rules for generating requests and the rules for generating 
> responses.  These rules apply whether the requester is the end client or 
> a relaying server.  How the server computes the response is a local 
> matter and thus not something that needs to be standardized.  The 
> contents of the response do need to be standardized and they are.  If a 
> server wants to call upon the resources of another SCVP server to help 
> answer a question, it may do that, but the contents of that request 
> message are irrelevant as long as the request conforms to the rules 
> specified in section 3 for SCVP requests.
> 
> An SCVP server that receives a DPV request could in turn send either a 
> DPV or DPD request to another server.  The request could ask for 
> revocation status checking if that was required by the client or the 
> server could ask for just the certification path and then perform 
> revocation status checking itself.  As long as it provides the correct 
> response to the client, it does not matter.

Dependingh on a paricular policy, the only correct answer can be one that
includes all the information provided by external sources that have contributed
to make the DPV response.  

> So, any information about how to transform a request from a client into 
> a request to another server would be informative not normative, and so 
> it does not need to be included in the base standard.  

- An optional feature does not mean that it is not normative when used.

- Currently there is no way for a server to include a response from
  another server ASIS, including its signature. 
  The remote server acts as a civil law notary type, the third
  party is a judge that only validates whether the notary has
  validated the certificate, and does not perform any validation.

- If a DPV server validates a certificate, it may only provide
  a yes and no answer, and a statement from the remote server
  also with a yes and no answer. No path, no revocation info. 
   
                                                        It is my 
> understanding that Tim Polk has proposed that you write a separate, 
> informative document describing how relay can be used.

???

> >- the result of the request could be returned as is with just the
> >  security envelope changed. But then the client does not have
> >  the important information required to show to a third party.
> >  
> >
> What information would the client be required to show to a third party 
> that is not provided.  In the case of DPD, the client is performing the 

A way to authenticate the response, the third party is not required
to trust the client's local server but only a response from let's say
'public notary service'.

> validation itself and so would certainly have any evidence needed to 
> show to a third party.  In the case of DPV, the client is indicating 
> that it trusts the server.  If the signed response from the server is 
> not sufficient evidence to show to a third party, then the client needs 
> to request more information from the server (e.g., require the server to 
> include the certification path in the response).   What does relay have 
The local server may not be in the trust space of the third party. 

> to do with this?  What if the server you sent to request to didn't even 
> use relay to compute the response?  Are you saying that a server might 
> be REQUIRED to use relay in order to generate a response, not because 
> the server is unable to compute the response on its own but because some 
> evidence would be created as a result of performing relay that is needed 
> by the client to later show to a third party and that evidence could not 
> be created without relay?  If so, then I do not see anything in 3379 to 
> justify this type of requirement.  If not, then I don't see how it could 

The requirement's text says clearly: 

   Such
   information may (not necessarily exclusively) consist of a
   certification path, revocation status information from authorized CRL
   issuers or authorized OCSP responders, revocation status information
   from CRL issuers or OCSP responders trusted under the validation
   policy, time-stamp tokens from TSAs responders trusted under the
   validation policy, or a DPV response from a DPV server that is
                         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   trusted under the validation policy.  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.

This means that it is possible for a server to use another one for
whatever purpose, and, if so (and why and how is a local matter), but
it is not a local matter to have the possibility to include the answer,
and this is not the case today.  

> be in the case that relay was used that the client would be required to 
> have information about the relay to show to a third party.

The signature of the remote server's DPV response is not shown, i.e.
there is no way for the third party to authenticate the information. 

- You have still not responded to my question why it is necessary to
  have returned information encapsulated in octet strings requiring
  another invocation of a parser for the octet strings. 

  I had said this long ago: *1*

  - There are octet strings that carry undefined global information
  without encoding guidance.

  - There are ANY defined by structures

  - There are octet string containing other asn1 structures

  - there is the EXTENSION logic (=previous + critical)

  Three different techniques are used for similar purposes, where
  is any justification or logic for these differences?

- Given that a server can now return more than one requesterName,
  I ask for a change that allow a sequence also in a request,
  so that one has at least some change to note more than one
  client identity. This allow to note participating entities
  in a relaying environment. 

- It seems that you have not seem that in my recent message about
  asn1 styles there was a remark to make a policyId optional in
  case of a fatal server error.

Peter

Date: Tue, 08 Mar 2005 09:39:07 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

Santosh,

> Denis,
> 
> Thanks.  When 3126 is used, there is additional basis for NR.  That is good.
> 
> Thinking ahead for SHA-1 (assuming it has similar vulnerability), I wonder
> if 3126 should be revised to use a different hashing algorithm than the one
> used to sign the certificate to shore up the NR argument.

No revision will be necessary, since RFC 3126 already includes that option 
in section "3.8.2  Other Signing Certificate Attribute Definition". I copy 
that section underneath:

    The following attribute is identical to the ESS SigningCertificate
    defined above except that this attribute can be used with hashing
    algorithms other than SHA-1.

    This attribute must be used in the same manner as defined above for
    the ESS SigningCertificate attribute.

    The following object identifier identifies the signing certificate
    attribute:

    id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
        member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) id-aa(2) 19 }

    The signing certificate attribute value has the ASN.1 syntax
    OtherSigningCertificate

    OtherSigningCertificate ::=  SEQUENCE {
        certs        SEQUENCE OF OtherCertID,
        policies     SEQUENCE OF PolicyInformation OPTIONAL
                     -- NOT USED IN THIS DOCUMENT
    }

    OtherCertID ::= SEQUENCE {
         otherCertHash            OtherHash,
         issuerSerial             IssuerSerial OPTIONAL
    }

    OtherHash ::= CHOICE {
        sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
        otherHash OtherHashAlgAndValue
    }

    OtherHashValue ::= OCTET STRING

    OtherHashAlgAndValue ::= SEQUENCE {
      hashAlgorithm  AlgorithmIdentifier,
      hashValue      OtherHashValue
    }

Denis

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Denis Pinkas
> Sent: Monday, March 07, 2005 9:50 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
> 
> 
> 
> Santosh,
> 
> 
>>Denis,
> 
> 
>>But, that alone will not support NR in case of the Lenstra attack 
>>since cert hash, issuer, and serial will be all the same.
> 
> 
> But the collision is on the *content* of the certificate computed using MD5 
> while ESSCertID requires the use of SHA-1 to compute a hash over the 
> *entire* certificate.
> 
> This solves the issue.
> 
> Denis
> 
> 
>>I think NR claim ties to showing Lenstra paper and then showing that 
>>forcing the subscriber to show the primes or private key to show that 
>>one of the primes for a 2048 modulus is only 512 bits (should be 
>>around 1024 bits).
>>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>>Sent: Monday, March 07, 2005 3:36 AM
>>To: Santosh Chokhani
>>Cc: [email-masked]
>>Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
>>
>>
>>
>>Santosh,
>>
>>
>>
>>>Some of us have suggested that the Lenstra attack does not break
>>>non-repudiation. I would like to add another evidence for NR.
>>>
>>>If there is a dispute between the signer and the relying party and the
>>>signer (or CA) and the relying party produce two certificates 
>>>resulting in the same hash,
>>
>>
>>When RFC 3126 is used, then ESSCertID MUST be used as a signed 
>>attribute
>>which means that not only there MUST be the same hash value but also the 
>>same CA DN and the same serial number.
>>
>>    ESSCertID ::=  SEQUENCE {
>>         certHash                 Hash,
>>         issuerSerial             IssuerSerial OPTIONAL
>>    }
>>
>>    Hash ::= OCTET STRING -- SHA1 hash of entire certificate
>>
>>    IssuerSerial ::= SEQUENCE {
>>         issuer                   GeneralNames,
>>         serialNumber             CertificateSerialNumber
>>    }
>>
>>Denis
>>
>>
>>
>>>signer could be required to produce further evidence for the modulii
>>>and one would notice that one of the factors is 512 bits for 2048 
>>>modulus, something FIPS does not recommend.  That would be viewed as 
>>>additional evidence of mischief by the subscriber.
>>>
>>>Santosh Chokhani
>>>Orion Security Solutions, Inc.
>>>1489 Chain Bridge Road, Suite 300
>>>McLean, Virginia 22101
>>>(703) 917-0060  Ext. 35 (voice)
>>>(703) 917-0260 (Fax)
>>>[email-masked]
>>>Visit our Web site
>>>http://www.orionsec.com
>>
>>
>>
>>
>>
> 
> 
> 

Date: Tue, 08 Mar 2005 09:38:50 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

Santosh,

> Denis,
> 
> Thanks.  When 3126 is used, there is additional basis for NR.  That is good.
> 
> Thinking ahead for SHA-1 (assuming it has similar vulnerability), I wonder
> if 3126 should be revised to use a different hashing algorithm than the one
> used to sign the certificate to shore up the NR argument.

No revision will be necessary, since RFC 3126 alrady includes that option in 
section "3.8.2  Other Signing Certificate Attribute Definition". I copy that 
section underneath:

    The following attribute is identical to the ESS SigningCertificate
    defined above except that this attribute can be used with hashing
    algorithms other than SHA-1.

    This attribute must be used in the same manner as defined above for
    the ESS SigningCertificate attribute.

    The following object identifier identifies the signing certificate
    attribute:

    id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
        member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        smime(16) id-aa(2) 19 }

    The signing certificate attribute value has the ASN.1 syntax
    OtherSigningCertificate

    OtherSigningCertificate ::=  SEQUENCE {
        certs        SEQUENCE OF OtherCertID,
        policies     SEQUENCE OF PolicyInformation OPTIONAL
                     -- NOT USED IN THIS DOCUMENT
    }

    OtherCertID ::= SEQUENCE {
         otherCertHash            OtherHash,
         issuerSerial             IssuerSerial OPTIONAL
    }

    OtherHash ::= CHOICE {
        sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
        otherHash OtherHashAlgAndValue
    }

    OtherHashValue ::= OCTET STRING

    OtherHashAlgAndValue ::= SEQUENCE {
      hashAlgorithm  AlgorithmIdentifier,
      hashValue      OtherHashValue
    }

Denis

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Denis Pinkas
> Sent: Monday, March 07, 2005 9:50 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
> 
> 
> 
> Santosh,
> 
> 
>>Denis,
> 
> 
>>But, that alone will not support NR in case of the Lenstra attack 
>>since cert hash, issuer, and serial will be all the same.
> 
> 
> But the collision is on the *content* of the certificate computed using MD5 
> while ESSCertID requires the use of SHA-1 to compute a hash over the 
> *entire* certificate.
> 
> This solves the issue.
> 
> Denis
> 
> 
>>I think NR claim ties to showing Lenstra paper and then showing that 
>>forcing the subscriber to show the primes or private key to show that 
>>one of the primes for a 2048 modulus is only 512 bits (should be 
>>around 1024 bits).
>>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>>Sent: Monday, March 07, 2005 3:36 AM
>>To: Santosh Chokhani
>>Cc: [email-masked]
>>Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
>>
>>
>>
>>Santosh,
>>
>>
>>
>>>Some of us have suggested that the Lenstra attack does not break
>>>non-repudiation. I would like to add another evidence for NR.
>>>
>>>If there is a dispute between the signer and the relying party and the
>>>signer (or CA) and the relying party produce two certificates 
>>>resulting in the same hash,
>>
>>
>>When RFC 3126 is used, then ESSCertID MUST be used as a signed 
>>attribute
>>which means that not only there MUST be the same hash value but also the 
>>same CA DN and the same serial number.
>>
>>    ESSCertID ::=  SEQUENCE {
>>         certHash                 Hash,
>>         issuerSerial             IssuerSerial OPTIONAL
>>    }
>>
>>    Hash ::= OCTET STRING -- SHA1 hash of entire certificate
>>
>>    IssuerSerial ::= SEQUENCE {
>>         issuer                   GeneralNames,
>>         serialNumber             CertificateSerialNumber
>>    }
>>
>>Denis
>>
>>
>>
>>>signer could be required to produce further evidence for the modulii
>>>and one would notice that one of the factors is 512 bits for 2048 
>>>modulus, something FIPS does not recommend.  That would be viewed as 
>>>additional evidence of mischief by the subscriber.
>>>
>>>Santosh Chokhani
>>>Orion Security Solutions, Inc.
>>>1489 Chain Bridge Road, Suite 300
>>>McLean, Virginia 22101
>>>(703) 917-0060  Ext. 35 (voice)
>>>(703) 917-0260 (Fax)
>>>[email-masked]
>>>Visit our Web site
>>>http://www.orionsec.com
>>
>>
>>
>>
>>
> 
> 
> 

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, pkix mailing list <[email-masked]>, pkix chair <[email-masked]>, pkix chair <[email-masked]>
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure  Certificate Request Message Format (CRMF)' to Proposed Standard 
Date: Mon, 07 Mar 2005 19:20:10 -0500
Sender: [email-masked]

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Certificate Request Message Format 
   (CRMF) '
   <draft-ietf-pkix-rfc2511bis-08.txt> as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509) Working 
Group. 

The IESG contact persons are Russ Housley and Sam Hartman.

Technical Summary

  This document obsoletes RFC 2511.

  This document describes the Certificate Request Message Format (CRMF).
  This syntax is used to convey a request for a certificate to a
  Certification Authority (CA), possibly via a Registration Authority
  (RA), for the purposes of X.509 certificate production.  The request
  will typically include a public key and associated registration
  information.

Working Group Summary

  The Working Group came to consensus on this document.

Protocol Quality

  This document was reviewed by Jeffrey I. Schiller for the IESG.

RFC Editor Note

  Update the [CMS] reference to point to RFC 3852 instead of
  RFC 3369, which is obsoleted by RFC 3852.

  There is an error in the ASN.1 module.  I very minor change to
  Appendix B is needed to correct it.

  OLD:

  -- Cryptographic Message Syntax 
     EnvelopedData 
        FROM CryptographicMessageSyntax { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
             modules(0) cms-2001(14) };  -- found in [CMS] 

  NEW:

  -- Cryptographic Message Syntax 
     EnvelopedData 
        FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
                                       ^^^^
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
             modules(0) cms-2001(14) };  -- found in [CMS]

Date: Mon, 7 Mar 2005 16:26:46 -0500
To: "Dave Engberg" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Cc: "Robert Zuccherato" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

At 8:15 PM -0500 3/4/05, Dave Engberg wrote:
>
>I think Robert was using the formal RFC 2560 definition of "good":
>
>    The "good" state indicates a positive response to the status inquiry.
>    At a minimum, this positive response indicates that the certificate
>    is not revoked, but does not necessarily mean that the certificate
>    was ever issued or that the time at which the response was produced
>    is within the certificate's validity interval. [...]
>
>This is slightly different than the intuitive sense of good-ness, 
>and I think it matches with your description.  Mr. Myers (et.al) 
>could chime in, but I belive this definition was specifically chosen 
>so that a responder could operate using only the CRL and not a DB of 
>issued certs.  (Pre-signing aside.)
>

If that is the context in which to interpret "good," then no problem.

Steve
--============_-1101891357==_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: [saag] X.509 certificate collision, via MD5
collisions</title></head><body>
<div>At 8:15 PM -0500 3/4/05, Dave Engberg wrote:</div>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">I think
Robert was using the formal RFC 2560 definition of
&quot;good&quot;:</font><br>
<blockquote><font face="Arial" size="-1">&nbsp;&nbsp; The &quot;good&quot;
state indicates a positive response to the status inquiry.<br>
&nbsp;&nbsp; At a minimum, this positive response indicates that the
certificate<br>
&nbsp;&nbsp; is not revoked, but does not necessarily mean that the
certificate<br>
&nbsp;&nbsp; was ever issued or that the time at which the response
was produced<br>
&nbsp;&nbsp; is within the certificate's validity interval.
[...]</font><br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">This is
slightly different than the intuitive sense of good-ness, and I think
it matches with your description.&nbsp; Mr. Myers (et.al) could chime
in, but I belive this definition was specifically chosen so that a
responder could operate using only the CRL and not a DB of issued
certs.&nbsp; (Pre-signing aside.)</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<div><br></div>
<div>If that is the context in which to interpret &quot;good,&quot;
then no problem.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1101891357==_ma============--

Date: Mon,  7 Mar 2005 14:13:24 -0500
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: "Final" PKIX Agenda
Sender: [email-masked]

Folks,

As is often the case, there are a few last minute changes to the PKIX Agenda.
(1) Akira Kanaoka (Secom/JNSA PKI Challenge Project) will be making the 
presentation on UTF8Striong deployment.
(2) A ten minute liasion presentation by has been added on a forthcoming 
personal draft defining a data interchange format for OCSP servers. The
presenter will be John Hines from Tumbleweed.
(3) To accomodate, I shrank the 3280bis and CRL AIA time slots by 5 minutes 
each.  I believe I had added to the time slot requested by the presenters in 
both instances.

Thanks,

Tim Polk

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

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

TUESDAY, March 8, 2005, 1300-1500

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

CHAIRS: Stephen Kent <[email-masked]>
        Tim Polk <[email-masked]>

1. WG Status and Direction

1.1 Document Status Review [Tim Polk (NIST)]
       (10 min.)

2. PKIX WG Specifications

2.1 Simple Certificate Validation Protocol (SCVP)
       Trevor Freeman (Microsoft) and David Cooper (NIST
      http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-18.txt

      Significant progress has been made towards rough consensus through
      the two drafts submitted since the last meeting.  These drafts
      represent been submitted with significant enhancements.  This
      presentation will highlight those changes and their rationale, as
      well as the question of rough consensus.
      (20 min.)

2.2 3280bis
        David Cooper (NIST)
      currently available on NIST site
http://csrc.nist.gov/pki/documents/PKIX/draft-ietf-pkix-rfc3280bis-00.txt
      see also
http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html

      A design team met in January to develop a -00 draft from a issues
      list complied from PKIX mail messages and mail to the RFC 3280
      editors.  Draft -00 incorproates a number of clarifications and small
      changes designed to align with ISO and remove ambiguities, and a new
      section on comparing internationalized names.  Draft -00 and a diff
      file highlighting changes are now available from the URLS above.  
      This presentation will focus on the set of changes and in the -00
      draft and the proposed approaches for comparing internationalized names.
      (25 min.)

2.3 UTF8String Deployment and Migration
        Akira Kanaoka (Secom/JNSA PKI Challenge Project)
        (no draft)

      This presentation will provide the feedback recieved fron a questionnaire
      on UTF8String deployment in Asia, and discuss a migration strategy
      that is currently under development. 
      (15 min.)

2.4 Discovering CRL Signer Certificates Using AIA
        Stefan Santesson (Microsoft)
      http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt

      Draft -00 of this new PKIX document was published after the last meeting.
      This presentation will review the comments recieved oin this document to
      date and the plan for progression.
      (10 min.)

2.5 Update on CMC Archive, CMC Transport
        Jim Schaad (Soaring Hawk)
      http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-trans-03.txt
      http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-archive-01.txt

      This presentation will review the state of several related drafts and
      highlight the controversies that remain.  (20 min.)

3. Related Specifications & Liaison Presentations

      Time allowing, liaison presentations will be accommodated to ensure the
      PKIX WG is aware of related specifications currently progressing as
      individual drafts.

3.1 Lightweight Directory Access Protocol (LDAP) schema definitions
      Kent Zeilenga (OpenLDAP)
      http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-x509-01.txt

      The author of this individual submission has requested that the WG review
      and comment upon this draft.  He intends to make a decision by the end of
      IETF#62 whether to recommend this revision for IESG consideration as a
      Proposed Standard. This document is intended to be published at the same
      time as the revised LDAP TS being developed by the LDAPBIS WG. (10 min.)

3.2 OCSP Data Interchange Format
      John Hines (Tumbleweed)
        (no draft)

      The presenter will be submitting an individual draft defining a data
      interchange format for OCSP servers.  The presentation will present the
      problems that inspired this draft and invite WG participation. (10 min.) 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Date: Mon, 7 Mar 2005 12:27:16 -0500
Importance: Normal
Sender: [email-masked]

Denis,

Thanks.  When 3126 is used, there is additional basis for NR.  That is good.

Thinking ahead for SHA-1 (assuming it has similar vulnerability), I wonder
if 3126 should be revised to use a different hashing algorithm than the one
used to sign the certificate to shore up the NR argument.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Monday, March 07, 2005 9:50 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions

Santosh,

> Denis,

> But, that alone will not support NR in case of the Lenstra attack 
> since cert hash, issuer, and serial will be all the same.

But the collision is on the *content* of the certificate computed using MD5 
while ESSCertID requires the use of SHA-1 to compute a hash over the 
*entire* certificate.

This solves the issue.

Denis

> I think NR claim ties to showing Lenstra paper and then showing that 
> forcing the subscriber to show the primes or private key to show that 
> one of the primes for a 2048 modulus is only 512 bits (should be 
> around 1024 bits).
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Monday, March 07, 2005 3:36 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
> 
> 
> 
> Santosh,
> 
> 
>>Some of us have suggested that the Lenstra attack does not break
>>non-repudiation. I would like to add another evidence for NR.
>>
>>If there is a dispute between the signer and the relying party and the
>>signer (or CA) and the relying party produce two certificates 
>>resulting in the same hash,
> 
> 
> When RFC 3126 is used, then ESSCertID MUST be used as a signed 
> attribute
> which means that not only there MUST be the same hash value but also the 
> same CA DN and the same serial number.
> 
>     ESSCertID ::=  SEQUENCE {
>          certHash                 Hash,
>          issuerSerial             IssuerSerial OPTIONAL
>     }
> 
>     Hash ::= OCTET STRING -- SHA1 hash of entire certificate
> 
>     IssuerSerial ::= SEQUENCE {
>          issuer                   GeneralNames,
>          serialNumber             CertificateSerialNumber
>     }
> 
> Denis
> 
> 
>>signer could be required to produce further evidence for the modulii
>>and one would notice that one of the factors is 512 bits for 2048 
>>modulus, something FIPS does not recommend.  That would be viewed as 
>>additional evidence of mischief by the subscriber.
>>
>>Santosh Chokhani
>>Orion Security Solutions, Inc.
>>1489 Chain Bridge Road, Suite 300
>>McLean, Virginia 22101
>>(703) 917-0060  Ext. 35 (voice)
>>(703) 917-0260 (Fax)
>>[email-masked]
>>Visit our Web site
>>http://www.orionsec.com
> 
> 
> 
> 
> 

Date: Mon, 07 Mar 2005 15:50:13 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

Santosh,

> Denis,

> But, that alone will not support NR in case of the Lenstra attack since cert
> hash, issuer, and serial will be all the same.

But the collision is on the *content* of the certificate computed using MD5 
while ESSCertID requires the use of SHA-1 to compute a hash over the 
*entire* certificate.

This solves the issue.

Denis

> I think NR claim ties to showing Lenstra paper and then showing that forcing
> the subscriber to show the primes or private key to show that one of the
> primes for a 2048 modulus is only 512 bits (should be around 1024 bits).
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Denis Pinkas
> Sent: Monday, March 07, 2005 3:36 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
> 
> 
> 
> Santosh,
> 
> 
>>Some of us have suggested that the Lenstra attack does not break 
>>non-repudiation. I would like to add another evidence for NR.
>>
>>If there is a dispute between the signer and the relying party and the 
>>signer (or CA) and the relying party produce two certificates 
>>resulting in the same hash,
> 
> 
> When RFC 3126 is used, then ESSCertID MUST be used as a signed attribute 
> which means that not only there MUST be the same hash value but also the 
> same CA DN and the same serial number.
> 
>     ESSCertID ::=  SEQUENCE {
>          certHash                 Hash,
>          issuerSerial             IssuerSerial OPTIONAL
>     }
> 
>     Hash ::= OCTET STRING -- SHA1 hash of entire certificate
> 
>     IssuerSerial ::= SEQUENCE {
>          issuer                   GeneralNames,
>          serialNumber             CertificateSerialNumber
>     }
> 
> Denis
> 
> 
>>signer could be required to produce further evidence for the modulii 
>>and one would notice that one of the factors is 512 bits for 2048 
>>modulus, something FIPS does not recommend.  That would be viewed as 
>>additional evidence of mischief by the subscriber.
>>
>>Santosh Chokhani
>>Orion Security Solutions, Inc.
>>1489 Chain Bridge Road, Suite 300
>>McLean, Virginia 22101
>>(703) 917-0060  Ext. 35 (voice)
>>(703) 917-0260 (Fax)
>>[email-masked]
>>Visit our Web site
>>http://www.orionsec.com
> 
> 
> 
> 
> 

Date: Mon, 07 Mar 2005 14:59:57 +0100
From: Nathalie Jolly <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Comments to SCVP ID 17
Sender: [email-masked]

Hello David,

Thanks for your answers. Please read my comments under your answers.

David A. Cooper a �crit :
> 
> Nathalie Jolly wrote:
> 
>> 1- Some general considerations
>>
>> The abstract and introduction refer to a specification for
>> implementating DPD/DPV ("certificate path construction and validation"
>> as stated in the abstract), whereas the rest of the draft specifies 
>> certificate validation as a whole (certificate content validation + 
>> revocation status + building and validation of the certification 
>> paths, depending of the chosen checks).
>>
>> I would suggest :
>> - that you rewrite the abstract and introduction so that the purpose 
>> of the document becomes clearer (SCVP includes DPD/DPV but also deals 
>> with certificate content and revocation)
>> - that you distinguish in the text the "DPD" and the "DPV" part.
> 
> 
> I do not understand. Certificate content validation and revocation 
> status checking are part of certification path validation.

Certificate content validation and revocation status checking _may be_
part of certificate validation (it depends on the checks and validation
policy the client chooses to ask for). The abstract and introduction do
not highlight enough the fact that the SCVP protocol is modular. It
seems important that abstract and introduction define the most important
issues of the RFC.

> Where specifically in the text is there a need to distinguish between 
> the DPD part and the DPV part?  Remember that SCVP is simply one 
> protocol that can be used for both purposes.

I agree it can be used for both purposes. I meant that, in the protocol
specification, some features are clearly dedicated to discovery, and
other to validation. This could be detailed along the text.

>> 2- Validation policies, checks and validation algorithms
>>
>> 2.1- The concepts
>> If I understand correctly :
>> - checks = the validations that the client wants done,
>> - validation policy = the values that the client wants the server to use
>> while performing the checks,
>> - validation algorithm = the algorithm to be used by the server for
>> performing the checks.
>>
>> The server uses the "validation algorithm" in order to perform the
>> "checks" using the values of the "validation policy".
>>
>> My feeling is that we need to define a name for (checks + validation
>> policy + validation algorithm). They are thinly correlated with
>> one another. In my opinion, the term "validation policy" should refer as
>> the whole (checks + validation policy + validation algorithm), since the
>> word "policy" means a global strategy more than just a few numerical 
>> values.
>>
>> Especially the algorithm should be a part of the "validation policy",
>> since each algorithm is an implementation of a set of checks. We could
>> have an algorithm per check and combine algorithms for each checks
>> combination.
>>
>> Then, the chapters 5 and 6 (Server Policy request and response) would
>> send to the client the validation policies available, including checks
>> and algorithms for each response, and not two separate lists for
>> validation policies and validation algorithms.
>>
>> I read that reviewers Wen-Cheng Wang and Denis Pinkas are of this
>> opinion, at least for merging "validation policy" and "validation
>> algorithm" (maybe not for the "checks"), and I totally agree with them.
> 
> The validation algorithm is already part of the validation policy.  As 
> with other aspects of a validation policy, the validation policy defines 
> a default value and may or may not allow the client to request the use 
> of a non-default value.

When I wrote that the validation algorithm must be part of the
validation policy, I was thinking of the set of checks. The idea is that
the algorithm implements a check, and that when combining the checks,
you combine the linked algorithms.

> As for combining the checks with the validation policy, this seems like 
> a rather significant change at the last minute and it does not seem that 
> the change is necessary nor have others requested such a change, so I 
> have to assume that the working group is generally in favor of the 
> current structure.

Yes, I know timing is an issue for the draft. Maybe it is just a
question of words choice. I would save the "validation policy" concept
for the general purpose of validation strategy for the organisation
implementing SCVP, even if we do not map it in the ASN.1 structure of
the protocol. As you certainly know, words are very important and will 
never change once the draft is a RFC, whereas changing a word _now_ is 
still easy.

>> 2.2- Checks, some complementary remarks
>>
>> - �1 : Sentence "A server may choose to perform additional checks,
>> although the server cannot indicate in the response that the additional
>> checks have been performed." ->
>>
>> What happens if an error occurs for one of these additional checks ? The
>> server should be able to send back an error message, which is not
>> possible if he cannot indicate the additional check in the response. Or
>> the client will not understand why the server returns an error.
> 
> 
> This is an issue that Sharon Boeyen raised as well.  If I understand 
> correctly, she would like to have the option of returning additional 
> checks items in the replyChecks field if additional checks were 
> performed and one of those additional checks resulted in an error.  The 
> replyChecks would still be required to include all of the checks item 
> from the request, but would be allowed to include additional checks as 
> well.  We will have to raise this issue at the meeting next week to see 
> if the working group favors such a change.

I fully agree with her. I hope the working group will favor this suggestion.

>> - The text does not address the possibility of keeping the calculated
>> paths (DPD) in a cache on the server between validation queries (DPV). 
>> Certification paths should be able to be stored by the SCVP server and 
>> not calculated for each request, since they do not depend on the 
>> incoming certificate (2 certificates delivered by the same CA and been 
>> validated under the same validation policy have the same certification 
>> path at a given time). Thus, we need to state that the path building 
>> is optional, if it has been done before and if the CA / validation 
>> policy information have not been modified.
> 
> 
> This is an implementation detail and not an aspect of the protocol.  In 
> the protocol, it is clearly stated that cached responses may be allowed 
> except when the client insists on a non-cached response.  I fully expect 
> servers to cache certification paths for use in responding to future 
> queries, but (other than when sending cached responses) the server's 
> doing so should have no affect on the client's query or the server's 
> response, just the efficiency with which the server generates the 
> response, so it outside the scope of the standard.

OK.

>> Therefore, we could have checks such as "id-stc-check-pkc-path" without
>> the "build" part.
> 
> 
> The client can not include a certification path in its request (only a 
> set of certificates that the server may either use or ignore), so from 
> the client's point-of-view the server must always build a certification 
> path.  Just because the client's request includes a check asking the 
> server to build a path does not mean that the server cannot simply 
> return a previously cached path as long as the returned path satisfies 
> the client's request.
> 

OK. In my opinion, this deserves to be written down explicitly in the RFC.

>> More generally, the text should separate clearly what is the scope of 
>> DPD and what is the scope of DPV.
> 
> SCVP already states which checks are required for DPD and which are 
> required for DPV.  In draft 19, the text will state that only DPD 
> servers are required to implement id-stc-build-pkc-path and only DPV 
> servers are required to implement id-stc-build-valid-pkc-path and 
> id-stc-build-status-checked-pkc-path.

OK, good idea.

>> 2.3- Validation policies
>>
>> - Concerning the default values that can be overridden : a
>> simplification would be that the server does not return an error but
>> behaves as it should :
>>
>> We could add an attribute : are_default_values_overridable
>>
>> then the server behavior could be :
>> If (is_default_values_overridable) then :
>> - conflicts must not lead to server error
>> - and SCVP server takes new values
>> If !(is_default_values_overridable) then :
>> - conflicts must not lead to server error
>> - and SCVP server takes default values
> 
> It is my understanding that this is not the general view of the working 
> group.  There seems to be consensus that the server must either use the 
> values specified by the client or return an error.  If the server 
> indicates that a certificate is valid, but validated the certificate 
> using different input values than those requested by the client, then 
> the client may unknowingly accept a certificate that does not meet its 
> requirements.

This raises the point I already talked about, "client versus server
authority". In organisations where the need is to centralize the
validation service, the validation authority is responsible for its
answers and cannot accept the modification of parameters. The need is to
validate certificates, not to return error values...

>> - Concerning validation policy parameters :
>>
>> The parameter list should be extensible. For example, we could make use
>> of a parameter stating if the certificate to validate must be a CA
>> certificate, a Enduser certificate or any type of certificate, ...
> 
> The parameters list is extensible.  If the validation is performed using
> a validation algorithm that accepts additional parameters, then those 
> additional parameters may be specified along with the algorithm.  The 
> name validation algorithm, for example, includes additional parameters.

What I meant is that the additional parameters should be located in the
validation policy and not in the validation algorithm. They are
parameters, like "inhibitPolicyMappings" or any other that you specified
in "validationPolicy" and are used by a validation algorithm.

> At one point there was a field that allowed the client to specify that 
> the certificate to be validated must be a CA certificate or an end 
> entity certificate.  However, such a feature would have added 
> substantial complexity, so the decision was made to remove it from the 
> base standard with the understanding that this feature could always be 
> added in the future (e.g., as a new validation algorithm, a new check 
> item, an extension, etc.).

OK. This feature is a good example. It adds :
- a new check : the check for certificate type
- an extention to the validation policy : the expected value
- a new algorithm : an algorithm that is able to make the check,
whatever the expected value
The expected value (isCACert or isEndUserCert) is part of the validation
policy.
The algorithm is "expected-value independent".

> 
>> 2.4- Client versus server authority
>>
>> The text addresses the case where the client does not trust the server
>> and has to receive all the information used by the server, even if the
>> server validates the certification path, in order to be able to decide
>> not to trust the answer and query again the same or another server.
>>
>> In organisations that want to centralize their PKI policies, the
>> projects that need a SCVP server cannot have the choice to contest the
>> authoritative answer of the SCVP server. Checks and validation policies
>> are contractually defined between the client and the server and the
>> client has to accept the answer received. In this context, we need a
>> protocol that gives the server the right to refuse subsequent requests
>> (which means : "SCVP servers MAY support serverContextInfo" - instead of
>> "SHOULD")
> 
> In most cases, I would expect serverContextInfo to be used for DPD, 
> where the certification path returned to the client may not satisfy the 
> client's validation policy requirements.  The server may not validate 
> the path it is returning to the client, but may know about more than one 
> potentially acceptable certification paths.  If the first path does not 
> meet the client's requirements and the server indicates that additional 
> paths are available, this provides a method for the client to request 
> another path.
> 
> serverContextInfo is less likely to be needed for DPV since the server 
> is validating that it has found a certification path that satisfies the 
> validation policy specified by the client.  But, I do not see a 
> compelling reason to change "SHOULD" to "MAY".  "SHOULD" does not mean 
> that a server that does not implement this is non-conformant.  Also, 
> this "SHOULD" is referring to the implementation of the SCVP server 
> (i.e., the code).  It says nothing about how a given SCVP server is 
> configured, which is the issue that you are concerned about.

OK.

> 
>> 3- serverContextInfo
>>
>> I can't really understand the choice to implement this
>> "serverContextInfo" instead of letting the server send all the paths at
>> once. It means we have to keep context on the server for each query
>> (with all the subsequent questions : how long do we keep it ? do we need
>> to backup it for replay/verification purpose ?)
> 
> 
> There is an id-swb-pkc-all-cert-paths wantBack, but this may not be the 
> best option depending on how the server is implemented.  In many cases 
> the first path returned by the server will be acceptable to the client.  
> If the server had to return all paths, this would require extra 
> bandwidth and may require extra processing to compute the paths.
> 
> The subsequent questions are implementation details.  It could be that 
> the server will retain information about previous queries for which it 
> returned a serverContextInfo, where the serverContextInfo could be an 
> index into this store.  In this case, the server may store information 
> about a limited number of previous queries while deleting information 
> about old queries.  Alternatively, the server may return all the 
> information needed in serverContextInfo so that it does not need to 
> remember anything about previous queries.
> 
>> The text states that this value is used by the client if if finds the
>> response "unacceptable". What does "unacceptable mean" ? If it is
>> possible to define these "unacceptability criteria", they could be
>> implemented in the validation policy on the server, so that the server
>> gives the correct response at first query.
> 
> 
> As I said above, I believe this feature will mostly be used with DPD.  
> In this case, the server may return certification paths without 
> validating them first, so the server would not know whether the path it 
> is returning satisfies the client's validation policy or not.

OK. When I wrote that the text did not detail precisely enough what was
designed for DPD and what was designed for DPV, this is a good example
of questions that would deserve to be clarified.

> 
>> 4- basic validation algorithm errors (3.2.4.2.2)
>>
>> IIRC, the validation algorithm defined in section 6 of [PKIX-1] does not
>> contain any keyusage / revocation check. Thus, the
>> id-bvae-invalid-key-usage and id-bvae-revoked values are not used.
> 
> The validation policy includes keyUsages, which specifies requirements 
> if any for the end (or target) certificate.  If the certificate includes 
> a keyUsage extension that does not satisfy the keyUsages requirement in 
> the validation policy, then the id-bvae-invalid-key-usage is returned.

No. I re-read RFC 3280 chapter 6 and did not read anything concerning
keyUsage in the algorithm, except about keyCertSign value.

> Revocation checking must be performed by the server if the client 
> includes a check item that requires it.  Also, section 6 of RFC 3280 
> does include revocation checking:
> 
>    6.1.3  Basic Certificate Processing
> 
>       The basic path processing actions to be performed for certificate i
>       (for all i in [1..n]) are listed below.
> 
>          (a)  Verify the basic certificate information.  The certificate
>          MUST satisfy each of the following:
> 
>             (3)  At the current time, the certificate is not revoked and is
>             not on hold status.  This may be determined by obtaining the
>             appropriate CRL (section 6.3), status information, or by out-
>             of-band mechanisms.
> 

OK. My mistake.

>> 5- ValidationTime
>>
>> I am afraid I missed the "clock skew" concept. IIUC, the idea of 
>> introducing clock skew aims to solve the delay between the moment 
>> where the user revokes his certificats and the moment where the system 
>> is aware that the certificate is indeed revoked.
>>
>> How does the SCVP server behave with the "clock stew" concept ?
>>
>> - If the server builds a response concerning the state the
>> certificate was in 10 mn before the query, it increases the risk that 
>> a certificate has been revoked in the meantime and that the SVCP 
>> server is not yet aware of the revocation.
>>
>> - If the server builds a response concerning the state the
>> certificate will be in 10 mn after the query, the server has to wait 
>> 10 mn before checking the certificate and sending the response to the 
>> client.
> 
> 
> The server would never have to wait before sending the response.  
> Section 3.2.7 states "A server can ignore the validationTime provided in 
> the request if the time is within the clock skew of the server's current 
> time." So, if the specified validationTime is the current time or less 
> than 10 minutes in the past (assuming the default value), the server can 
> just respond with the status at the current time.  If the specified 
> validationTime is more than 10 minutes in the past, then validationTime 
> + 10 minutes is already in the past so the server would be able to 
> respond immediately.

This is now very very clear and correct. Could you rephrase the draft text ?

> 
>> It seems to me that the solution is not clear enough in the text.
>>
>> 6- Some minor remarks
>>
>> *** $3.2.2 : Sentence "For each check specified in the request, the 
>> SCVP server MUST perform all of the requested checks, or return an 
>> error".
>>
>> please rewrite : "For each check specified in the request, the SCVP 
>> server MUST perform the requested check, or return an error".
> 
> 
> OK.
> 
>> *** id-swb-pkc-best-cert-path : we lack a definition of what is the 
>> "best" certification path and how the choice is made by the SCVP server.
> 
> 
> This is just a name, not the description.  Besides, the path returned by 
> the server is the one that it considers "best" given the specified 
> validation policy.
> 
>> *** �3 Validation request
>> Please state that a SCVP server MUST process a protected request.
> 
> 
> Section 4 states:
> 
>   For protected requests and responses, SCVP servers MUST support
>   SignedData and SHOULD support AuthenticatedData.  It is a matter of
>   local policy which types are used.
> 
> So processing protected requests is already required.
> 
>> *** �3.2.7 validationTime
>> typo : valididationTime -> validationTime
> 
> 
> OK.
> 
> 

Best regards,
Nathalie Jolly.

-- 
Nathalie Jolly - inet6
-------------------------------------------------------------------
   o            Siege social: 51, rue de Verdun - 92 158 Suresnes
  /     _ __ _  Bureaux: 33, rue Benoit Malon - 92150 Suresnes
/ /\  /_ / /_  France
\/  \/_ / /_/  Tel. +33 (0) 1 41 44 85 45
-------------- Fax  +33 (0) 1 46 97 20 10
i n e t s y s  http://www.inet6.fr

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Date: Mon, 7 Mar 2005 08:35:56 -0500
Importance: Normal
Sender: [email-masked]

Denis,

But, that alone will not support NR in case of the Lenstra attack since cert
hash, issuer, and serial will be all the same.

I think NR claim ties to showing Lenstra paper and then showing that forcing
the subscriber to show the primes or private key to show that one of the
primes for a 2048 modulus is only 512 bits (should be around 1024 bits).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Monday, March 07, 2005 3:36 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions

Santosh,

> Some of us have suggested that the Lenstra attack does not break 
> non-repudiation. I would like to add another evidence for NR.
> 
> If there is a dispute between the signer and the relying party and the 
> signer (or CA) and the relying party produce two certificates 
> resulting in the same hash,

When RFC 3126 is used, then ESSCertID MUST be used as a signed attribute 
which means that not only there MUST be the same hash value but also the 
same CA DN and the same serial number.

    ESSCertID ::=  SEQUENCE {
         certHash                 Hash,
         issuerSerial             IssuerSerial OPTIONAL
    }

    Hash ::= OCTET STRING -- SHA1 hash of entire certificate

    IssuerSerial ::= SEQUENCE {
         issuer                   GeneralNames,
         serialNumber             CertificateSerialNumber
    }

Denis

> signer could be required to produce further evidence for the modulii 
> and one would notice that one of the factors is 512 bits for 2048 
> modulus, something FIPS does not recommend.  That would be viewed as 
> additional evidence of mischief by the subscriber.
> 
> Santosh Chokhani
> Orion Security Solutions, Inc.
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> (703) 917-0060  Ext. 35 (voice)
> (703) 917-0260 (Fax)
> [email-masked]
> Visit our Web site
> http://www.orionsec.com

Date: Mon, 07 Mar 2005 09:36:19 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

Santosh,

> Some of us have suggested that the Lenstra attack does not break
> non-repudiation. I would like to add another evidence for NR.
> 
> If there is a dispute between the signer and the relying party and the
> signer (or CA) and the relying party produce two certificates resulting in
> the same hash, 

When RFC 3126 is used, then ESSCertID MUST be used as a signed attribute 
which means that not only there MUST be the same hash value but also the 
same CA DN and the same serial number.

    ESSCertID ::=  SEQUENCE {
         certHash                 Hash,
         issuerSerial             IssuerSerial OPTIONAL
    }

    Hash ::= OCTET STRING -- SHA1 hash of entire certificate

    IssuerSerial ::= SEQUENCE {
         issuer                   GeneralNames,
         serialNumber             CertificateSerialNumber
    }

Denis

> signer could be required to produce further evidence for the
> modulii and one would notice that one of the factors is 512 bits for 2048
> modulus, something FIPS does not recommend.  That would be viewed as
> additional evidence of mischief by the subscriber.
> 
> Santosh Chokhani
> Orion Security Solutions, Inc.
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> (703) 917-0060  Ext. 35 (voice)
> (703) 917-0260 (Fax)
> [email-masked]
> Visit our Web site
> http://www.orionsec.com

Date: Sat, 05 Mar 2005 19:17:41 +0000
To: [email-masked]
From: J Adrian Pickering <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

At 18:58 04/03/2005, Robert Zuccherato wrote:
>
>The reason why the randomness in the serial number is able to prevent this 
>particular attack is that the attacker cannot predict it's value and thus 
>cannot predict the value of the hash function chaining variable at the 
>point the public keys begin to get processed.  This appears to prevent the 
>construction of collisions in the public keys.

This was why I suggested in TSP we removed the 'monotonic increasing' 
requirement for a TSA serial number during final draft. Mananaging 'random' 
serial numbers is not so easy but I rather think it is a requirement.

The attacks highlight the importance of making every bit significant in the 
message to be hashed. Aside from certificates, I've got increasingly 
worried about the non-rendered and/or highly redundant junk in documents. I 
trust logos aren't going to cause problems here.

Adrian Pickering/
University of Southampton, UK

Content-class: urn:content-classes:message
Subject: alert the PKIX working group of a potential intellectual property issue
Date: Sat, 5 Mar 2005 10:38:21 -0800
From: "John Hines" <[email-masked]>
To: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C521B2.BAEAE40C
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

To members of the IETF PKIX security working group,

=20

This message is to alert the PKIX working group of a potential
intellectual property issue associated

with U.S. Patent No. 5,717,758, "Witness-Based Certificate Revocation
System." =20

=20

It is a matter of public record that Corestreet, which owns the patent,
=66iled a lawsuit in the U.S. District=20
Court for the District of Massachusetts (Boston) (civil action #
03-10761-MLW) on April 23, 2003)=20
claiming that Valicert Inc. infringed the patent.  Corestreet filed the
lawsuit after the merger between=20
Valicert and Tumbleweed Communications Corp. had been announced, but
before the merger closed.

=20

According to Intellectual Property Rights in IETF Technology (RFC 3668),

available at http://www.ietf.org/rfc/rfc3668.txt, the events described
above and the patent referenced above, =20
need to be disclosed as part of on-going ratification of the Simple
Certificate Validation Protocol (SCVP).
SCVP draft 18 is available at
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-18.txt.

John Hines

=20

"Tumbleweed E-mail Firewall <tumbleweed.com>" made the following
 annotations on 03/05/05 10:45:17
---------------------------------------------------------------------------=
---
This e-mail, including attachments, may include confidential and/or =
proprietary information, and may be used only by the person or entity to =
which it is addressed.  If the reader of this e-mail is not the intended =
recipient or his or her authorized agent, the reader is hereby notified tha=
t=
 any dissemination, distribution or copying of this e-mail is prohibited. I=
=66=
 you have received this e-mail in error, please notify the sender by =
replying to this message and delete this e-mail immediately.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=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_01C521B2.BAEAE40C
Content-Type: text/html;
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName" downloadurl=3D"http://www.microsoft.com"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
=66ont-family:Arial'>To members of the IETF PKIX security working =
group,<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
=66ont-family:Arial'>This message is to alert the PKIX working group of a
potential intellectual property issue =
associated<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
=66ont-family:Arial'>with&nbsp;<st1:place w:st=3D"on"><st1:country-region =
w:st=3D"on">U.S.</st1:country-region></st1:place>
Patent&nbsp;No.&nbsp;5,717,758,&nbsp;&quot;Witness-Based Certificate =
Revocation
System.&quot;&nbsp; </span></font><o:p></o:p></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
=66ont-family:Arial'>It is a matter of public record that Corestreet,
which&nbsp;owns the patent,&nbsp;filed&nbsp;a lawsuit in&nbsp;the
U.S.&nbsp;District <br>
Court for the District of Massachusetts (Boston) (civil action # =
03-10761-MLW)
on&nbsp;April 23, 2003) <br>
claiming that Valicert Inc. infringed the patent.&nbsp; Corestreet filed the
lawsuit after the merger between <br>
Valicert and Tumbleweed Communications Corp. had been announced, but before=
 =
the
merger closed.</span></font><o:p></o:p></p>

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

<pre><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>According to Intellectual =
Property Rights in IETF Technology (RFC 3668),<br>
available at <a href=3D"http://www.ietf.org/rfc/rfc3668.txt"
title=3D"http://www.ietf.org/rfc/rfc3668.txt">http://www.ietf.org/rfc/rfc36=
68.txt</a>,=
 the events described above and the patent referenced above, =
&nbsp;<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>need to be disclosed as part o=
=66=
 on-going ratification of the Simple Certificate Validation Protocol =
(SCVP).<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>SCVP draft 18 is available at =
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-18.txt.<o:p></o:p>=
</span></font></pre>

<p><st1:PersonName
style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"
tabIndex=3D"0" w:st=3D"on"><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
 font-family:Arial'>John Hines</span></font></st1:PersonName><o:p></o:p></p>

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

</div>

<P>"Tumbleweed E-mail Firewall &lt;tumbleweed.com&gt;" made the =
=66ollowing<br>
 annotations on 03/05/05 10:45:17<br>
---------------------------------------------------------------------------=
---<br>
This e-mail, including attachments, may include confidential and/or =
proprietary information, and may be used only by the person or entity to =
which it is addressed.  If the reader of this e-mail is not the intended =
recipient or his or her authorized agent, the reader is hereby notified tha=
t=
 any dissemination, distribution or copying of this e-mail is prohibited. I=
=66=
 you have received this e-mail in error, please notify the sender by =
replying to this message and delete this e-mail immediately.<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=3D<br>
</P></body>

</html>

------_=_NextPart_001_01C521B2.BAEAE40C--

From: "Michael Myers" <[email-masked]>
To: "Dave Engberg" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Robert Zuccherato" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Date: Fri, 4 Mar 2005 19:53:57 -0700
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C520F3.E72EC170
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: [saag] X.509 certificate collision, via MD5 collisionsThe cited text was
authored by Dave Solo in response to an ad-hoc caucus held many years ago in
Chicago, with Mack Hicks' concurrence. Dave's text was not written to ratify
reliance on CRLs, but rather to define the meaning of "good" in the context
of OCSP.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Dave Engberg
Sent: Friday, March 04, 2005 6:16 PM
To: Stephen Kent; Robert Zuccherato
Cc: [email-masked]
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions

I think Robert was using the formal RFC 2560 definition of "good":
     The "good" state indicates a positive response to the status inquiry.
     At a minimum, this positive response indicates that the certificate
     is not revoked, but does not necessarily mean that the certificate
     was ever issued or that the time at which the response was produced
     is within the certificate's validity interval. [...]
This is slightly different than the intuitive sense of good-ness, and I
think it matches with your description.  Mr. Myers (et.al) could chime in,
but I belive this definition was specifically chosen so that a responder
could operate using only the CRL and not a DB of issued certs.  (Pre-signing
aside.)

----------------------------------------------------------------------------
----
From: Stephen Kent
Sent: Fri 3/4/2005 6:43 PM
To: Robert Zuccherato
Cc: Russ Housley; [email-masked]
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions

At 10:46 AM -0500 3/4/05, Robert Zuccherato wrote:
>       <SNIP>
>There are also some practical problems with overloading the serial
>number.  CRLs will, in most circumstances, increase in size.  Also,
>OCSP responders that pre-compute responses may have trouble
>pre-computing "good" responses if they cannot predict which serial
>numbers have been used.  This issue would come up with responders
>that work from CRLs and assume that a certificate is "good" if it's
>serial number doesn't appear on a CRL.

An OCSP responder is only supposed to indicate whether a cert is
revoked or not.  so, if the cert is not in the CRL,  it it not known
to be revoked, and if it is there is it revoked. absence from the CRL
is not necessarily an indication of a "good" cert and any inference
of that sort is an error.

Steve

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [saag] X.509 certificate collision, via MD5 =
collisions</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D984032502-05032005><FONT face=3D"Courier New" =
size=3D2>The cited=20
text was authored by Dave Solo in response to an ad-hoc caucus held many =
years=20
ago in Chicago, with Mack Hicks' concurrence.&nbsp;Dave's text was not =
written=20
to ratify reliance on CRLs, but rather to define the meaning of "good" =
in the=20
context of OCSP.</FONT></SPAN></DIV>
<DIV><SPAN class=3D984032502-05032005><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D984032502-05032005><FONT face=3D"Courier New"=20
size=3D2>Mike</FONT></SPAN></DIV>
<DIV><SPAN class=3D984032502-05032005><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3D"Courier New"=20
size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
[mailto:[email-masked]]<B>On Behalf Of </B>Dave=20
Engberg<BR><B>Sent:</B> Friday, March 04, 2005 6:16 PM<BR><B>To:</B> =
Stephen=20
Kent; Robert Zuccherato<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B> RE:=20
[saag] X.509 certificate collision, via MD5 =
collisions<BR><BR></FONT></DIV>
<DIV id=3DidOWAReplyText19260 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>I think Robert was =
using the formal=20
RFC 2560 definition of "good":</FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; The =
"good" state=20
  indicates a positive response to the status inquiry.<BR>&nbsp;&nbsp; =
At a=20
  minimum, this positive response indicates that the =
certificate<BR>&nbsp;&nbsp;=20
  is not revoked, but does not necessarily mean that the=20
  certificate<BR>&nbsp;&nbsp; was ever issued or that the time at which =
the=20
  response was produced<BR>&nbsp;&nbsp; is within the certificate's =
validity=20
  interval. [...]</FONT></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>This is slightly =
different than the=20
intuitive sense of good-ness, and I think it matches with your=20
description.&nbsp; Mr. Myers (et.al) could chime in, but I belive this=20
definition was specifically chosen so that a responder could operate =
using only=20
the CRL and not a DB of issued certs.&nbsp; (Pre-signing =
aside.)</FONT></DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV></DIV>
<DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><BR><FONT=20
face=3D"Courier New" size=3D2>
<HR tabIndex=3D-1>
</FONT><FONT face=3D"Courier New"><FONT size=3D2><B>From:</B> Stephen=20
Kent<BR><B>Sent:</B> Fri 3/4/2005 6:43 PM<BR><B>To:</B> Robert=20
Zuccherato<BR><B>Cc:</B> Russ Housley; =
[email-masked]<BR><B>Subject:</B> RE:=20
[saag] X.509 certificate collision, via MD5=20
collisions<BR><BR></FONT></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><BR>
<P><FONT face=3D"Courier New" size=3D2>At 10:46 AM -0500 3/4/05, Robert =
Zuccherato=20
wrote:<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;SNIP&gt;<BR>&gt;There are=20
also some practical problems with overloading the =
serial<BR>&gt;number.&nbsp;=20
CRLs will, in most circumstances, increase in size.&nbsp; =
Also,<BR>&gt;OCSP=20
responders that pre-compute responses may have =
trouble<BR>&gt;pre-computing=20
"good" responses if they cannot predict which serial<BR>&gt;numbers have =
been=20
used.&nbsp; This issue would come up with responders<BR>&gt;that work =
from CRLs=20
and assume that a certificate is "good" if it's<BR>&gt;serial number =
doesn't=20
appear on a CRL.<BR><BR>An OCSP responder is only supposed to indicate =
whether a=20
cert is<BR>revoked or not.&nbsp; so, if the cert is not in the =
CRL,&nbsp; it it=20
not known<BR>to be revoked, and if it is there is it revoked. absence =
from the=20
CRL<BR>is not necessarily an indication of a "good" cert and any =
inference<BR>of=20
that sort is an =
error.<BR><BR>Steve<BR><BR></FONT></P></DIV></BODY></HTML>

------=_NextPart_000_0006_01C520F3.E72EC170--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Date: Fri, 4 Mar 2005 20:19:01 -0500
Importance: Normal
Sender: [email-masked]

Some of us have suggested that the Lenstra attack does not break
non-repudiation. I would like to add another evidence for NR.

If there is a dispute between the signer and the relying party and the
signer (or CA) and the relying party produce two certificates resulting in
the same hash, signer could be required to produce further evidence for the
modulii and one would notice that one of the factors is 512 bits for 2048
modulus, something FIPS does not recommend.  That would be viewed as
additional evidence of mischief by the subscriber.

Santosh Chokhani
Orion Security Solutions, Inc.
1489 Chain Bridge Road, Suite 300
McLean, Virginia 22101
(703) 917-0060  Ext. 35 (voice)
(703) 917-0260 (Fax)
[email-masked]
Visit our Web site
http://www.orionsec.com

Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
From: Dave Engberg <[email-masked]>
To: Stephen Kent <[email-masked]>, Robert Zuccherato <[email-masked]>
Cc: <[email-masked]>
Date: Fri, 4 Mar 2005 18:15:45 -0700
Sender: [email-masked]

<HTML><HEAD><TITLE>RE: [saag] X.509 certificate collision, via MD5 collisio=
ns</TITLE></HEAD>
<BODY>
<DIV id=3DidOWAReplyText19260 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2></FONT>&nbsp;</D=
IV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I think Robert was using the for=
mal RFC 2560 definition of "good":</FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV dir=3Dltr><FONT face=3DArial size=3D2>&nbsp;&nbsp; The "good" state in=
dicates a positive response to the status inquiry.<BR>&nbsp;&nbsp; At a min=
imum, this positive response indicates that the certificate<BR>&nbsp;&nbsp;=
 is not revoked, but does not necessarily mean that the certificate<BR>&nbs=
p;&nbsp; was ever issued or that the time at which the response was produce=
d<BR>&nbsp;&nbsp; is within the certificate's validity interval. [...]</FON=
T></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>This is slightly different than =
the intuitive sense of good-ness, and I think it matches with your descript=
ion.&nbsp; Mr. Myers (et.al) could chime in, but I belive this definition w=
as specifically chosen so that a responder could operate using only the CRL=
 and not a DB of issued certs.&nbsp; (Pre-signing aside.)</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Stephen Kent<BR><B>Sent:</B> Fri =
3/4/2005 6:43 PM<BR><B>To:</B> Robert Zuccherato<BR><B>Cc:</B> Russ Housley=
; [email-masked]<BR><B>Subject:</B> RE: [saag] X.509 certificate collisi=
on, via MD5 collisions<BR></FONT><BR></DIV>
<DIV><BR>
<P><FONT size=3D2>At 10:46 AM -0500 3/4/05, Robert Zuccherato wrote:<BR>&gt=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;SNIP&gt;<BR>&gt;There are also so=
me practical problems with overloading the serial<BR>&gt;number.&nbsp; CRLs=
 will, in most circumstances, increase in size.&nbsp; Also,<BR>&gt;OCSP res=
ponders that pre-compute responses may have trouble<BR>&gt;pre-computing "g=
ood" responses if they cannot predict which serial<BR>&gt;numbers have been=
 used.&nbsp; This issue would come up with responders<BR>&gt;that work from=
 CRLs and assume that a certificate is "good" if it's<BR>&gt;serial number =
doesn't appear on a CRL.<BR><BR>An OCSP responder is only supposed to indic=
ate whether a cert is<BR>revoked or not.&nbsp; so, if the cert is not in th=
e CRL,&nbsp; it it not known<BR>to be revoked, and if it is there is it rev=
oked. absence from the CRL<BR>is not necessarily an indication of a "good" =
cert and any inference<BR>of that sort is an error.<BR><BR>Steve<BR><BR></F=
ONT></P></DIV></BODY></HTML>

Date: Fri, 4 Mar 2005 18:43:19 -0500
To: Robert Zuccherato <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Cc: "'Russ Housley'" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:46 AM -0500 3/4/05, Robert Zuccherato wrote:
>	<SNIP>
>There are also some practical problems with overloading the serial 
>number.  CRLs will, in most circumstances, increase in size.  Also, 
>OCSP responders that pre-compute responses may have trouble 
>pre-computing "good" responses if they cannot predict which serial 
>numbers have been used.  This issue would come up with responders 
>that work from CRLs and assume that a certificate is "good" if it's 
>serial number doesn't appear on a CRL.

An OCSP responder is only supposed to indicate whether a cert is 
revoked or not.  so, if the cert is not in the CRL,  it it not known 
to be revoked, and if it is there is it revoked. absence from the CRL 
is not necessarily an indication of a "good" cert and any inference 
of that sort is an error.

Steve

To: Stephen Kent <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Reply-To: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Mar 2005 15:47:36 -0800
Sender: [email-masked]

Stephen Kent <[email-masked]> writes:
> At 9:45 AM -0800 3/4/05, Paul Hoffman wrote:
>>At 10:46 AM -0500 3/4/05, Robert Zuccherato wrote:
>>> However, I really wonder if we should be recommending that people
>>> change their implementations at this point.  I don't think we know
>>> enough yet about the potential attacks on MD5, SHA-1 to say with
>>> any certainty that any particular counter-measures are worth
>>> implementing.  This infrastructure was built assuming that people
>>> will use strong hash functions.  I see no reason at this point to
>>> change that assumption.  People should have stopped using MD5 a
>>> long time ago.  Over the next couple of years they will likely have
>>> to stop using SHA-1 as well.  I think that is the real advice that
>>> we should be giving people at this time.
>>
>> The first sentence fully contradicts the last one. To use a new hash
>> algorithm is a *much* larger change than to have CAs change the
>> method they issue serial numbers; one involves changing every
>> validating client, the other doesn't.
>>
>>>There are also some practical problems with overloading the serial number.
>>
>> The term "overloading" is silly here. Before now, no one has accused
>> VeriSign of "overloading" its serial numbers.
>
> Paul,
>
> This is not entirely true.  I have noted in the past that there are
> subtle vulnerabilities associated with issuing serial numbers that are
> not serial. This is a concern with VeriSign and with the CA built into
> Microsoft desktop product as well.  Still, IF the collision problem is
> determined to be a serious concern, then I agree that changing the
> serial number generation process has much less impact than changing
> the hash algorithm.

Steve,

By "not serial" do you mean "not monotonically increasing" or do you
mean "must increase by one each time"?

Thanks,
-Ekr

Date: Fri, 04 Mar 2005 18:10:00 -0500
From: "David A. Cooper" <[email-masked]>
To: Nathalie Jolly <[email-masked]>
CC: [email-masked]
Subject: Re: Comments to SCVP ID 17
Sender: [email-masked]

Nathalie Jolly wrote:

> 1- Some general considerations
>
> The abstract and introduction refer to a specification for
> implementating DPD/DPV ("certificate path construction and validation"
> as stated in the abstract), whereas the rest of the draft specifies 
> certificate validation as a whole (certificate content validation + 
> revocation status + building and validation of the certification 
> paths, depending of the chosen checks).
>
> I would suggest :
> - that you rewrite the abstract and introduction so that the purpose 
> of the document becomes clearer (SCVP includes DPD/DPV but also deals 
> with certificate content and revocation)
> - that you distinguish in the text the "DPD" and the "DPV" part.

I do not understand. Certificate content validation and revocation 
status checking are part of certification path validation.

Where specifically in the text is there a need to distinguish between 
the DPD part and the DPV part?  Remember that SCVP is simply one 
protocol that can be used for both purposes.

> 2- Validation policies, checks and validation algorithms
>
> 2.1- The concepts
> If I understand correctly :
> - checks = the validations that the client wants done,
> - validation policy = the values that the client wants the server to use
> while performing the checks,
> - validation algorithm = the algorithm to be used by the server for
> performing the checks.
>
> The server uses the "validation algorithm" in order to perform the
> "checks" using the values of the "validation policy".
>
> My feeling is that we need to define a name for (checks + validation
> policy + validation algorithm). They are thinly correlated with
> one another. In my opinion, the term "validation policy" should refer as
> the whole (checks + validation policy + validation algorithm), since the
> word "policy" means a global strategy more than just a few numerical 
> values.
>
> Especially the algorithm should be a part of the "validation policy",
> since each algorithm is an implementation of a set of checks. We could
> have an algorithm per check and combine algorithms for each checks
> combination.
>
> Then, the chapters 5 and 6 (Server Policy request and response) would
> send to the client the validation policies available, including checks
> and algorithms for each response, and not two separate lists for
> validation policies and validation algorithms.
>
> I read that reviewers Wen-Cheng Wang and Denis Pinkas are of this
> opinion, at least for merging "validation policy" and "validation
> algorithm" (maybe not for the "checks"), and I totally agree with them.

The validation algorithm is already part of the validation policy.  As 
with other aspects of a validation policy, the validation policy defines 
a default value and may or may not allow the client to request the use 
of a non-default value.

As for combining the checks with the validation policy, this seems like 
a rather significant change at the last minute and it does not seem that 
the change is necessary nor have others requested such a change, so I 
have to assume that the working group is generally in favor of the 
current structure.

> 2.2- Checks, some complementary remarks
>
> - �1 : Sentence "A server may choose to perform additional checks,
> although the server cannot indicate in the response that the additional
> checks have been performed." ->
>
> What happens if an error occurs for one of these additional checks ? The
> server should be able to send back an error message, which is not
> possible if he cannot indicate the additional check in the response. Or
> the client will not understand why the server returns an error.

This is an issue that Sharon Boeyen raised as well.  If I understand 
correctly, she would like to have the option of returning additional 
checks items in the replyChecks field if additional checks were 
performed and one of those additional checks resulted in an error.  The 
replyChecks would still be required to include all of the checks item 
from the request, but would be allowed to include additional checks as 
well.  We will have to raise this issue at the meeting next week to see 
if the working group favors such a change.

> - The text does not address the possibility of keeping the calculated
> paths (DPD) in a cache on the server between validation queries (DPV). 
> Certification paths should be able to be stored by the SCVP server and 
> not calculated for each request, since they do not depend on the 
> incoming certificate (2 certificates delivered by the same CA and been 
> validated under the same validation policy have the same certification 
> path at a given time). Thus, we need to state that the path building 
> is optional, if it has been done before and if the CA / validation 
> policy information have not been modified.

This is an implementation detail and not an aspect of the protocol.  In 
the protocol, it is clearly stated that cached responses may be allowed 
except when the client insists on a non-cached response.  I fully expect 
servers to cache certification paths for use in responding to future 
queries, but (other than when sending cached responses) the server's 
doing so should have no affect on the client's query or the server's 
response, just the efficiency with which the server generates the 
response, so it outside the scope of the standard.

> Therefore, we could have checks such as "id-stc-check-pkc-path" without
> the "build" part.

The client can not include a certification path in its request (only a 
set of certificates that the server may either use or ignore), so from 
the client's point-of-view the server must always build a certification 
path.  Just because the client's request includes a check asking the 
server to build a path does not mean that the server cannot simply 
return a previously cached path as long as the returned path satisfies 
the client's request.

> More generally, the text should separate clearly what is the scope of 
> DPD and what is the scope of DPV.

SCVP already states which checks are required for DPD and which are 
required for DPV.  In draft 19, the text will state that only DPD 
servers are required to implement id-stc-build-pkc-path and only DPV 
servers are required to implement id-stc-build-valid-pkc-path and 
id-stc-build-status-checked-pkc-path.

> 2.3- Validation policies
>
> - Concerning the default values that can be overridden : a
> simplification would be that the server does not return an error but
> behaves as it should :
>
> We could add an attribute : are_default_values_overridable
>
> then the server behavior could be :
> If (is_default_values_overridable) then :
> - conflicts must not lead to server error
> - and SCVP server takes new values
> If !(is_default_values_overridable) then :
> - conflicts must not lead to server error
> - and SCVP server takes default values

It is my understanding that this is not the general view of the working 
group.  There seems to be consensus that the server must either use the 
values specified by the client or return an error.  If the server 
indicates that a certificate is valid, but validated the certificate 
using different input values than those requested by the client, then 
the client may unknowingly accept a certificate that does not meet its 
requirements.

> - Concerning validation policy parameters :
>
> The parameter list should be extensible. For example, we could make use
> of a parameter stating if the certificate to validate must be a CA
> certificate, a Enduser certificate or any type of certificate, ...

The parameters list is extensible.  If the validation is performed using 
a validation algorithm that accepts additional parameters, then those 
additional parameters may be specified along with the algorithm.  The 
name validation algorithm, for example, includes additional parameters.

At one point there was a field that allowed the client to specify that 
the certificate to be validated must be a CA certificate or an end 
entity certificate.  However, such a feature would have added 
substantial complexity, so the decision was made to remove it from the 
base standard with the understanding that this feature could always be 
added in the future (e.g., as a new validation algorithm, a new check 
item, an extension, etc.).

> 2.4- Client versus server authority
>
> The text addresses the case where the client does not trust the server
> and has to receive all the information used by the server, even if the
> server validates the certification path, in order to be able to decide
> not to trust the answer and query again the same or another server.
>
> In organisations that want to centralize their PKI policies, the
> projects that need a SCVP server cannot have the choice to contest the
> authoritative answer of the SCVP server. Checks and validation policies
> are contractually defined between the client and the server and the
> client has to accept the answer received. In this context, we need a
> protocol that gives the server the right to refuse subsequent requests
> (which means : "SCVP servers MAY support serverContextInfo" - instead of
> "SHOULD")

In most cases, I would expect serverContextInfo to be used for DPD, 
where the certification path returned to the client may not satisfy the 
client's validation policy requirements.  The server may not validate 
the path it is returning to the client, but may know about more than one 
potentially acceptable certification paths.  If the first path does not 
meet the client's requirements and the server indicates that additional 
paths are available, this provides a method for the client to request 
another path.

serverContextInfo is less likely to be needed for DPV since the server 
is validating that it has found a certification path that satisfies the 
validation policy specified by the client.  But, I do not see a 
compelling reason to change "SHOULD" to "MAY".  "SHOULD" does not mean 
that a server that does not implement this is non-conformant.  Also, 
this "SHOULD" is referring to the implementation of the SCVP server 
(i.e., the code).  It says nothing about how a given SCVP server is 
configured, which is the issue that you are concerned about.

> 3- serverContextInfo
>
> I can't really understand the choice to implement this
> "serverContextInfo" instead of letting the server send all the paths at
> once. It means we have to keep context on the server for each query
> (with all the subsequent questions : how long do we keep it ? do we need
> to backup it for replay/verification purpose ?)

There is an id-swb-pkc-all-cert-paths wantBack, but this may not be the 
best option depending on how the server is implemented.  In many cases 
the first path returned by the server will be acceptable to the client.  
If the server had to return all paths, this would require extra 
bandwidth and may require extra processing to compute the paths.

The subsequent questions are implementation details.  It could be that 
the server will retain information about previous queries for which it 
returned a serverContextInfo, where the serverContextInfo could be an 
index into this store.  In this case, the server may store information 
about a limited number of previous queries while deleting information 
about old queries.  Alternatively, the server may return all the 
information needed in serverContextInfo so that it does not need to 
remember anything about previous queries.

> The text states that this value is used by the client if if finds the
> response "unacceptable". What does "unacceptable mean" ? If it is
> possible to define these "unacceptability criteria", they could be
> implemented in the validation policy on the server, so that the server
> gives the correct response at first query.

As I said above, I believe this feature will mostly be used with DPD.  
In this case, the server may return certification paths without 
validating them first, so the server would not know whether the path it 
is returning satisfies the client's validation policy or not.

> 4- basic validation algorithm errors (3.2.4.2.2)
>
> IIRC, the validation algorithm defined in section 6 of [PKIX-1] does not
> contain any keyusage / revocation check. Thus, the
> id-bvae-invalid-key-usage and id-bvae-revoked values are not used.

The validation policy includes keyUsages, which specifies requirements 
if any for the end (or target) certificate.  If the certificate includes 
a keyUsage extension that does not satisfy the keyUsages requirement in 
the validation policy, then the id-bvae-invalid-key-usage is returned.

Revocation checking must be performed by the server if the client 
includes a check item that requires it.  Also, section 6 of RFC 3280 
does include revocation checking:

    6.1.3  Basic Certificate Processing

       The basic path processing actions to be performed for certificate i
       (for all i in [1..n]) are listed below.

          (a)  Verify the basic certificate information.  The certificate
          MUST satisfy each of the following:

             (3)  At the current time, the certificate is not revoked and is
             not on hold status.  This may be determined by obtaining the
             appropriate CRL (section 6.3), status information, or by out-
             of-band mechanisms.

>
> 5- ValidationTime
>
> I am afraid I missed the "clock skew" concept. IIUC, the idea of 
> introducing clock skew aims to solve the delay between the moment 
> where the user revokes his certificats and the moment where the system 
> is aware that the certificate is indeed revoked.
>
> How does the SCVP server behave with the "clock stew" concept ?
>
> - If the server builds a response concerning the state the
> certificate was in 10 mn before the query, it increases the risk that 
> a certificate has been revoked in the meantime and that the SVCP 
> server is not yet aware of the revocation.
>
> - If the server builds a response concerning the state the
> certificate will be in 10 mn after the query, the server has to wait 
> 10 mn before checking the certificate and sending the response to the 
> client.

The server would never have to wait before sending the response.  
Section 3.2.7 states "A server can ignore the validationTime provided in 
the request if the time is within the clock skew of the server's current 
time." So, if the specified validationTime is the current time or less 
than 10 minutes in the past (assuming the default value), the server can 
just respond with the status at the current time.  If the specified 
validationTime is more than 10 minutes in the past, then validationTime 
+ 10 minutes is already in the past so the server would be able to 
respond immediately.

> It seems to me that the solution is not clear enough in the text.
>
> 6- Some minor remarks
>
> *** $3.2.2 : Sentence "For each check specified in the request, the 
> SCVP server MUST perform all of the requested checks, or return an 
> error".
>
> please rewrite : "For each check specified in the request, the SCVP 
> server MUST perform the requested check, or return an error".

OK.

> *** id-swb-pkc-best-cert-path : we lack a definition of what is the 
> "best" certification path and how the choice is made by the SCVP server.

This is just a name, not the description.  Besides, the path returned by 
the server is the one that it considers "best" given the specified 
validation policy.

> *** �3 Validation request
> Please state that a SCVP server MUST process a protected request.

Section 4 states:

   For protected requests and responses, SCVP servers MUST support
   SignedData and SHOULD support AuthenticatedData.  It is a matter of
   local policy which types are used.

So processing protected requests is already required.

> *** �3.2.7 validationTime
> typo : valididationTime -> validationTime

OK.

Date: Fri, 4 Mar 2005 16:31:25 -0500
To: Paul Hoffman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Cc: [email-masked]
Sender: [email-masked]

At 9:45 AM -0800 3/4/05, Paul Hoffman wrote:
>At 10:46 AM -0500 3/4/05, Robert Zuccherato wrote:
>>However, I really wonder if we should be recommending that people 
>>change their implementations at this point.  I don't think we know 
>>enough yet about the potential attacks on MD5, SHA-1 to say with 
>>any certainty that any particular counter-measures are worth 
>>implementing.  This infrastructure was built assuming that people 
>>will use strong hash functions.  I see no reason at this point to 
>>change that assumption.  People should have stopped using MD5 a 
>>long time ago.  Over the next couple of years they will likely have 
>>to stop using SHA-1 as well.  I think that is the real advice that 
>>we should be giving people at this time.
>
>The first sentence fully contradicts the last one. To use a new hash 
>algorithm is a *much* larger change than to have CAs change the 
>method they issue serial numbers; one involves changing every 
>validating client, the other doesn't.
>
>>There are also some practical problems with overloading the serial number.
>
>The term "overloading" is silly here. Before now, no one has accused 
>VeriSign of "overloading" its serial numbers.

Paul,

This is not entirely true.  I have noted in the past that there are 
subtle vulnerabilities associated with issuing serial numbers that 
are not serial. This is a concern with VeriSign and with the CA built 
into Microsoft desktop product as well.  Still, IF the collision 
problem is determined to be a serious concern, then I agree that 
changing the serial number generation process has much less impact 
than changing the hash algorithm.

Steve

Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
From: Dave Engberg <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: <[email-masked]>
Date: Fri, 4 Mar 2005 12:36:26 -0700
Sender: [email-masked]

<HTML><HEAD><TITLE>Re: [saag] X.509 certificate collision, via MD5 collisio=
ns</TITLE></HEAD>
<BODY>
<DIV id=3DidOWAReplyText1180 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2></FONT>&nbsp;</D=
IV>
<DIV dir=3Dltr>Is the location of the randomness (before the public key) re=
levant for SHA-1, or is this only a consideration for the known MD5 attack?=
&nbsp; I.e. would Rich's proposal work fine as long as he was using SHA-1?<=
/DIV>
<DIV dir=3Dltr>&nbsp;</DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Stephen Farrell<BR><B>Sent:</B> F=
ri 3/4/2005 1:54 PM<BR><B>To:</B> Guida, Richard [JJCUS]<BR><B>Cc:</B> ietf=
[email-masked]<BR><B>Subject:</B> Re: [saag] X.509 certificate collision, vi=
a MD5 collisions<BR></FONT><BR></DIV>
<DIV><BR><BR>
<P><FONT size=3D2>Rich,<BR><BR>I believe that randomness after the public k=
ey isn't much<BR>use, but others'll know better.<BR><BR>However, instead of=
 including an extension with a random value,<BR>you could include an extens=
ion with a better hash over the<BR>rest of the TBS-cert, (e.g. using sha256=
 or better). If you<BR>just don't have any other hash algorithm available f=
or some<BR>reason, then you could add an extension which contains a<BR>rand=
om value ("V") and H("V"||TBS-cert).<BR><BR>In both cases a client that can=
 process the extension can<BR>detect problems. You can also detect bad cert=
s via filtering<BR>on e.g. an ldap server. Not sure how much of this'd be<B=
R>worthwhile though.<BR><BR>In any case, I'd agree with others who've said =
that its a<BR>bit too soon to be deciding how to fix this.<BR><BR>Next week=
's meetings should be interesting anyway!<BR>Stephen.<BR><BR>Guida, Richard=
 [JJCUS] wrote:<BR><BR>&gt; Robert - can you help me understand the substan=
ce of your last<BR>&gt; sentence?&nbsp; We are indeed considering adding a =
proprietary extension<BR>&gt; which would be populated with just random dat=
a (for certs issued by our<BR>&gt; enterprise PKI).&nbsp; Is the issue that=
 the extension appears after the<BR>&gt; public key in the TBS blob - and t=
he attack thus would work regardless<BR>&gt; of that random data?&nbsp; Tha=
nks very much.&nbsp; Wish I had more time to<BR>&gt; understand the details=
 of the attack myself, but at my age I am lucky to<BR>&gt; remember the def=
inition of the Fibonacci sequence.....<BR>&gt;&nbsp;<BR>&gt;<BR>&gt; *Richa=
rd A. Guida*<BR>&gt; *Director, Information Security*<BR>&gt;<BR>&gt; */Joh=
nson &amp; Johnson/*//<BR>&gt; Room GS8217<BR>&gt; 410 George Street<BR>&gt=
; New Brunswick, New Jersey&nbsp; 08901<BR>&gt; Phone:&nbsp; 732 524 3785<B=
R>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Original Message-----<BR>&gt;&n=
bsp;&nbsp;&nbsp;&nbsp; *From:* Robert Zuccherato [<A href=3D"mailto:robert.=
[email-masked]" target=3D_blank>mailto:[email-masked]=
m</A>]<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; *Sent:* Friday, March 04, 2005 10:46=
 AM<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; *To:* 'Russ Housley'; [email-masked]=
<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; *Subject:* RE: [saag] X.509 certificate co=
llision, via MD5 collisions<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; I'd lik=
e to comment on the following suggestion from Russ:<BR>&gt;<BR>&gt;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; &gt; In the past, I have recommended the use of larg=
e serial numbers<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; where the first=
 part is a monotonically increasing integer and<BR>&gt;&nbsp;&nbsp;&nbsp;&n=
bsp; the second<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; part is random.&=
nbsp; A 64-bit random value should thwart this attack.<BR>&gt;<BR>&gt;&nbsp=
;&nbsp;&nbsp;&nbsp; This idea has a number of good points.&nbsp; It seems t=
hat a CA that<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; includes randomness in its se=
rial number would be able to prevent<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; collis=
ions like the one produced by Lenstra,<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nb=
sp; Wang and de Wegner.&nbsp; Including the randomness in the serial number=
<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; in the way that has been suggested is also=
 nice because it's done in<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; such a way that =
PKIX conformant applications shouldn't choke on<BR>&gt;&nbsp;&nbsp;&nbsp;&n=
bsp; them.&nbsp; A CA can also continue to issue serial numbers using<BR>&g=
t;&nbsp;&nbsp;&nbsp;&nbsp; monotonically increasing values, or any other sc=
heme that they wish<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; to use, in the non-rand=
om part.<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; However, I really wonder i=
f we should be recommending that people<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; cha=
nge their implementations at this point.&nbsp; I don't think we know<BR>&gt=
;&nbsp;&nbsp;&nbsp;&nbsp; enough yet about the potential attacks on MD5, SH=
A-1 to say with any<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; certainty that any part=
icular counter-measures are worth<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; implement=
ing.&nbsp; This infrastructure was built assuming that people<BR>&gt;&nbsp;=
&nbsp;&nbsp;&nbsp; will use strong hash functions.&nbsp; I see no reason at=
 this point to<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; change that assumption.&nbsp=
; People should have stopped using MD5 a long<BR>&gt;&nbsp;&nbsp;&nbsp;&nbs=
p; time ago.&nbsp; Over the next couple of years they will likely have to<B=
R>&gt;&nbsp;&nbsp;&nbsp;&nbsp; stop using SHA-1 as well.&nbsp; I think that=
 is the real advice that we<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; should be givin=
g people at this time.<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; There are al=
so some practical problems with overloading the serial<BR>&gt;&nbsp;&nbsp;&=
nbsp;&nbsp; number.&nbsp; CRLs will, in most circumstances, increase in siz=
e.&nbsp; Also,<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; OCSP responders that pre-com=
pute responses may have trouble<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; pre-computi=
ng "good" responses if they cannot predict which serial<BR>&gt;&nbsp;&nbsp;=
&nbsp;&nbsp; numbers have been used.&nbsp; This issue would come up with re=
sponders<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; that work from CRLs and assume tha=
t a certificate is "good" if it's<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; serial nu=
mber doesn't appear on a CRL.<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; I'd a=
lso like to point out that the serial number proposal would<BR>&gt;&nbsp;&n=
bsp;&nbsp;&nbsp; only help X.509 certificates and not CRLs, RFC 3161 time s=
tamp<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; tokens (there was already a message to=
 the CFRG list today showing<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; how to extend =
the MD5 X.509 work to 3161 tokens), OCSP responses,<BR>&gt;&nbsp;&nbsp;&nbs=
p;&nbsp; etc.&nbsp; One might consider defining a non-critical extension th=
at<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; would simply contain a random integer of=
 an appropriate size that is<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; freshly genera=
ted by the signer at signing time.&nbsp; But, I don't<BR>&gt;&nbsp;&nbsp;&n=
bsp;&nbsp; believe that would solve the problem.&nbsp; Once the collision h=
as been<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; produced using the public keys, any=
thing added to the certificate<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; after that (=
i.e., an extension) will also produce a collision.<BR>&gt;<BR>&gt;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Robert Zucc=
herato.<BR>&gt;<BR><BR></FONT></P></DIV></BODY></HTML>

From: "todd glassey" <[email-masked]>
To: "Robert Zuccherato" <[email-masked]>, "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Date: Fri, 4 Mar 2005 11:17:49 -0800
Sender: [email-masked]

This is a multi-part message in MIME format.

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

RE: [saag] X.509 certificate collision, via MD5 collisionsIf use models =
had been required in the x509 standards team and here as well this would =
be much less of an issue if at all.

Todd=20
  ----- Original Message -----=20
  From: Robert Zuccherato=20
  To: 'Russ Housley' ; [email-masked]=20
  Sent: Friday, March 04, 2005 7:46 AM
  Subject: RE: [saag] X.509 certificate collision, via MD5 collisions

  I'd like to comment on the following suggestion from Russ:=20

  > In the past, I have recommended the use of large serial numbers=20
  > where the first part is a monotonically increasing integer and the =
second=20
  > part is random.  A 64-bit random value should thwart this attack. =20

  This idea has a number of good points.  It seems that a CA that =
includes randomness in its serial number would be able to prevent =
collisions like the one produced by Lenstra,=20

  Wang and de Wegner.  Including the randomness in the serial number in =
the way that has been suggested is also nice because it's done in such a =
way that PKIX conformant applications shouldn't choke on them.  A CA can =
also continue to issue serial numbers using monotonically increasing =
values, or any other scheme that they wish to use, in the non-random =
part. =20

  However, I really wonder if we should be recommending that people =
change their implementations at this point.  I don't think we know =
enough yet about the potential attacks on MD5, SHA-1 to say with any =
certainty that any particular counter-measures are worth implementing.  =
This infrastructure was built assuming that people will use strong hash =
functions.  I see no reason at this point to change that assumption.  =
People should have stopped using MD5 a long time ago.  Over the next =
couple of years they will likely have to stop using SHA-1 as well.  I =
think that is the real advice that we should be giving people at this =
time.

  There are also some practical problems with overloading the serial =
number.  CRLs will, in most circumstances, increase in size.  Also, OCSP =
responders that pre-compute responses may have trouble pre-computing =
"good" responses if they cannot predict which serial numbers have been =
used.  This issue would come up with responders that work from CRLs and =
assume that a certificate is "good" if it's serial number doesn't appear =
on a CRL.

  I'd also like to point out that the serial number proposal would only =
help X.509 certificates and not CRLs, RFC 3161 time stamp tokens (there =
was already a message to the CFRG list today showing how to extend the =
MD5 X.509 work to 3161 tokens), OCSP responses, etc.  One might consider =
defining a non-critical extension that would simply contain a random =
integer of an appropriate size that is freshly generated by the signer =
at signing time.  But, I don't believe that would solve the problem.  =
Once the collision has been produced using the public keys, anything =
added to the certificate after that (i.e., an extension) will also =
produce a collision.

          Robert Zuccherato.=20

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [saag] X.509 certificate collision, via MD5 =
collisions</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT face=3DArial size=3D2>If use models had been required in the =
x509=20
standards team and here as well this would be much less of an issue if =
at=20
all.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Todd </FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Robert Zuccherato</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">'Russ Housley'</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">[email-masked]</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, March 04, 2005 =
7:46=20
AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [saag] X.509 =
certificate=20
  collision, via MD5 collisions</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>I'd like to comment on the following suggestion from =

  Russ:</FONT> </P>
  <P><FONT size=3D2>&gt; In the past, I have recommended the use of =
large serial=20
  numbers </FONT><BR><FONT size=3D2>&gt; where the first part is a =
monotonically=20
  increasing integer and the second </FONT><BR><FONT size=3D2>&gt; part =
is=20
  random.&nbsp; A 64-bit random value should thwart this attack.&nbsp;=20
  </FONT></P>
  <P><FONT size=3D2>This idea has a number of good points.&nbsp; It =
seems that a=20
  CA that includes randomness in its serial number would be able to =
prevent=20
  collisions like the one produced by Lenstra, </FONT></P>
  <P><FONT size=3D2>Wang and de Wegner.&nbsp; Including the randomness =
in the=20
  serial number in the way that has been suggested is also nice because =
it's=20
  done in such a way that PKIX conformant applications shouldn't choke =
on=20
  them.&nbsp; A CA can also continue to issue serial numbers using =
monotonically=20
  increasing values, or any other scheme that they wish to use, in the=20
  non-random part.&nbsp; </FONT></P>
  <P><FONT size=3D2>However, I really wonder if we should be =
recommending that=20
  people change their implementations at this point.&nbsp; I don't think =
we know=20
  enough yet about the potential attacks on MD5, SHA-1 to say with any =
certainty=20
  that any particular counter-measures are worth implementing.&nbsp; =
This=20
  infrastructure was built assuming that people will use strong hash=20
  functions.&nbsp; I see no reason at this point to change that=20
  assumption.&nbsp; People should have stopped using MD5 a long time =
ago.&nbsp;=20
  Over the next couple of years they will likely have to stop using =
SHA-1 as=20
  well.&nbsp; I think that is the real advice that we should be giving =
people at=20
  this time.</FONT></P>
  <P><FONT size=3D2>There are also some practical problems with =
overloading the=20
  serial number.&nbsp; CRLs will, in most circumstances, increase in =
size.&nbsp;=20
  Also, OCSP responders that pre-compute responses may have trouble=20
  pre-computing "good" responses if they cannot predict which serial =
numbers=20
  have been used.&nbsp; This issue would come up with responders that =
work from=20
  CRLs and assume that a certificate is "good" if it's serial number =
doesn't=20
  appear on a CRL.</FONT></P>
  <P><FONT size=3D2>I'd also like to point out that the serial number =
proposal=20
  would only help X.509 certificates and not CRLs, RFC 3161 time stamp =
tokens=20
  (there was already a message to the CFRG list today showing how to =
extend the=20
  MD5 X.509 work to 3161 tokens), OCSP responses, etc.&nbsp; One might =
consider=20
  defining a non-critical extension that would simply contain a random =
integer=20
  of an appropriate size that is freshly generated by the signer at =
signing=20
  time.&nbsp; But, I don't believe that would solve the problem.&nbsp; =
Once the=20
  collision has been produced using the public keys, anything added to =
the=20
  certificate after that (i.e., an extension) will also produce a=20
  collision.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=3D2>Robert=20
  Zuccherato.</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0679_01C520AB.CCAF3CA0--

Date: Fri, 04 Mar 2005 14:08:27 -0500
From: "David A. Cooper" <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: SCVP Draft 17: Summary of changes
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------010105090502010805070407
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Peter Sylvester wrote:

>>> Is there a particular reason to have a NULL in the keyusages and not just
>>> an empty sequence as here?
>>>
>>>      
>>>
>>Yes.  extendedKeyUsages is defined as a sequence in which the end 
>>certificate must satisfy ALL of the elements of the sequence.  If the 
>>sequence if empty, then the end certificate trivially satisfies this.
>>
>>keyUsages is defined as a sequence in which the end certificate must 
>>satisfy AT LEAST ONE of the elements of the sequence.  If the sequence 
>>were empty, it would not be possible for the certificate to satisfy at 
>>least one element from the sequence.
>>    
>>
>
>Not only in mathematics a red herring may neither be red nor a herring. An empty
>set trivially full fills any condition.
>
You asked me the reason that I encoded keyUsages the way that I did and 
so I explained.  Just because you don't agree with my reasoning is no 
reason to be insulting.

Of course, if the working group indicates a preference for a different 
encoding, I will change it, but I have not heard anyone else suggest 
that this needs to be changed.

>I had actually been tempted to change requestorRef to be a sequence of 
>GeneralName since GeneralName seemed to be more appropriate than OCTET 
>STRING for something that was supposed to hold an identifier.  A side 
>effect of this change is that it would have specified the encodings for 
>the identifiers as well.  However, there was a comment submitted for 
>draft 16 indicating a need to be able to use a hash value as an 
>identifier in requestorRef, an option that would have been effectively 
>precluded if OCTET STRING had been changed to GeneralName.  Since I 
>could not justify preventing use of a hash value and one can easily 
>encode any GeneralName value in an OCTET STRING, I left the syntax for 
>requestorRef unchanged.
>  
>
>
>Since you could not justify it, well then, yes, that's important ... :) 
>And, you didn't even feel that this would have been worth to be
>discussed a little bit.
>  
>
As I see it, my responsibility as an editor is to do my best to ensure 
that the final document is technically correct and represents rough 
working group consensus.  That means that I should not be making changes 
to the protocol simply for stylistic reasons just because one person 
would prefer to see the change made, even if that person is me.

>There is nothing in 3379 that requires that you must be able to encode
>a hash value.
>  
>
That's probably true, but not the point.  Its not as if I unilaterally 
changed the protocol to enable the encoding of hash values in 
requestorRef.  I'm just saying that I would have been in favor of making 
such a change, but could not because I had reason to believe that some 
members of the working group would be against such a change, whereas I 
didn't know of anyone who felt that the change was needed.

I am really confused by your argument that I should have made a 
unilateral change simply because the option that I would have been 
removing is not mandated by 3379.  First, as you have said before, just 
because something is not mandated by 3379 does not mean that it can't be 
included in SCVP.  Second, YOU are the one who expressed a desire to be 
able to encode a hash value in requestorRef 
(http://www.imc.org/ietf-pkix/mail-archive/msg01739.html). 

>>I think this is more of a theoretical concern than a practical concern.  
>>The odds that two servers that are part of the same SCVP relay network 
>>would select different identifiers for use in requestorRef, but that as 
>>a result of using different encoding techniques the encoded versions of 
>>their names are the same are extremely small.
>>    
>>
>
>There are also various ways to encode a hash value into a GeneralName,
>so it is wrong that this has been effectively precluded. Waht IS actually
>precluded is that these identifiers can have a structure following any
>global name space and you have no collisions using encoding.
>
While it is trivial to convert something that would have been encoded as 
GeneralName to an OCTET STRING (just place the DER encoding of the name 
in the octet string), I am not aware of any currently defined method for 
encoding a hash value in GeneralName.  Certainly one could define an 
attribute for inclusion in a directoryName or one could define a new 
name form to go in otherName, but that doesn't seem very practical.

>> believe that SCVP already includes all of the basic fields needed to 
>>support relay.  I don't believe that the base document needs to say any 
>>more.  When a server implements relay, it sends out an CVRequest and 
>>gets back a CVResponse just as a normal client would.  Guidance on what 
>>queries a server should send and what it should do with the response is 
>>just that.  Guidance on how to use a particular feature does not need to 
>>be in the base standard, it can be in a separate informational 
>>document.  If there is a desire for SCVP servers that implement relay to 
>>exchange auxiliary information, that information can always be included 
>>in non-critical response extensions.  So, I can not see any reason to 
>>hold up the base standard.  There are too many people who need this 
>>standard to be completed and who can use it even without guidance on how 
>>to implement relay.
>>    
>>
>
>There is no exchange of AUXILIARY information. The requirements say
>clearly that the client can request that the server returns ALL
>information. The base text allows for relaying.
>
>The current text does not honor this requierement of 3379.
>  
>
Please specify exactly where in 3379 there is a requirement that the 
current text does not honor.  I do see the following in section 4.2:

   - 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

To me, this means that any information in the request or response that 
is specific to relay MUST be auxiliary information in that the recipient 
must be able to process the message even if this information is ignored.

>what you are suggesting, is to totally ignore relaying in the base
>document which is contrary to what had been announced by Trevor, i.e. 
>to specify how a relay would act, nothing had been changed. 
>After having discussed that this is needed several months ago, 
>and with agreement from Trevor, it is really surprising that
>you haven't made your observation earlier.
>  
>
If Trevor agreed to make a change to the document that was not made, I 
am not aware of it.  If there was a prior agreement to make a change to 
the document and the change was not made, then I'll work with Trevor to 
add the necessary text.  I am expressing my own opinions on this matter 
based on my knowledge of the situation.

>Thus, as you admit, the text does not at all contain information about how 
>
>- a relay should take a request from a client and transform it into
>  a request to another server;
>  At least it is already said one modification is to add the loop
>  control.
>  
>
Support for loop detection is mandated by 3379:

   - When a server supports a relay mechanism, a mechanism to detect
     loops or repetition MUST be provided.

So, it is clear that this must be included in the protocol.  In SCVP, it 
is included in such a way that it can be ignored by clients and servers 
that do not support relay.

There no reason for the standard to state how to transform a request 
from a client  into a request to another server.  The protocol already 
specifies the rules for generating requests and the rules for generating 
responses.  These rules apply whether the requester is the end client or 
a relaying server.  How the server computes the response is a local 
matter and thus not something that needs to be standardized.  The 
contents of the response do need to be standardized and they are.  If a 
server wants to call upon the resources of another SCVP server to help 
answer a question, it may do that, but the contents of that request 
message are irrelevant as long as the request conforms to the rules 
specified in section 3 for SCVP requests.

An SCVP server that receives a DPV request could in turn send either a 
DPV or DPD request to another server.  The request could ask for 
revocation status checking if that was required by the client or the 
server could ask for just the certification path and then perform 
revocation status checking itself.  As long as it provides the correct 
response to the client, it does not matter.

So, any information about how to transform a request from a client into 
a request to another server would be informative not normative, and so 
it does not need to be included in the base standard.  It is my 
understanding that Tim Polk has proposed that you write a separate, 
informative document describing how relay can be used.

>- the result of the request could be returned as is with just the
>  security envelope changed. But then the client does not have
>  the important information required to show to a third party.
>  
>
What information would the client be required to show to a third party 
that is not provided.  In the case of DPD, the client is performing the 
validation itself and so would certainly have any evidence needed to 
show to a third party.  In the case of DPV, the client is indicating 
that it trusts the server.  If the signed response from the server is 
not sufficient evidence to show to a third party, then the client needs 
to request more information from the server (e.g., require the server to 
include the certification path in the response).   What does relay have 
to do with this?  What if the server you sent to request to didn't even 
use relay to compute the response?  Are you saying that a server might 
be REQUIRED to use relay in order to generate a response, not because 
the server is unable to compute the response on its own but because some 
evidence would be created as a result of performing relay that is needed 
by the client to later show to a third party and that evidence could not 
be created without relay?  If so, then I do not see anything in 3379 to 
justify this type of requirement.  If not, then I don't see how it could 
be in the case that relay was used that the client would be required to 
have information about the relay to show to a third party.

Dave

--------------010105090502010805070407
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Sylvester wrote:
<blockquote cite="[email-masked]"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap=""> Is there a particular reason to have a NULL in the keyusages and not just
 an empty sequence as here?

      </pre>
    </blockquote>
    <pre wrap="">Yes.  extendedKeyUsages is defined as a sequence in which the end 
certificate must satisfy ALL of the elements of the sequence.  If the 
sequence if empty, then the end certificate trivially satisfies this.

keyUsages is defined as a sequence in which the end certificate must 
satisfy AT LEAST ONE of the elements of the sequence.  If the sequence 
were empty, it would not be possible for the certificate to satisfy at 
least one element from the sequence.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Not only in mathematics a red herring may neither be red nor a herring. An empty
set trivially full fills any condition.</pre>
</blockquote>
You asked me the reason that I encoded keyUsages the way that I did and
so I explained.&nbsp; Just because you don't agree with my reasoning is no
reason to be insulting.<br>
<br>
Of course, if the working group indicates a preference for a different
encoding, I will change it, but I have not heard anyone else suggest
that this needs to be changed.
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">I had actually been tempted to change requestorRef to be a sequence of 
GeneralName since GeneralName seemed to be more appropriate than OCTET 
STRING for something that was supposed to hold an identifier.  A side 
effect of this change is that it would have specified the encodings for 
the identifiers as well.  However, there was a comment submitted for 
draft 16 indicating a need to be able to use a hash value as an 
identifier in requestorRef, an option that would have been effectively 
precluded if OCTET STRING had been changed to GeneralName.  Since I 
could not justify preventing use of a hash value and one can easily 
encode any GeneralName value in an OCTET STRING, I left the syntax for 
requestorRef unchanged.
  </pre>
</blockquote>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap=""></pre>
  <pre wrap=""></pre>
  <pre wrap=""><!---->
Since you could not justify it, well then, yes, that's important ... :) 
And, you didn't even feel that this would have been worth to be
discussed a little bit.
  </pre>
</blockquote>
As I see it, my responsibility as an editor is to do my best to ensure
that the final document is technically correct and represents rough
working group consensus.&nbsp; That means that I should not be making
changes to the protocol simply for stylistic reasons just because one
person would prefer to see the change made, even if that person is me.<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">There is nothing in 3379 that requires that you must be able to encode
a hash value.
  </pre>
</blockquote>
That's probably true, but not the point.&nbsp; Its not as if I unilaterally
changed the protocol to enable the encoding of hash values in
requestorRef.&nbsp; I'm just saying that I would have been in favor of
making such a change, but could not because I had reason to believe
that some members of the working group would be against such a change,
whereas I didn't know of anyone who felt that the change was needed.<br>
<br>
I am really confused by your argument that I should have made a
unilateral change simply because the option that I would have been
removing is not mandated by 3379.&nbsp; First, as you have said before, just
because something is not mandated by 3379 does not mean that it can't
be included in SCVP.&nbsp; Second, YOU are the one who expressed a desire to
be able to encode a hash value in requestorRef
(<a class="moz-txt-link-freetext" href="http://www.imc.org/ietf-pkix/mail-archive/msg01739.html">http://www.imc.org/ietf-pkix/mail-archive/msg01739.html</a>).&nbsp; <br>
<blockquote cite="[email-masked]"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">I think this is more of a theoretical concern than a practical concern.  
The odds that two servers that are part of the same SCVP relay network 
would select different identifiers for use in requestorRef, but that as 
a result of using different encoding techniques the encoded versions of 
their names are the same are extremely small.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
There are also various ways to encode a hash value into a GeneralName,
so it is wrong that this has been effectively precluded. Waht IS actually
precluded is that these identifiers can have a structure following any
global name space and you have no collisions using encoding.</pre>
</blockquote>
While it is trivial to convert something that would have been encoded
as GeneralName to an OCTET STRING (just place the DER encoding of the
name in the octet string), I am not aware of any currently defined
method for encoding a hash value in GeneralName.&nbsp; Certainly one could
define an attribute for inclusion in a directoryName or one could
define a new name form to go in otherName, but that doesn't seem very
practical.<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap=""> believe that SCVP already includes all of the basic fields needed to 
support relay.  I don't believe that the base document needs to say any 
more.  When a server implements relay, it sends out an CVRequest and 
gets back a CVResponse just as a normal client would.  Guidance on what 
queries a server should send and what it should do with the response is 
just that.  Guidance on how to use a particular feature does not need to 
be in the base standard, it can be in a separate informational 
document.  If there is a desire for SCVP servers that implement relay to 
exchange auxiliary information, that information can always be included 
in non-critical response extensions.  So, I can not see any reason to 
hold up the base standard.  There are too many people who need this 
standard to be completed and who can use it even without guidance on how 
to implement relay.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
There is no exchange of AUXILIARY information. The requirements say
clearly that the client can request that the server returns ALL
information. The base text allows for relaying.

The current text does not honor this requierement of 3379.
  </pre>
</blockquote>
Please specify exactly where in 3379 there is a requirement that the
current text does not honor.&nbsp; I do see the following in section 4.2:<br>
<br>
&nbsp;&nbsp; - Optional parameters in the protocol request and/or response MAY be<br>
&nbsp;&nbsp;&nbsp;&nbsp; provide support for relaying, re-direction or multicasting.&nbsp; DPV<br>
&nbsp;&nbsp;&nbsp;&nbsp; clients that ignore any such optional parameters MUST be able to<br>
&nbsp;&nbsp;&nbsp;&nbsp; use the DPV service.&nbsp; DPV servers that ignore any such optional<br>
&nbsp;&nbsp;&nbsp;&nbsp; parameters MUST still be able to offer the DPV service<br>
<br>
To me, this means that any information in the request or response that
is specific to relay MUST be auxiliary information in that the
recipient must be able to process the message even if this information
is ignored.<br>
<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">what you are suggesting, is to totally ignore relaying in the base
document which is contrary to what had been announced by Trevor, i.e. 
to specify how a relay would act, nothing had been changed. 
After having discussed that this is needed several months ago, 
and with agreement from Trevor, it is really surprising that
you haven't made your observation earlier.
  </pre>
</blockquote>
If Trevor agreed to make a change to the document that was not made, I
am not aware of it.&nbsp; If there was a prior agreement to make a change to
the document and the change was not made, then I'll work with Trevor to
add the necessary text.&nbsp; I am expressing my own opinions on this matter
based on my knowledge of the situation.<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">Thus, as you admit, the text does not at all contain information about how 

- a relay should take a request from a client and transform it into
  a request to another server;
  At least it is already said one modification is to add the loop
  control.
  </pre>
</blockquote>
Support for loop detection is mandated by 3379:<br>
<br>
&nbsp;&nbsp; - When a server supports a relay mechanism, a mechanism to detect<br>
&nbsp;&nbsp;&nbsp;&nbsp; loops or repetition MUST be provided.<br>
<br>
So, it is clear that this must be included in the protocol.&nbsp; In SCVP,
it is included in such a way that it can be ignored by clients and
servers that do not support relay.<br>
<br>
There no reason for the standard to state how to transform a request
from a client&nbsp; into a request to another server.&nbsp; The protocol already
specifies the rules for generating requests and the rules for
generating responses.&nbsp; These rules apply whether the requester is the
end client or a relaying server.&nbsp; How the server computes the response
is a local matter and thus not something that needs to be
standardized.&nbsp; The contents of the response do need to be standardized
and they are.&nbsp; If a server wants to call upon the resources of another
SCVP server to help answer a question, it may do that, but the contents
of that request message are irrelevant as long as the request conforms
to the rules specified in section 3 for SCVP requests.<br>
<br>
An SCVP server that receives a DPV request could in turn send either a
DPV or DPD request to another server.&nbsp; The request could ask for
revocation status checking if that was required by the client or the
server could ask for just the certification path and then perform
revocation status checking itself.&nbsp; As long as it provides the correct
response to the client, it does not matter.<br>
<br>
So, any information about how to transform a request from a client into
a request to another server would be informative not normative, and so
it does not need to be included in the base standard.&nbsp; It is my
understanding that Tim Polk has proposed that you write a separate,
informative document describing how relay can be used.<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">
- the result of the request could be returned as is with just the
  security envelope changed. But then the client does not have
  the important information required to show to a third party.
  </pre>
</blockquote>
What information would the client be required to show to a third party
that is not provided.&nbsp; In the case of DPD, the client is performing the
validation itself and so would certainly have any evidence needed to
show to a third party.&nbsp; In the case of DPV, the client is indicating
that it trusts the server.&nbsp; If the signed response from the server is
not sufficient evidence to show to a third party, then the client needs
to request more information from the server (e.g., require the server
to include the certification path in the response).&nbsp;&nbsp; What does relay
have to do with this?&nbsp; What if the server you sent to request to didn't
even use relay to compute the response?&nbsp; Are you saying that a server
might be REQUIRED to use relay in order to generate a response, not
because the server is unable to compute the response on its own but
because some evidence would be created as a result of performing relay
that is needed by the client to later show to a third party and that
evidence could not be created without relay?&nbsp; If so, then I do not see
anything in 3379 to justify this type of requirement.&nbsp; If not, then I
don't see how it could be in the case that relay was used that the
client would be required to have information about the relay to show to
a third party.<br>
<br>
Dave<br>
<br>
</body>
</html>

--------------010105090502010805070407--

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Date: Fri, 4 Mar 2005 14:08:41 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C520ED.946DD796
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks very much, Stephen; excellent idea on using an extension that just
includes a stronger hash.  As you noted, we are not in crisis mode, but we
are following this area closely and if a consensus forms about the best way
to deal with the matter until a stronger hashing function emerges (outside
the SHA family), then we certainly want to consider it.  Migrating to
SHA-256 or SHA-512 is certainly fine and also in the plans.  Thanks again --
Rich

Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  732 524 3785

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Friday, March 04, 2005 1:55 PM
To: Guida, Richard [JJCUS]
Cc: [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions

Rich,

I believe that randomness after the public key isn't much
use, but others'll know better.

However, instead of including an extension with a random value,
you could include an extension with a better hash over the
rest of the TBS-cert, (e.g. using sha256 or better). If you
just don't have any other hash algorithm available for some
reason, then you could add an extension which contains a
random value ("V") and H("V"||TBS-cert).

In both cases a client that can process the extension can
detect problems. You can also detect bad certs via filtering
on e.g. an ldap server. Not sure how much of this'd be
worthwhile though.

In any case, I'd agree with others who've said that its a
bit too soon to be deciding how to fix this.

Next week's meetings should be interesting anyway!
Stephen.

Guida, Richard [JJCUS] wrote:

> Robert - can you help me understand the substance of your last 
> sentence?  We are indeed considering adding a proprietary extension 
> which would be populated with just random data (for certs issued by our 
> enterprise PKI).  Is the issue that the extension appears after the 
> public key in the TBS blob - and the attack thus would work regardless 
> of that random data?  Thanks very much.  Wish I had more time to 
> understand the details of the attack myself, but at my age I am lucky to 
> remember the definition of the Fibonacci sequence.....
>  
> 
> *Richard A. Guida*
> *Director, Information Security*
> 
> */Johnson & Johnson/*//
> Room GS8217
> 410 George Street
> New Brunswick, New Jersey  08901
> Phone:  732 524 3785
> 
>     -----Original Message-----
>     *From:* Robert Zuccherato [mailto:[email-masked]]
>     *Sent:* Friday, March 04, 2005 10:46 AM
>     *To:* 'Russ Housley'; [email-masked]
>     *Subject:* RE: [saag] X.509 certificate collision, via MD5 collisions
> 
>     I'd like to comment on the following suggestion from Russ:
> 
>      > In the past, I have recommended the use of large serial numbers
>      > where the first part is a monotonically increasing integer and
>     the second
>      > part is random.  A 64-bit random value should thwart this attack. 
> 
>     This idea has a number of good points.  It seems that a CA that
>     includes randomness in its serial number would be able to prevent
>     collisions like the one produced by Lenstra,
> 
>     Wang and de Wegner.  Including the randomness in the serial number
>     in the way that has been suggested is also nice because it's done in
>     such a way that PKIX conformant applications shouldn't choke on
>     them.  A CA can also continue to issue serial numbers using
>     monotonically increasing values, or any other scheme that they wish
>     to use, in the non-random part. 
> 
>     However, I really wonder if we should be recommending that people
>     change their implementations at this point.  I don't think we know
>     enough yet about the potential attacks on MD5, SHA-1 to say with any
>     certainty that any particular counter-measures are worth
>     implementing.  This infrastructure was built assuming that people
>     will use strong hash functions.  I see no reason at this point to
>     change that assumption.  People should have stopped using MD5 a long
>     time ago.  Over the next couple of years they will likely have to
>     stop using SHA-1 as well.  I think that is the real advice that we
>     should be giving people at this time.
> 
>     There are also some practical problems with overloading the serial
>     number.  CRLs will, in most circumstances, increase in size.  Also,
>     OCSP responders that pre-compute responses may have trouble
>     pre-computing "good" responses if they cannot predict which serial
>     numbers have been used.  This issue would come up with responders
>     that work from CRLs and assume that a certificate is "good" if it's
>     serial number doesn't appear on a CRL.
> 
>     I'd also like to point out that the serial number proposal would
>     only help X.509 certificates and not CRLs, RFC 3161 time stamp
>     tokens (there was already a message to the CFRG list today showing
>     how to extend the MD5 X.509 work to 3161 tokens), OCSP responses,
>     etc.  One might consider defining a non-critical extension that
>     would simply contain a random integer of an appropriate size that is
>     freshly generated by the signer at signing time.  But, I don't
>     believe that would solve the problem.  Once the collision has been
>     produced using the public keys, anything added to the certificate
>     after that (i.e., an extension) will also produce a collision.
> 
>             Robert Zuccherato.
> 

------_=_NextPart_001_01C520ED.946DD796
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.88">
<TITLE>RE: [saag] X.509 certificate collision, via MD5 =
collisions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Thanks very much, Stephen; excellent idea on using an =
extension that just includes a stronger hash.&nbsp; As you noted, we =
are not in crisis mode, but we are following this area closely and if a =
consensus forms about the best way to deal with the matter until a =
stronger hashing function emerges (outside the SHA family), then we =
certainly want to consider it.&nbsp; Migrating to SHA-256 or SHA-512 is =
certainly fine and also in the plans.&nbsp; Thanks again -- =
Rich</FONT></P>
<BR>

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

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stephen Farrell [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked].=
ie</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, March 04, 2005 1:55 PM</FONT>
<BR><FONT SIZE=3D2>To: Guida, Richard [JJCUS]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [saag] X.509 certificate collision, via =
MD5 collisions</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Rich,</FONT>
</P>

<P><FONT SIZE=3D2>I believe that randomness after the public key isn't =
much</FONT>
<BR><FONT SIZE=3D2>use, but others'll know better.</FONT>
</P>

<P><FONT SIZE=3D2>However, instead of including an extension with a =
random value,</FONT>
<BR><FONT SIZE=3D2>you could include an extension with a better hash =
over the</FONT>
<BR><FONT SIZE=3D2>rest of the TBS-cert, (e.g. using sha256 or better). =
If you</FONT>
<BR><FONT SIZE=3D2>just don't have any other hash algorithm available =
for some</FONT>
<BR><FONT SIZE=3D2>reason, then you could add an extension which =
contains a</FONT>
<BR><FONT SIZE=3D2>random value (&quot;V&quot;) and =
H(&quot;V&quot;||TBS-cert).</FONT>
</P>

<P><FONT SIZE=3D2>In both cases a client that can process the extension =
can</FONT>
<BR><FONT SIZE=3D2>detect problems. You can also detect bad certs via =
filtering</FONT>
<BR><FONT SIZE=3D2>on e.g. an ldap server. Not sure how much of this'd =
be</FONT>
<BR><FONT SIZE=3D2>worthwhile though.</FONT>
</P>

<P><FONT SIZE=3D2>In any case, I'd agree with others who've said that =
its a</FONT>
<BR><FONT SIZE=3D2>bit too soon to be deciding how to fix this.</FONT>
</P>

<P><FONT SIZE=3D2>Next week's meetings should be interesting =
anyway!</FONT>
<BR><FONT SIZE=3D2>Stephen.</FONT>
</P>

<P><FONT SIZE=3D2>Guida, Richard [JJCUS] wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Robert - can you help me understand the =
substance of your last </FONT>
<BR><FONT SIZE=3D2>&gt; sentence?&nbsp; We are indeed considering =
adding a proprietary extension </FONT>
<BR><FONT SIZE=3D2>&gt; which would be populated with just random data =
(for certs issued by our </FONT>
<BR><FONT SIZE=3D2>&gt; enterprise PKI).&nbsp; Is the issue that the =
extension appears after the </FONT>
<BR><FONT SIZE=3D2>&gt; public key in the TBS blob - and the attack =
thus would work regardless </FONT>
<BR><FONT SIZE=3D2>&gt; of that random data?&nbsp; Thanks very =
much.&nbsp; Wish I had more time to </FONT>
<BR><FONT SIZE=3D2>&gt; understand the details of the attack myself, =
but at my age I am lucky to </FONT>
<BR><FONT SIZE=3D2>&gt; remember the definition of the Fibonacci =
sequence.....</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; *Richard A. Guida*</FONT>
<BR><FONT SIZE=3D2>&gt; *Director, Information Security*</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; */Johnson &amp; Johnson/*//</FONT>
<BR><FONT SIZE=3D2>&gt; Room GS8217</FONT>
<BR><FONT SIZE=3D2>&gt; 410 George Street</FONT>
<BR><FONT SIZE=3D2>&gt; New Brunswick, New Jersey&nbsp; 08901</FONT>
<BR><FONT SIZE=3D2>&gt; Phone:&nbsp; 732 524 3785</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; *From:* Robert =
Zuccherato [<A =
HREF=3D"mailto:[email-masked]">mailto:robert.zuccherato@e=
ntrust.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; *Sent:* Friday, March =
04, 2005 10:46 AM</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; *To:* 'Russ Housley'; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; *Subject:* RE: [saag] =
X.509 certificate collision, via MD5 collisions</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; I'd like to comment on =
the following suggestion from Russ:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; In the past, =
I have recommended the use of large serial numbers</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; where the =
first part is a monotonically increasing integer and</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; the second</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; part is =
random.&nbsp; A 64-bit random value should thwart this attack. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; This idea has a number =
of good points.&nbsp; It seems that a CA that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; includes randomness in =
its serial number would be able to prevent</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; collisions like the one =
produced by Lenstra,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Wang and de =
Wegner.&nbsp; Including the randomness in the serial number</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; in the way that has =
been suggested is also nice because it's done in</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; such a way that PKIX =
conformant applications shouldn't choke on</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; them.&nbsp; A CA can =
also continue to issue serial numbers using</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; monotonically =
increasing values, or any other scheme that they wish</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; to use, in the =
non-random part. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; However, I really =
wonder if we should be recommending that people</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; change their =
implementations at this point.&nbsp; I don't think we know</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; enough yet about the =
potential attacks on MD5, SHA-1 to say with any</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; certainty that any =
particular counter-measures are worth</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; implementing.&nbsp; =
This infrastructure was built assuming that people</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; will use strong hash =
functions.&nbsp; I see no reason at this point to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; change that =
assumption.&nbsp; People should have stopped using MD5 a long</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; time ago.&nbsp; Over =
the next couple of years they will likely have to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; stop using SHA-1 as =
well.&nbsp; I think that is the real advice that we</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; should be giving people =
at this time.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; There are also some =
practical problems with overloading the serial</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; number.&nbsp; CRLs =
will, in most circumstances, increase in size.&nbsp; Also,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; OCSP responders that =
pre-compute responses may have trouble</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; pre-computing =
&quot;good&quot; responses if they cannot predict which serial</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; numbers have been =
used.&nbsp; This issue would come up with responders</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; that work from CRLs and =
assume that a certificate is &quot;good&quot; if it's</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; serial number doesn't =
appear on a CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; I'd also like to point =
out that the serial number proposal would</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; only help X.509 =
certificates and not CRLs, RFC 3161 time stamp</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; tokens (there was =
already a message to the CFRG list today showing</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; how to extend the MD5 =
X.509 work to 3161 tokens), OCSP responses,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; etc.&nbsp; One might =
consider defining a non-critical extension that</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; would simply contain a =
random integer of an appropriate size that is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; freshly generated by =
the signer at signing time.&nbsp; But, I don't</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; believe that would =
solve the problem.&nbsp; Once the collision has been</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; produced using the =
public keys, anything added to the certificate</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; after that (i.e., an =
extension) will also produce a collision.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; Robert Zuccherato.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C520ED.946DD796--

From: Robert Zuccherato <[email-masked]>
To: "'Guida, Richard [JJCUS]'" <[email-masked]>, "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Date: Fri, 4 Mar 2005 13:58:15 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C520EC.1F09D08E
Content-Type: text/plain

Yes, the two public keys are produced so that after they are processed there
is a collision in the hash function chaining variable.  Anything added after
this point will similarly produce a collision, as long as the same data is
added to both.  Thus, even if the CA includes randomness after the public
key in the TBS blob, an identical certificate with the second public key
will produce the same hash, and thus the same signature.
 
The reason why the randomness in the serial number is able to prevent this
particular attack is that the attacker cannot predict it's value and thus
cannot predict the value of the hash function chaining variable at the point
the public keys begin to get processed.  This appears to prevent the
construction of collisions in the public keys.
 
    Robert.

-----Original Message-----
From: Guida, Richard [JJCUS] [mailto:[email-masked]] 
Sent: March 4, 2005 1:31 PM
To: Robert Zuccherato; 'Russ Housley'; [email-masked]
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions

Robert - can you help me understand the substance of your last sentence?  We
are indeed considering adding a proprietary extension which would be
populated with just random data (for certs issued by our enterprise PKI).
Is the issue that the extension appears after the public key in the TBS blob
- and the attack thus would work regardless of that random data?  Thanks
very much.  Wish I had more time to understand the details of the attack
myself, but at my age I am lucky to remember the definition of the Fibonacci
sequence.....

Richard A. Guida 
Director, Information Security 

Johnson & Johnson 
Room GS8217 
410 George Street 
New Brunswick, New Jersey  08901 
Phone:  732 524 3785 

-----Original Message-----
From: Robert Zuccherato [mailto:[email-masked]]
Sent: Friday, March 04, 2005 10:46 AM
To: 'Russ Housley'; [email-masked]
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions

I'd like to comment on the following suggestion from Russ: 

> In the past, I have recommended the use of large serial numbers 
> where the first part is a monotonically increasing integer and the second 
> part is random.  A 64-bit random value should thwart this attack.  

This idea has a number of good points.  It seems that a CA that includes
randomness in its serial number would be able to prevent collisions like the
one produced by Lenstra, 

Wang and de Wegner.  Including the randomness in the serial number in the
way that has been suggested is also nice because it's done in such a way
that PKIX conformant applications shouldn't choke on them.  A CA can also
continue to issue serial numbers using monotonically increasing values, or
any other scheme that they wish to use, in the non-random part.  

However, I really wonder if we should be recommending that people change
their implementations at this point.  I don't think we know enough yet about
the potential attacks on MD5, SHA-1 to say with any certainty that any
particular counter-measures are worth implementing.  This infrastructure was
built assuming that people will use strong hash functions.  I see no reason
at this point to change that assumption.  People should have stopped using
MD5 a long time ago.  Over the next couple of years they will likely have to
stop using SHA-1 as well.  I think that is the real advice that we should be
giving people at this time.

There are also some practical problems with overloading the serial number.
CRLs will, in most circumstances, increase in size.  Also, OCSP responders
that pre-compute responses may have trouble pre-computing "good" responses
if they cannot predict which serial numbers have been used.  This issue
would come up with responders that work from CRLs and assume that a
certificate is "good" if it's serial number doesn't appear on a CRL.

I'd also like to point out that the serial number proposal would only help
X.509 certificates and not CRLs, RFC 3161 time stamp tokens (there was
already a message to the CFRG list today showing how to extend the MD5 X.509
work to 3161 tokens), OCSP responses, etc.  One might consider defining a
non-critical extension that would simply contain a random integer of an
appropriate size that is freshly generated by the signer at signing time.
But, I don't believe that would solve the problem.  Once the collision has
been produced using the public keys, anything added to the certificate after
that (i.e., an extension) will also produce a collision.

        Robert Zuccherato. 

------_=_NextPart_001_01C520EC.1F09D08E
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2900.2604" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#800000 size=2><SPAN class=403044118-04032005>Yes, 
the two public keys are produced so that after they are processed there is a 
collision in the hash function chaining variable.&nbsp; Anything added after 
this point will similarly produce a collision, as long as the same data is added 
to both.&nbsp; Thus, even if the CA includes randomness after the public key in 
the TBS blob, an identical certificate with the second public key will produce 
the same hash, and thus the same signature.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#800000 size=2><SPAN 
class=403044118-04032005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#800000 size=2><SPAN class=403044118-04032005>The 
reason why the randomness in the serial number is able to prevent this 
particular attack is that the attacker cannot predict it's value and thus cannot 
predict the value of the hash function chaining variable at the point the public 
keys begin to get processed.&nbsp; This appears to prevent the construction of 
collisions in the public keys.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#800000 size=2><SPAN 
class=403044118-04032005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#800000 size=2><SPAN 
class=403044118-04032005>&nbsp;&nbsp;&nbsp; Robert.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Guida, Richard 
  [JJCUS] [mailto:[email-masked]] <BR><B>Sent:</B> March 4, 2005 1:31 
  PM<BR><B>To:</B> Robert Zuccherato; 'Russ Housley'; 
  [email-masked]<BR><B>Subject:</B> RE: [saag] X.509 certificate collision, 
  via MD5 collisions<BR><BR></FONT></DIV>
  <DIV><SPAN class=268362618-04032005><FONT face=Arial color=#0000ff 
  size=2>Robert - can you help me understand the substance of your last 
  sentence?&nbsp; We are indeed considering adding a proprietary extension which 
  would be populated with just random data (for certs issued by our enterprise 
  PKI).&nbsp; Is the issue that the extension appears after the public key in 
  the TBS blob - and the attack thus would work regardless of that random 
  data?&nbsp; Thanks very much.&nbsp; Wish I had more time to understand the 
  details of the attack myself, but at my age I am lucky to remember the 
  definition of the Fibonacci sequence.....</FONT></SPAN></DIV>
  <DIV><SPAN class=268362618-04032005><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV><BR>
  <P><B><FONT face=Arial size=2>Richard A. Guida</FONT></B> <BR><B><FONT 
  face=Arial size=2>Director, Information Security</FONT></B> </P>
  <P><B><I><FONT face="Times New Roman" color=#ff0000 size=5>Johnson &amp; 
  Johnson</FONT></I></B><I></I> <BR><FONT face=Arial size=2>Room GS8217</FONT> 
  <BR><FONT face=Arial size=2>410 George Street</FONT> <BR><FONT face=Arial 
  size=2>New Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT face=Arial 
  size=2>Phone:&nbsp; 732 524 3785</FONT> </P>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Robert Zuccherato 
    [mailto:[email-masked]]<BR><B>Sent:</B> Friday, March 04, 
    2005 10:46 AM<BR><B>To:</B> 'Russ Housley'; 
    [email-masked]<BR><B>Subject:</B> RE: [saag] X.509 certificate collision, 
    via MD5 collisions<BR><BR></FONT></DIV>
    <P><FONT size=2>I'd like to comment on the following suggestion from 
    Russ:</FONT> </P>
    <P><FONT size=2>&gt; In the past, I have recommended the use of large serial 
    numbers </FONT><BR><FONT size=2>&gt; where the first part is a monotonically 
    increasing integer and the second </FONT><BR><FONT size=2>&gt; part is 
    random.&nbsp; A 64-bit random value should thwart this attack.&nbsp; 
    </FONT></P>
    <P><FONT size=2>This idea has a number of good points.&nbsp; It seems that a 
    CA that includes randomness in its serial number would be able to prevent 
    collisions like the one produced by Lenstra, </FONT></P>
    <P><FONT size=2>Wang and de Wegner.&nbsp; Including the randomness in the 
    serial number in the way that has been suggested is also nice because it's 
    done in such a way that PKIX conformant applications shouldn't choke on 
    them.&nbsp; A CA can also continue to issue serial numbers using 
    monotonically increasing values, or any other scheme that they wish to use, 
    in the non-random part.&nbsp; </FONT></P>
    <P><FONT size=2>However, I really wonder if we should be recommending that 
    people change their implementations at this point.&nbsp; I don't think we 
    know enough yet about the potential attacks on MD5, SHA-1 to say with any 
    certainty that any particular counter-measures are worth implementing.&nbsp; 
    This infrastructure was built assuming that people will use strong hash 
    functions.&nbsp; I see no reason at this point to change that 
    assumption.&nbsp; People should have stopped using MD5 a long time 
    ago.&nbsp; Over the next couple of years they will likely have to stop using 
    SHA-1 as well.&nbsp; I think that is the real advice that we should be 
    giving people at this time.</FONT></P>
    <P><FONT size=2>There are also some practical problems with overloading the 
    serial number.&nbsp; CRLs will, in most circumstances, increase in 
    size.&nbsp; Also, OCSP responders that pre-compute responses may have 
    trouble pre-computing "good" responses if they cannot predict which serial 
    numbers have been used.&nbsp; This issue would come up with responders that 
    work from CRLs and assume that a certificate is "good" if it's serial number 
    doesn't appear on a CRL.</FONT></P>
    <P><FONT size=2>I'd also like to point out that the serial number proposal 
    would only help X.509 certificates and not CRLs, RFC 3161 time stamp tokens 
    (there was already a message to the CFRG list today showing how to extend 
    the MD5 X.509 work to 3161 tokens), OCSP responses, etc.&nbsp; One might 
    consider defining a non-critical extension that would simply contain a 
    random integer of an appropriate size that is freshly generated by the 
    signer at signing time.&nbsp; But, I don't believe that would solve the 
    problem.&nbsp; Once the collision has been produced using the public keys, 
    anything added to the certificate after that (i.e., an extension) will also 
    produce a collision.</FONT></P>
    <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Robert 
    Zuccherato.</FONT> </P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C520EC.1F09D08E--

Date: Fri, 04 Mar 2005 18:54:37 +0000
From: Stephen Farrell <[email-masked]>
To: "Guida, Richard [JJCUS]" <[email-masked]>
Cc: [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

Rich,

I believe that randomness after the public key isn't much
use, but others'll know better.

However, instead of including an extension with a random value,
you could include an extension with a better hash over the
rest of the TBS-cert, (e.g. using sha256 or better). If you
just don't have any other hash algorithm available for some
reason, then you could add an extension which contains a
random value ("V") and H("V"||TBS-cert).

In both cases a client that can process the extension can
detect problems. You can also detect bad certs via filtering
on e.g. an ldap server. Not sure how much of this'd be
worthwhile though.

In any case, I'd agree with others who've said that its a
bit too soon to be deciding how to fix this.

Next week's meetings should be interesting anyway!
Stephen.

Guida, Richard [JJCUS] wrote:

> Robert - can you help me understand the substance of your last 
> sentence?  We are indeed considering adding a proprietary extension 
> which would be populated with just random data (for certs issued by our 
> enterprise PKI).  Is the issue that the extension appears after the 
> public key in the TBS blob - and the attack thus would work regardless 
> of that random data?  Thanks very much.  Wish I had more time to 
> understand the details of the attack myself, but at my age I am lucky to 
> remember the definition of the Fibonacci sequence.....
>  
> 
> *Richard A. Guida*
> *Director, Information Security*
> 
> */Johnson & Johnson/*//
> Room GS8217
> 410 George Street
> New Brunswick, New Jersey  08901
> Phone:  732 524 3785
> 
>     -----Original Message-----
>     *From:* Robert Zuccherato [mailto:[email-masked]]
>     *Sent:* Friday, March 04, 2005 10:46 AM
>     *To:* 'Russ Housley'; [email-masked]
>     *Subject:* RE: [saag] X.509 certificate collision, via MD5 collisions
> 
>     I'd like to comment on the following suggestion from Russ:
> 
>      > In the past, I have recommended the use of large serial numbers
>      > where the first part is a monotonically increasing integer and
>     the second
>      > part is random.  A 64-bit random value should thwart this attack. 
> 
>     This idea has a number of good points.  It seems that a CA that
>     includes randomness in its serial number would be able to prevent
>     collisions like the one produced by Lenstra,
> 
>     Wang and de Wegner.  Including the randomness in the serial number
>     in the way that has been suggested is also nice because it's done in
>     such a way that PKIX conformant applications shouldn't choke on
>     them.  A CA can also continue to issue serial numbers using
>     monotonically increasing values, or any other scheme that they wish
>     to use, in the non-random part. 
> 
>     However, I really wonder if we should be recommending that people
>     change their implementations at this point.  I don't think we know
>     enough yet about the potential attacks on MD5, SHA-1 to say with any
>     certainty that any particular counter-measures are worth
>     implementing.  This infrastructure was built assuming that people
>     will use strong hash functions.  I see no reason at this point to
>     change that assumption.  People should have stopped using MD5 a long
>     time ago.  Over the next couple of years they will likely have to
>     stop using SHA-1 as well.  I think that is the real advice that we
>     should be giving people at this time.
> 
>     There are also some practical problems with overloading the serial
>     number.  CRLs will, in most circumstances, increase in size.  Also,
>     OCSP responders that pre-compute responses may have trouble
>     pre-computing "good" responses if they cannot predict which serial
>     numbers have been used.  This issue would come up with responders
>     that work from CRLs and assume that a certificate is "good" if it's
>     serial number doesn't appear on a CRL.
> 
>     I'd also like to point out that the serial number proposal would
>     only help X.509 certificates and not CRLs, RFC 3161 time stamp
>     tokens (there was already a message to the CFRG list today showing
>     how to extend the MD5 X.509 work to 3161 tokens), OCSP responses,
>     etc.  One might consider defining a non-critical extension that
>     would simply contain a random integer of an appropriate size that is
>     freshly generated by the signer at signing time.  But, I don't
>     believe that would solve the problem.  Once the collision has been
>     produced using the public keys, anything added to the certificate
>     after that (i.e., an extension) will also produce a collision.
> 
>             Robert Zuccherato.
> 

From: "Guida, Richard [JJCUS]" <[email-masked]>
To: Robert Zuccherato <[email-masked]>, "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Date: Fri, 4 Mar 2005 13:31:20 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C520E8.5C6E033E
Content-Type: text/plain;
	charset="iso-8859-1"

Robert - can you help me understand the substance of your last sentence?  We
are indeed considering adding a proprietary extension which would be
populated with just random data (for certs issued by our enterprise PKI).
Is the issue that the extension appears after the public key in the TBS blob
- and the attack thus would work regardless of that random data?  Thanks
very much.  Wish I had more time to understand the details of the attack
myself, but at my age I am lucky to remember the definition of the Fibonacci
sequence.....

Richard A. Guida 
Director, Information Security 

Johnson & Johnson 
Room GS8217 
410 George Street 
New Brunswick, New Jersey  08901 
Phone:  732 524 3785 

-----Original Message-----
From: Robert Zuccherato [mailto:[email-masked]]
Sent: Friday, March 04, 2005 10:46 AM
To: 'Russ Housley'; [email-masked]
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions

I'd like to comment on the following suggestion from Russ: 

> In the past, I have recommended the use of large serial numbers 
> where the first part is a monotonically increasing integer and the second 
> part is random.  A 64-bit random value should thwart this attack.  

This idea has a number of good points.  It seems that a CA that includes
randomness in its serial number would be able to prevent collisions like the
one produced by Lenstra, 

Wang and de Wegner.  Including the randomness in the serial number in the
way that has been suggested is also nice because it's done in such a way
that PKIX conformant applications shouldn't choke on them.  A CA can also
continue to issue serial numbers using monotonically increasing values, or
any other scheme that they wish to use, in the non-random part.  

However, I really wonder if we should be recommending that people change
their implementations at this point.  I don't think we know enough yet about
the potential attacks on MD5, SHA-1 to say with any certainty that any
particular counter-measures are worth implementing.  This infrastructure was
built assuming that people will use strong hash functions.  I see no reason
at this point to change that assumption.  People should have stopped using
MD5 a long time ago.  Over the next couple of years they will likely have to
stop using SHA-1 as well.  I think that is the real advice that we should be
giving people at this time.

There are also some practical problems with overloading the serial number.
CRLs will, in most circumstances, increase in size.  Also, OCSP responders
that pre-compute responses may have trouble pre-computing "good" responses
if they cannot predict which serial numbers have been used.  This issue
would come up with responders that work from CRLs and assume that a
certificate is "good" if it's serial number doesn't appear on a CRL.

I'd also like to point out that the serial number proposal would only help
X.509 certificates and not CRLs, RFC 3161 time stamp tokens (there was
already a message to the CFRG list today showing how to extend the MD5 X.509
work to 3161 tokens), OCSP responses, etc.  One might consider defining a
non-critical extension that would simply contain a random integer of an
appropriate size that is freshly generated by the signer at signing time.
But, I don't believe that would solve the problem.  Once the collision has
been produced using the public keys, anything added to the certificate after
that (i.e., an extension) will also produce a collision.

        Robert Zuccherato. 

------_=_NextPart_001_01C520E8.5C6E033E
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [saag] X.509 certificate collision, via MD5 collisions</TITLE>

<META content="MSHTML 6.00.2800.1492" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=268362618-04032005><FONT face=Arial color=#0000ff size=2>Robert 
- can you help me understand the substance of your last sentence?&nbsp; We are 
indeed considering adding a proprietary extension which would be populated with 
just random data (for certs issued by our enterprise PKI).&nbsp; Is the issue 
that the extension appears after the public key in the TBS blob - and the attack 
thus would work regardless of that random data?&nbsp; Thanks very much.&nbsp; 
Wish I had more time to understand the details of the attack myself, but at my 
age I am lucky to remember the definition of the Fibonacci 
sequence.....</FONT></SPAN></DIV>
<DIV><SPAN class=268362618-04032005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV><BR>
<P><B><FONT face=Arial size=2>Richard A. Guida</FONT></B> <BR><B><FONT 
face=Arial size=2>Director, Information Security</FONT></B> </P>
<P><B><I><FONT face="Times New Roman" color=#ff0000 size=5>Johnson &amp; 
Johnson</FONT></I></B><I></I> <BR><FONT face=Arial size=2>Room GS8217</FONT> 
<BR><FONT face=Arial size=2>410 George Street</FONT> <BR><FONT face=Arial 
size=2>New Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT face=Arial 
size=2>Phone:&nbsp; 732 524 3785</FONT> </P>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Robert Zuccherato 
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, March 04, 2005 
  10:46 AM<BR><B>To:</B> 'Russ Housley'; [email-masked]<BR><B>Subject:</B> 
  RE: [saag] X.509 certificate collision, via MD5 
collisions<BR><BR></FONT></DIV>
  <P><FONT size=2>I'd like to comment on the following suggestion from 
  Russ:</FONT> </P>
  <P><FONT size=2>&gt; In the past, I have recommended the use of large serial 
  numbers </FONT><BR><FONT size=2>&gt; where the first part is a monotonically 
  increasing integer and the second </FONT><BR><FONT size=2>&gt; part is 
  random.&nbsp; A 64-bit random value should thwart this attack.&nbsp; 
  </FONT></P>
  <P><FONT size=2>This idea has a number of good points.&nbsp; It seems that a 
  CA that includes randomness in its serial number would be able to prevent 
  collisions like the one produced by Lenstra, </FONT></P>
  <P><FONT size=2>Wang and de Wegner.&nbsp; Including the randomness in the 
  serial number in the way that has been suggested is also nice because it's 
  done in such a way that PKIX conformant applications shouldn't choke on 
  them.&nbsp; A CA can also continue to issue serial numbers using monotonically 
  increasing values, or any other scheme that they wish to use, in the 
  non-random part.&nbsp; </FONT></P>
  <P><FONT size=2>However, I really wonder if we should be recommending that 
  people change their implementations at this point.&nbsp; I don't think we know 
  enough yet about the potential attacks on MD5, SHA-1 to say with any certainty 
  that any particular counter-measures are worth implementing.&nbsp; This 
  infrastructure was built assuming that people will use strong hash 
  functions.&nbsp; I see no reason at this point to change that 
  assumption.&nbsp; People should have stopped using MD5 a long time ago.&nbsp; 
  Over the next couple of years they will likely have to stop using SHA-1 as 
  well.&nbsp; I think that is the real advice that we should be giving people at 
  this time.</FONT></P>
  <P><FONT size=2>There are also some practical problems with overloading the 
  serial number.&nbsp; CRLs will, in most circumstances, increase in size.&nbsp; 
  Also, OCSP responders that pre-compute responses may have trouble 
  pre-computing "good" responses if they cannot predict which serial numbers 
  have been used.&nbsp; This issue would come up with responders that work from 
  CRLs and assume that a certificate is "good" if it's serial number doesn't 
  appear on a CRL.</FONT></P>
  <P><FONT size=2>I'd also like to point out that the serial number proposal 
  would only help X.509 certificates and not CRLs, RFC 3161 time stamp tokens 
  (there was already a message to the CFRG list today showing how to extend the 
  MD5 X.509 work to 3161 tokens), OCSP responses, etc.&nbsp; One might consider 
  defining a non-critical extension that would simply contain a random integer 
  of an appropriate size that is freshly generated by the signer at signing 
  time.&nbsp; But, I don't believe that would solve the problem.&nbsp; Once the 
  collision has been produced using the public keys, anything added to the 
  certificate after that (i.e., an extension) will also produce a 
  collision.</FONT></P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2>Robert 
  Zuccherato.</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C520E8.5C6E033E--

Content-class: urn:content-classes:message
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Date: Fri, 4 Mar 2005 18:10:02 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Robert Zuccherato" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C520E5.6E5A2D2D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree that it is too early to specify specific countermeasures and I
also believe that we start walking a somewhat tricky and dangerous path
if we start to specify specific rules to construct data objects to be
hashed. Certificates are just one of many hashed objects in the chain of
a securing a signed message or transaction.

Stefan Santesson=20
Microsoft Security Center of Excellence (SCOE)=20
 =20

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Robert Zuccherato
Sent: den 4 mars 2005 16:46
To: 'Russ Housley'; [email-masked]
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions

=20

I'd like to comment on the following suggestion from Russ:=20

> In the past, I have recommended the use of large serial numbers=20
> where the first part is a monotonically increasing integer and the
second=20
> part is random.  A 64-bit random value should thwart this attack. =20

This idea has a number of good points.  It seems that a CA that includes
randomness in its serial number would be able to prevent collisions like
the one produced by Lenstra,=20

Wang and de Wegner.  Including the randomness in the serial number in
the way that has been suggested is also nice because it's done in such a
way that PKIX conformant applications shouldn't choke on them.  A CA can
also continue to issue serial numbers using monotonically increasing
values, or any other scheme that they wish to use, in the non-random
part. =20

However, I really wonder if we should be recommending that people change
their implementations at this point.  I don't think we know enough yet
about the potential attacks on MD5, SHA-1 to say with any certainty that
any particular counter-measures are worth implementing.  This
infrastructure was built assuming that people will use strong hash
functions.  I see no reason at this point to change that assumption.
People should have stopped using MD5 a long time ago.  Over the next
couple of years they will likely have to stop using SHA-1 as well.  I
think that is the real advice that we should be giving people at this
time.

There are also some practical problems with overloading the serial
number.  CRLs will, in most circumstances, increase in size.  Also, OCSP
responders that pre-compute responses may have trouble pre-computing
"good" responses if they cannot predict which serial numbers have been
used.  This issue would come up with responders that work from CRLs and
assume that a certificate is "good" if it's serial number doesn't appear
on a CRL.

I'd also like to point out that the serial number proposal would only
help X.509 certificates and not CRLs, RFC 3161 time stamp tokens (there
was already a message to the CFRG list today showing how to extend the
MD5 X.509 work to 3161 tokens), OCSP responses, etc.  One might consider
defining a non-critical extension that would simply contain a random
integer of an appropriate size that is freshly generated by the signer
at signing time.  But, I don't believe that would solve the problem.
Once the collision has been produced using the public keys, anything
added to the certificate after that (i.e., an extension) will also
produce a collision.

        Robert Zuccherato.=20

------_=_NextPart_001_01C520E5.6E5A2D2D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<title>RE: [saag] X.509 certificate collision, via MD5 =
collisions</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0cm;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I agree that it =
is too
early to specify specific countermeasures and I also believe that we =
start
walking a somewhat tricky and dangerous path if we start to specify =
specific rules
to construct data objects to be hashed. Certificates are just one of =
many
hashed objects in the chain of a securing a signed message or =
transaction.</span></font></p>

<div>

<p><b><font size=3D2 color=3Dolive face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
 10.0pt;font-family:Arial;color:olive;font-weight:bold'>Stefan =
Santesson</span></font></b><font
color=3Dnavy><span lang=3DEN-GB style=3D'color:navy'> <br>
</span></font><font size=3D2 color=3Dolive face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Microsoft =
Security Center of Excellence (SCOE)</span></font><font =
color=3Dnavy><span lang=3DEN-GB
style=3D'color:navy'> <br>
</span></font><font color=3Dnavy face=3DArial><span lang=3DEN-GB =
style=3D'font-family:
Arial;color:navy'>&nbsp;</span></font><font color=3Dnavy><span =
lang=3DEN-GB
style=3D'color:navy'> </span></font></p>

</div>

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Robert Zuccherato<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 4 mars 2005 =
16:46<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Russ Housley';
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [saag] X.509
certificate collision, via MD5 collisions</span></font></p>

</div>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>I'd like
to comment on the following suggestion from Russ:</span></font> </p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt; In
the past, I have recommended the use of large serial numbers =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; where the first =
part is a
monotonically increasing integer and the second </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; part is =
random.&nbsp; A 64-bit
random value should thwart this attack.&nbsp; </span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>This idea
has a number of good points.&nbsp; It seems that a CA that includes =
randomness
in its serial number would be able to prevent collisions like the one =
produced
by Lenstra, </span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Wang and
de Wegner.&nbsp; Including the randomness in the serial number in the =
way that
has been suggested is also nice because it's done in such a way that =
PKIX
conformant applications shouldn't choke on them.&nbsp; A CA can also =
continue
to issue serial numbers using monotonically increasing values, or any =
other
scheme that they wish to use, in the non-random part.&nbsp; =
</span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>However,
I really wonder if we should be recommending that people change their
implementations at this point.&nbsp; I don't think we know enough yet =
about the
potential attacks on MD5, SHA-1 to say with any certainty that any =
particular
counter-measures are worth implementing.&nbsp; This infrastructure was =
built
assuming that people will use strong hash functions.&nbsp; I see no =
reason at
this point to change that assumption.&nbsp; People should have stopped =
using
MD5 a long time ago.&nbsp; Over the next couple of years they will =
likely have
to stop using SHA-1 as well.&nbsp; I think that is the real advice that =
we
should be giving people at this time.</span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>There are
also some practical problems with overloading the serial number.&nbsp; =
CRLs
will, in most circumstances, increase in size.&nbsp; Also, OCSP =
responders that
pre-compute responses may have trouble pre-computing &quot;good&quot; =
responses
if they cannot predict which serial numbers have been used.&nbsp; This =
issue
would come up with responders that work from CRLs and assume that a =
certificate
is &quot;good&quot; if it's serial number doesn't appear on a =
CRL.</span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>I'd also
like to point out that the serial number proposal would only help X.509
certificates and not CRLs, RFC 3161 time stamp tokens (there was already =
a
message to the CFRG list today showing how to extend the MD5 X.509 work =
to 3161
tokens), OCSP responses, etc.&nbsp; One might consider defining a =
non-critical
extension that would simply contain a random integer of an appropriate =
size
that is freshly generated by the signer at signing time.&nbsp; But, I =
don't
believe that would solve the problem.&nbsp; Once the collision has been
produced using the public keys, anything added to the certificate after =
that
(i.e., an extension) will also produce a collision.</span></font></p>

<p><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font size=3D2><span style=3D'font-size:10.0pt'>Robert =
Zuccherato.</span></font>
</p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C520E5.6E5A2D2D--

Date: Fri, 4 Mar 2005 09:45:57 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

At 10:46 AM -0500 3/4/05, Robert Zuccherato wrote:
>However, I really wonder if we should be recommending that people 
>change their implementations at this point.  I don't think we know 
>enough yet about the potential attacks on MD5, SHA-1 to say with any 
>certainty that any particular counter-measures are worth 
>implementing.  This infrastructure was built assuming that people 
>will use strong hash functions.  I see no reason at this point to 
>change that assumption.  People should have stopped using MD5 a long 
>time ago.  Over the next couple of years they will likely have to 
>stop using SHA-1 as well.  I think that is the real advice that we 
>should be giving people at this time.

The first sentence fully contradicts the last one. To use a new hash 
algorithm is a *much* larger change than to have CAs change the 
method they issue serial numbers; one involves changing every 
validating client, the other doesn't.

>There are also some practical problems with overloading the serial number.

The term "overloading" is silly here. Before now, no one has accused 
VeriSign of "overloading" its serial numbers.

>   CRLs will, in most circumstances, increase in size.  Also, OCSP 
>responders that pre-compute responses may have trouble pre-computing 
>"good" responses if they cannot predict which serial numbers have 
>been used.  This issue would come up with responders that work from 
>CRLs and assume that a certificate is "good" if it's serial number 
>doesn't appear on a CRL.

Those are valid points. However, weigh them against asking every 
validating client to change its software (and not even assuring them 
that they won't have to again later when we discover that the 
"better" hash algorithm has some other flaws). Which is the better 
way to get the public to trust PKI more?

>I'd also like to point out that the serial number proposal would 
>only help X.509 certificates and not CRLs, RFC 3161 time stamp 
>tokens (there was already a message to the CFRG list today showing 
>how to extend the MD5 X.509 work to 3161 tokens), OCSP responses, 
>etc.

Please explain the attack scenario for these. What possible value is 
there for a CRL signature spoofing attack, for example? As for 
timestamps and OCSP responses, what Eric said yesterday still stands: 
if you are relying on a particular signed object for a valuable 
transaction, keep the object around.

--Paul Hoffman, Director
--VPN Consortium

Date: Fri, 04 Mar 2005 16:57:46 +0100
From: Alfonso De Gregorio <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Colliding RFC 3161 time-stamp tokens, via MD5-collisions
Sender: [email-masked]

Hi All, please accept my apologies if you have received this more than once.

First, I would like to thank Arjen Lenstra, Xiaoyun Wang,
and Benne de Weger for announcing a method for the construction
of pairs of colliding X.509 certificates.

I would like also to point out that it is possible, in a similar way,
to construct pairs of valid, but different, RFC 3161 time-stamp tokens
in which the signed data form a collision for the MD5 hash function.
This yields to the generation of the same signature by the
Time Stamping Authority when it uses MD5 as its hash function.

With this construction the attacker can easily craft MD5 collisions
in such a way that he or she constructs RFC 3161 time-stamp tokens
in which all fields, except the nonces, are equal (i.e., including
the TSA name and serial number). Hence, producing an evidence of the
apparent violation, by a given TSA, of an absolute requirement -
according to RFC 2119 - of the specifications. In fact, the RFC 3161
requires (see section 2.4.2) the uniqueness of the serial number that,
with the TSA name, must identify a unique time-stamp token.

The construction is straightforward.

1. First construct a template for the time-stamp token.
  All the fields must be completely filled in, with the exception
  of the nonce and the signature. The following requirements
  needs to be met:

     i) the data structure should be compliant to the RFC 3161 standard
        and the ASN.1 DER encoding rules;
    ii) the genTime (the time at which the time-stamp token has been
        created) and the serial-number needs to be guessed;
   iii) the position where the nonce field ends should be an exact
        multiple of 64 octets;

   (ii) The value at which the genTime field will be set by the TSA
   can be guessed depending on the accuracy of the clock (i.e.,
   the time deviation around the UTC time contained in genTime)
   and the time required to send and consume the time-stamping
   request message (e.g., the half round-trip latency plus the
   processing time). The accuracy is a public information and
   is typically equal to one second, or lesser values.

   In several implementations, the serial number is also guessable,
   since its a monotonically increasing number or derived from the
   system time.

   (iii) The third condition can be dealt with by filling out the
   nonce field with random data up to an exact multiple of 64 octets.
   This is a first part of the nonce value. For future reference,
   the offset where the first part of the nonce ends is labeled
   Offset-1. A second bitstring will be appended to it (see the
   step number 4).

2. The MD5 algorithm get executed on the first portion of the
  "to be signed" part, truncated at the position Offset-1
  (i.e., where the first part of the nonce ends). The input
  to MD5 is an exact multiple of 512 bits. The padding normally
  used in MD5 needs to be suppressed. The output should to be
  taken as the IV used as input for the next step.

3. Perform the step number 3 described by Lenstra et al. in
  'Colliding X.509 Certificates' available at
  <http://eprint.iacr.org/2005/067>. Two different bitstring,
  b1 and b2, whose length is a multiple of 512 bits, get
  constructed, using the technique developed by Wang et al.,
  for which the MD5 compression function with the IV from the
  previous step produces a collision.

4. Append the bitstring b1 into the time-stamp token template
  after the Offset-1. This bitstring completes the nonce value.
  Now all the (to be) signed data are complete and a time-stamping
  transaction can start with the given TSA. In the time-stamp
  request the attacker will specify the nonce that contains the
  bitstring b1.

5. The TSA replies with the time-stamp response that contains
  (seemingly) the expected time-stamp token.

6. To obtain the second valid time-stamp token, replace b1 for b2
  in the nonce field. The signature remains valid.

The time-stamp tokens are syntactically well-formed and obviously
valid also by a cryptographic standpoint, since their digital signature
can be verified by relying parties.

The same method may be applied against other iterative hash functions,
if a technique is identified to produce collisions with prescribed IV
also with the target function.

Finally, it would be much more interesting if someone would be
able to construct pairs of colliding RFC 3161 time-stamp tokens
whose genTime field (and/or serial number field) can be arbitrary
chosen. This would allow the pre-dating and post-dating of
data and would have a severe negative impact on intellectual property
protection applications and notary services based on RFC 3161 digital
time-stamping - reaffirming the importance of a strong evidence of
temporal ordering of time-stamps.

Alfonso

From: Robert Zuccherato <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Date: Fri, 4 Mar 2005 10:46:28 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C520D1.545C7191
Content-Type: text/plain

I'd like to comment on the following suggestion from Russ:

> In the past, I have recommended the use of large serial numbers 
> where the first part is a monotonically increasing integer and the second 
> part is random.  A 64-bit random value should thwart this attack.  

This idea has a number of good points.  It seems that a CA that includes
randomness in its serial number would be able to prevent collisions like the
one produced by Lenstra, 
Wang and de Wegner.  Including the randomness in the serial number in the
way that has been suggested is also nice because it's done in such a way
that PKIX conformant applications shouldn't choke on them.  A CA can also
continue to issue serial numbers using monotonically increasing values, or
any other scheme that they wish to use, in the non-random part.  

However, I really wonder if we should be recommending that people change
their implementations at this point.  I don't think we know enough yet about
the potential attacks on MD5, SHA-1 to say with any certainty that any
particular counter-measures are worth implementing.  This infrastructure was
built assuming that people will use strong hash functions.  I see no reason
at this point to change that assumption.  People should have stopped using
MD5 a long time ago.  Over the next couple of years they will likely have to
stop using SHA-1 as well.  I think that is the real advice that we should be
giving people at this time.

There are also some practical problems with overloading the serial number.
CRLs will, in most circumstances, increase in size.  Also, OCSP responders
that pre-compute responses may have trouble pre-computing "good" responses
if they cannot predict which serial numbers have been used.  This issue
would come up with responders that work from CRLs and assume that a
certificate is "good" if it's serial number doesn't appear on a CRL.

I'd also like to point out that the serial number proposal would only help
X.509 certificates and not CRLs, RFC 3161 time stamp tokens (there was
already a message to the CFRG list today showing how to extend the MD5 X.509
work to 3161 tokens), OCSP responses, etc.  One might consider defining a
non-critical extension that would simply contain a random integer of an
appropriate size that is freshly generated by the signer at signing time.
But, I don't believe that would solve the problem.  Once the collision has
been produced using the public keys, anything added to the certificate after
that (i.e., an extension) will also produce a collision.

	Robert Zuccherato.

------_=_NextPart_001_01C520D1.545C7191
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [saag] X.509 certificate collision, via MD5 =
collisions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I'd like to comment on the following suggestion from =
Russ:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; In the past, I have recommended the use of large =
serial numbers </FONT>
<BR><FONT SIZE=3D2>&gt; where the first part is a monotonically =
increasing integer and the second </FONT>
<BR><FONT SIZE=3D2>&gt; part is random.&nbsp; A 64-bit random value =
should thwart this attack.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>This idea has a number of good points.&nbsp; It seems =
that a CA that includes randomness in its serial number would be able =
to prevent collisions like the one produced by Lenstra, </FONT></P>

<P><FONT SIZE=3D2>Wang and de Wegner.&nbsp; Including the randomness in =
the serial number in the way that has been suggested is also nice =
because it's done in such a way that PKIX conformant applications =
shouldn't choke on them.&nbsp; A CA can also continue to issue serial =
numbers using monotonically increasing values, or any other scheme that =
they wish to use, in the non-random part.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>However, I really wonder if we should be recommending =
that people change their implementations at this point.&nbsp; I don't =
think we know enough yet about the potential attacks on MD5, SHA-1 to =
say with any certainty that any particular counter-measures are worth =
implementing.&nbsp; This infrastructure was built assuming that people =
will use strong hash functions.&nbsp; I see no reason at this point to =
change that assumption.&nbsp; People should have stopped using MD5 a =
long time ago.&nbsp; Over the next couple of years they will likely =
have to stop using SHA-1 as well.&nbsp; I think that is the real advice =
that we should be giving people at this time.</FONT></P>

<P><FONT SIZE=3D2>There are also some practical problems with =
overloading the serial number.&nbsp; CRLs will, in most circumstances, =
increase in size.&nbsp; Also, OCSP responders that pre-compute =
responses may have trouble pre-computing &quot;good&quot; responses if =
they cannot predict which serial numbers have been used.&nbsp; This =
issue would come up with responders that work from CRLs and assume that =
a certificate is &quot;good&quot; if it's serial number doesn't appear =
on a CRL.</FONT></P>

<P><FONT SIZE=3D2>I'd also like to point out that the serial number =
proposal would only help X.509 certificates and not CRLs, RFC 3161 time =
stamp tokens (there was already a message to the CFRG list today =
showing how to extend the MD5 X.509 work to 3161 tokens), OCSP =
responses, etc.&nbsp; One might consider defining a non-critical =
extension that would simply contain a random integer of an appropriate =
size that is freshly generated by the signer at signing time.&nbsp; =
But, I don't believe that would solve the problem.&nbsp; Once the =
collision has been produced using the public keys, anything added to =
the certificate after that (i.e., an extension) will also produce a =
collision.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>Robert =
Zuccherato.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C520D1.545C7191--

Content-class: urn:content-classes:message
Subject: RE: Comments to SCVP ID 17
Date: Fri, 4 Mar 2005 10:07:24 -0500
From: "Seth Hitchings" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

As it appears that there will be another revision to the draft, I have =
one more request.
=20
In section 4.9.5, replyWantBacks, please remove the "additional =
certitifcates used to
validate the revocation information" from the id-swb-pkc-best-cert-path =
and
id-swb-all-cert-paths want backs. This information will only ever be =
present if a client
requests id-swb-pkc-revocation-info. It makes the idea of the wantBack =
unnecessarily
complex to allow the presence or absence one wantBack to control the =
semantics of another.
It also increases the complexity for the client to parse the =
certification path out of the
cert path wantBack.

I suggest placing all information related to revocation info in the same =
wantBack. As
such, the wantBack value for id-swb-pkc-revocation-info could be updated =
to use the
following ASN.1 structure:

RevInfoWantBack ::=3D SEQUENCE {
  revocationInfo       RevocationInfos,
  validationCerts      CertBundle OPTIONAL }

Thanks,
Seth

________________________________

From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Tim
Polk
Sent: Tuesday, March 01, 2005 6:28 PM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: Comments to SCVP ID 17

At 10:23 AM 2/28/2005 +0100, you wrote:

	Here are some revised comments, based on the previous e-mail.
=09
	1. A new wording introduced in the document which is: =93PKI =
policies=94. This
	term is defined nowhere in RFC 3280, nor in this document. When it is
	used, it seems to mean =93validation policy=94. Please delete =
everywhere =93PKI
	policy=94 and replace it with =93validation policy=94.
=09
=09

Both occurrences of "PKI policies" have been changed to "validation =
policies" to align
with 3379.  (There were no occurrences of "PKI policy".)

	2. On page 7 the new term =93basic certification path processing =
algorithm=94
	is introduced whereas RFC 3280 uses a different wording :
=09
	 - =93certification path validation=94 (that is the title of section 6) =
and
	 - =93basic path validation=94 (that is the title of section 6.1).
=09
	Please do not introduce a new term.
=09

The sentence will be revised as follows:

SCVP defines a basic validation algorithm which implements the basic =
path validation
algorithm as defined in [PKIX-1], and permits the client to request =
additional information
about the certificate to be validated. =20

	3. The text refers to section 6.1.1 and it is said that one the input =
in
	section 6.1.1 is a =93Set of Trust Anchors=94. This is not consistent =
with
	section 6.1.1 from RFC3280 which deals with a *single* trust anchor,
	while section 6.2 from RFC 3280 deals with multiple trust anchors.
=09
	From the introduction, =93a validation policy contains one or more =
trust
	anchors=94. The protocol should allow, with a single request-response, =
to
	check if a certificate is valid against a validation policy which has
	more than one trust anchor. These checks should be done in accordance
	with section 6.2 from RFC 3280. The current ASN.1 is not conformant =
with
	section 6.1 from RFC 3280.
=09

The trust anchor text will be removed from the list associated with =
6.1.1 and relegated to
the following paragraph.  The following paragraph will state the options =
and use cases. =20

    The inputs to the basic certification path processing algorithm
    used by SCVP are defined by [PKIX-1] in section 6.1.1 and=20
    comprise:

		Certificate to be validated (by value or by reference);
	=09
	=09
		Validation time;
	=09
	=09
		The initial policy set;
	=09
	=09
		Initial inhibit policy mapping setting;
	=09
	=09
		Initial inhibit anyPolicy setting; and
	=09
	=09
		Initial require explicit policy setting.
	=09
	=09

       The basic certification path processing algorithm also supports =
specification of
one or=20
       more Trust Anchors (by value or reference) as an input.  Where =
the client demands a
       certification originating with a specific CA, a single Trust =
Anchor is specified.
Where
       the client is willing to accept paths beginning with any of =
several CAs, a set of
Trust
       anchors is specified.

	4. Section 1.4 is about a validation algorithm. Different rules may =
apply
	to every trust anchor and to the CA certificates from the certification
	path under every trust anchor. The ASN.1 description of =
ValidationPolicy
	starting on page 17 does not allow the client to define CA related
	different parameters for every trust anchor.
=09
	We currently have:
=09
	ValidationPolicy ::=3D SEQUENCE {
	       validationPolRef          ValidationPolRef,
	       validationAlg         [0] ValidationAlg OPTIONAL,
	       userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
	       IDENTIFIER OPTIONAL,
	       inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
	       requireExplicitPolicy [3] BOOLEAN OPTIONAL,
	       inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
	       trustAnchors          [6] TrustAnchors OPTIONAL,
	       keyUsages             [7] KeyUsages OPTIONAL,
	       extendedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL}
=09
	and
=09
	ValidationAlg ::=3D SEQUENCE {
	       valAlgId              OBJECT IDENTIFIER,
	       parameters            ANY DEFINED BY valAlgId OPTIONAL }
=09
	If:
	       trustAnchors          [6] TrustAnchors OPTIONAL,
=09
	is changed into:
=09
	       trustAnchor          [6] TrustAnchor OPTIONAL,
=09
	 ... then this would be conformant with the algorithm from section 6.1 =
of
	RFC 3280, but validation policies with multiple trust anchors and their
	own parameters could not be used.
=09
	The conditions that apply to CA certificates may be very complicated =
and
	vary from one trust anchor to another. The goal if this document is to
	support section 6.2 from FRC 3280.
=09

Using your ASN.1, the client would need to repeat the request for each =
Trust Anchor.

Using the current ASN.1, the client could use a single request for each =
set of Trust
Anchors that shared the set of parameters.  If the client wishes to =
specify different
parameters, then the client must use multiple requests.

In my opinion, the current ASN.1 provides a reasonable compromise =
between complexity and
functionality.

	A validation policy could OPTIONALLY include several =93target =
certificate
	specific parameters=94 as Wen-Cheng proposed, since they usually do not
	change from one trust anchor to another.
=09
	This would also solve the problem that Wen-Cheng noticed about the =
=93name
	validation algorithm=94.
=09
	Note that, as Wen-Cheng proposed, =93target certificate=94 seems to be =
a
	better term rather than =93end certificate=94
=09
	It is obvious that for each certification path, the algorithm from
	section 6.1 of RFC 3280 is being used. The validationAlg parameter is =
not
	needed.=20

We have already given the counter example (proxy certs) where this =
parameter *is* needed.

	We could then simply have:
=09
	ValidationPolicy ::=3D SEQUENCE {
	       validationPolRef          ValidationPolRef,
	       keyUsages                [0] KeyUsages OPTIONAL,
	       extendedKeyUsages        [1] SEQUENCE OF KeyPurposeId OPTIONAL,
	       nameValidationAlgParms   [2] NameValidationAlgParms OPTIONAL,
	       otherTests               [3] OtherTests OPTIONAL
	   }
=09
	additionalTests could be used for example to test QCStatements =
extensions
	presence and values, which would be very useful for Qualified
	Certificates.
=09

Other tests are currently supported in conjunction with the validation =
algorithm.

	5.Section 1.5 states: =93However, revocation checking is an optional
	feature in [PKIX-1], ... =94 This is incorrect.
=09
	RFC 3280 does not say that revocation checking is optional. Only CRLs
	processing is defined in RFC 3280 but we all know that OCSP is an
	alternative method. For DPV, revocation checking MUST be done to =
validate
	a certification path, but this may be done using different means. This
	means may be specified in the validation policy.
=09

First, I am not sure what change(s) you are advocating here.  Is the =
problem this sentence
or are you advocating additional restrictions on DPV services?

Second, I also do not agree with your interpretation of 3280.

In RFC 3280, CAs are required to either issue CRLs or have another =
mechanism to distribute
that information.  (No restrictions are specified on that mechanism so I =
presume
publishing it in the New York Times would be okay.)  RFC 3280 does not =
explicitly impose
these requireemnts on relying parties.  In fact, there are indications =
in both 3280 and
3647 that revocation checking need not be performed by relying parties.  =

>From the security considerations section in RFC 3280:

    Similarly, implementations of the certification path validation =
mechanism described in
    section 6 that omit revocation checking provide less assurance than =
those that support
it.=20

RFC 3647, section 4.4.9 bullet 6 implies that revocation checking is =
optional:

   * The mechanisms, if any, that a relying party may use or must use in =
order to
   check the status of certificates on which they wish to rely;=20

This text corresponds to the heading "4.9.6 Revocation checking =
requirement for relying
parties" in the suggested outline.

	6. It should be remembered that RFC 3379 makes the separation between =
DPV
	and DPD, while this document defines a single protocol for both of =
them.
	At the minimum the document should be profiled so that implementers may
	choose to support only DPV and not be forced to support also DPD.

We will change section 3.2.2 so that DPV servers need not support the
id-stc-build-pkc-path check. =20

  Conforming SCVP server implementations that support delegated path =
discovery (DPD) as
   defined in [RQMTS] MUST support the id-stc-build-pkc-path check. =20

We will change section 3.2.3 to clearly delineate the wantBacks that =
must be supported by
DPD and DPV server implementations.

   All conforming SCVP server implementations MUST support the =
id-swb-pkc-cert and
   id-swb-pkc-public-key-info wantBacks.  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.  =
Conforming SCVP
   server implementations that support delegated path validation (DPV) =
as defined in
[RQMTS]
   MUST support the id-swb-pkc-cert-status wantBack.

	7. =93SCVP=94 is a not a good name when the request is to only build a
	certification path - with or without revocation status (i.e. DPD, =
leaving
	the validation to the client). The certificate is not VALIDATED by the
	server, and even if it would, the client would not trust it. If someone
	says : =93I support SCVP=94, how could it make clear that it only =
supports
	the DPV variant of it ?
=09
	Better names would be:
=09
	 - DPVP: Delegated Path Validation Protocol, and
	 - DPDP: Delegated Path Discovery Protocol.
=09

Regardless of the mode (DPD vs. DPV) the goal is to simplify certificate =
validation.  In
one case we offload path discovery and perform validation locally.  In =
the second case,
both processes are offloaded to the server.

It is not so hard to clarify which services are supported.  They could =
say "Our DPV server
(client) implements SCVP as specified in RFC WXYZ".   This is not new or =
too difficult.
When ever there are optional features in a standard, the simple =
statement ("I support RFC
3280/2560/whatever") is insufficient. =20

	8. The text correctly states on page 6: =93An SCVP request needs only =
to
	contain the certificate to be validated, the referenced validation
	policy, and any run-time parameters for the request=94.
=09
	It would be very beneficial to be able to have implementations that =
only
	support the above requirements for DPV, leaving the security protection
	(i.e. integrity) to the communication link (i.e. using TLS) and not
	supporting other parameters (with the exception of the above optional
	=93target certificate specific parameters=94 as Wen-Cheng proposed). It =
is
	currently not straightforward to derive from the current document a
	profile for this.
=09
	It is suggested to revise the document so that this goal can be =
achieved
	and that conformance clauses are added to be able to say that a given
	implementation is conformant to this aspect only.
=09
	Additional comments (up to page 8 only) follow.
=09

Are you suggesting that userPolicySet and trustAnchors fields of the =
request should be
optional to support?

It is certainly possible to draft a useful profile of SCVP that does not =
make use of all
the mandatory to support features.  (For example, David Cooper has =
drafted a profile for
the FPKI that does not require the use of several of the mandatory to =
implement features,
including these two fields.)  However, in many environments it may be =
preferable to have
the client specify these values rather than attempting to define a =
separate validation
policy for every possible combination that may be needed for every =
relying party for every
application.

	9. Page 5. Section 1. Second paragraph. The text states:
=09
	   The first class of applications wants just two things: confirmation
	   that the public key belongs to the identity named in the certificate
	   and confirmation that the public key can be used for the intended
	   purpose.
=09
	This is not the main goal. Rephrase as:
=09
	   The first class of applications wants just confirmation
	   that the certificate is valid according a given validation policy.
=09

Your text implies that validating the certificate is the ultimate goal.  =
The current text
indicates that validating the certificate is a necessary step towards =
achieving the goal -
to use the key in a certificate for an intended purpose.  Your text is =
simpler, but I
don't think it gets to the heart of the matter.

	10. Page 5. Section 1. Second paragraph. The text states:
=09
	   The second class of applications can perform certification path
	   validation, but they lack a reliable or efficient method of
	   constructing a valid certification path.
=09
	Rephrase as:
=09
	   The second class of applications can perform certification path
	   validation, but they lack a reliable or efficient method of
	   constructing a valid certification path and the associated
	   revocation status information.
=09

Clients may wish to retrieve status information directly to ensure =
freshness.  It is
simple to retrieve status information if the certs contain CDPs or AIAs =
that point to OCSP
servers.

Given that this is introductory information, I believe the current text =
is acceptable.

	11. Page 5. Section 1.1. Second paragraph.
=09
	   The primary goals of SCVP are to make it easier to deploy =
PKI-enabled
	   applications and to allow central administration of PKI policies
	   within an organization.
=09
	Rephrase as:
=09
	   The primary goals of SCVP are to make it easier to deploy =
PKI-enabled
	   applications and to allow a server to support one or more validation
	   policies against which certificates can be tested by applications.
=09

First, central management of policies is a goal noted in 3379, so I =
wouldn't want to
delete it.

How about:

   The primary goals of SCVP are to make it easier to deploy PKI-enabled
   applications by delegating path discovery and/or validation =
processing to
   a server, and to allow central administration of validation policies
   within an organization.

	12. Page 5. Section 1.1. Second paragraph.
=09
	   SCVP can be used by clients that do much of
	   the certificate processing themselves but simply want an untrusted
	   server to collect information for them.  However, when the client =
has
	   complete trust in the SCVP server, SCVP can be used to delegate the
	   work of certification path construction and validation, and SCVP can
	   be used to ensure that policies are consistently enforced throughout
	   an organization.
=09
	Rephrase as:
=09
	   SCVP, used for DPV, can be used by clients that have complete trust
	   in a trusted DPV server. In such a case, the protocol can be used to
	   delegate the work of certification path construction and validation.
=09
	   SCVP, used for DPD, can be used by clients that do much of
	   the certificate processing themselves but simply want an untrusted
	   DPD server to collect information for them.
=09
=09

This is just a repeat of the introductory text in Section 1 above.  We =
have already
introduced the concepts, and there is no reason to assume that all =
servers fit into a
single category.  A DPV server might handle DPD requests as well.

Since the current text is accurate let's leave it as is.=20

	Denis
=09
=09
=09

Tim

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

------=_NextPart_000_07F0_01C520A1.F64BE680--

To: Jean-Marc Desperrier <[email-masked]>
Cc: [email-masked]
Subject: Re: [saag] Another bad day at the hash function factory
Reply-To: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Mar 2005 06:57:39 -0800
Sender: [email-masked]

Jean-Marc Desperrier <[email-masked]> writes:

> Dr Stephen Henson wrote:
>
>> Eric Rescorla wrote:
>>
>>> We have available:
>>>
>>> * A certificate containing key A (retained by the CA)
>>> * A certificate containing key B (retained by the relying party)
>>
> As I said initially I think it may happen, thought not very likely,
> that the relying party think it's safe enough to keep only the
> identification of the certificat for key B, and not the whole
> certificate.
>
> In that case, it would very sensible to the attack.

Well, we know now that people ought not to do that.

-Ekr

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: [saag] Another bad day at the hash function factory
Date: Fri, 04 Mar 2005 21:04:51 +1300
Sender: [email-masked]

Dr Stephen Henson <[email-masked]> writes:

>I also notice that the examples don't include the subject public key ID
>extension. If the CA used an appropriate recommended algorithm to generate
>SKID then it could demonstrate that the certificate containing A contained a
>consistent SKID whereas the one containing B did not.

I don't think this'd help, given the wide variety of methods for generating
SKIDs, having one that doesn't match the key wouldn't indicate much unless you
could show that every cert issued by the CA except the one in question had
some deterministic mapping from key -> SKID.

Peter.

Date: Fri, 04 Mar 2005 08:51:46 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: [saag] Another bad day at the hash function factory
Sender: [email-masked]

Dr Stephen Henson wrote:

> Eric Rescorla wrote:
>
>> We have available:
>>
>> * A certificate containing key A (retained by the CA)
>> * A certificate containing key B (retained by the relying party)
>
As I said initially I think it may happen, thought not very likely, that 
the relying party think it's safe enough to keep only the identification 
of the certificat for key B, and not the whole certificate.

In that case, it would very sensible to the attack.

> I also notice that the examples don't include the subject public key 
> ID extension. If the CA used an appropriate recommended algorithm to 
> generate SKID then it could demonstrate that the certificate 
> containing A contained a consistent SKID whereas the one containing B 
> did not.

At the time being, it's more strongly recommended to use the SKI 
extension for CA certificates than it is for end entity certificate.

Date: Thu, 03 Mar 2005 18:34:53 -0500
From: "David A. Cooper" <[email-masked]>
To: Wen-Cheng Wang <[email-masked]>
CC: [email-masked]
Subject: Re: Comments to SCVP ID 17
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060305000001010204020800
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Wen-Cheng Wang wrote:

>>     5. After reading SCVP 17, I finally understand the
>>        purpose of name validation algorithm. Before SCVP 17,
>>        I always thought it is used to specify the name
>>        matching rule (binary matching or X.500 name matching)
>>        during certificate chaining. Now I understand that it
>>        is use to specify the request for checking subject
>>        name of the "target certificate". If it is so, I think
>>        it is unreasonalbe to say:
>>      
>>          "The name validation is a refinement of the basic
>>           validation algorithm"
>>      
>>        The basic validation algorithm is an algorithm
>>        specifying conditions and rules for validating
>>        the whole certification path. In terms of RFC 3379,
>>        the basic validation algorithm specifies
>>        "certification path requirements". On th contrary,
>>        the name validation algorithm only specifies the
>>        request for checking subject name of the "target
>>        certificate". In terms of RFC 3379, the so-called
>>        name validation algorithm is simply one of the
>>        "end-entity certificate specific requirements".
>>        (Now I prefer to call them "target certificate
>>         specific requirements".)
>>        It is much like "keyUsages" and "extendedKeyUsages"
>>        checks, which are also "target certificate
>>        specific requirements". To make the protocol
>>        more resonable and aligned with RFC 3379, I
>>        suggest to take "name validation algorithm" out
>>        of section 3.2.4.2 and group it with "keyUsages"
>>        and "extendedKeyUsages", because they all belong
>>        to the category of "target certificate specific
>>        requirements".
>
>     I believe that there is still a misunderstanding.  The name
>     validation algorithm does not *only* specify checking the subject
>     name in the end (or target) certificate.  When the name validation
>     algorithm is specified, the server MUST perform all of the checks
>     required by the Basic Validation Algorithm *in addition to*
>     checking the subject name in the end (target) certificate.  That
>     is why the name validation algorithm is referred to as a
>     refinement of the basic validation algorithm.  As is stated in
>     section 3.2.4.2.1 (Basic Validation Algorithm): "That is, none of
>     the validation requirements in the basic algorithm may be omitted
>     from any newly defined validation algorithms."
>
> Believe me, I understand the refinement relationship. I simply feel that
> it is odd to say a "name validation algorithm" is a refinement of a path
> validation algorithm. I believe that most people will not associate
> path validation with the term "name validation". Maybe you should name
> it "the basic validation algorithm with name checking".

I am hesitant to change the name of the algorithm, since this would seem 
to require making changes to the ASN.1.  However, we can certainly 
re-word the first sentence of section 3.2.4.2.3 to remove the word 
"refinement".

>
>
>     While name validation could have been implemented in a similar
>     manner to the verification of keyUsage and extendedKeyUsage,
>     specifying name validation as a different validation algorithm
>     works just as well.  Changing the ASN.1 to group name checking
>     with keyUsages and extendedKeyUsages would simply be a styistic
>     change that would have no real effect on the protocol.  While Tim
>     and I made changes to the ASN.1 to clean up the tagging since so
>     many people insisted that they wanted the change, we really need
>     to get this document finished, and so I think we should try to
>     avoid making changes to the protocol that are unnecessary.
>
> I still believe that it is better to group "name checking", "key usage 
> checking"
> and "extended key usage checking" into the category of "end/target 
> certificate
> requirements". This is not a simply a stylistic change. It is a matter 
> of logicalness
> of the protocol design. However, if we are really running out of time, 
> I can live
> with "the basic validation algorithm with name validation".

OK.  I believe that it is very important that we get this document 
finished.  The -00 draft of SCVP was announced on June 28, 1999 and I 
know several people who are anxious to see this document completed.  We 
could argue forever about the best way to format the request, but the 
changes that you propose would have no effect on the information that 
the client could send to the server or that the server could return to 
the client.  It would just shuffle the bits.

>>     6. The current text of SCVP 17 tries to define a
>>        "global" default validation policy and tries to
>>        enforce all implementation to support that default
>>        validation policy. This notion of "default validation
>>        policy" does not align with the general understanding
>>        of "default validation policy".
>>       
>>        The default validation policy defined in SCVP 17 is
>>        actually simply a "basic" validation policy which
>>        adopts the basic path validation algorithm defined
>>        in RFC 3280, it is odd to specify it as the "global"
>>        default validation policy. The general understanding
>>        of "default validation policy" is the default one
>>        among the organizational validation policies.
>>        
>>        I suggest to change term "default validation policy"
>>        to "basic validation policy" to avoid confussion.
>>        With this distinction of the notion of "default
>>        validation policy" and the notion of the predefined
>>        "basic validation policy, we can clearly say that
>>      
>>          The SCVP server can define multiple vlidation
>>          policies and nominate one as its default
>>          policy. If the client does not select a
>>          validation policy in its request, the server
>>          will use the default validation policy.
>>      
>>          The SCVP server MAY list the "basic validation
>>          policy" defined in this specification as one
>>          of its supported validation policies. The SCVP
>>          server MAY select the "basic validation
>>          policy" as its default policy.
>>      
>>        Please note that I also suggest that the
>>        "validationPolicy" field in the "Query" data type
>>        should be changed to be an optional field. This
>>        allow the client to ommit the selection of
>>        the validation policy in its request and simply
>>        let the server use its default policy.
>
>     The "default validation policy" really is the default validation
>     policy for the organiztion; it is not a "global" validation policy.
>
>     Section 3.2.4.1.1 states that the default validation policy MUST
>     use the basic validation algorithm as its default validation
>     algorithm, but each individual SCVP server is free to set the
>     default values for all other parameters (e.g., trust anchors) of
>     the validation policy as it wishes.  The server specifies the
>     default parameter values that it uses in its default validation
>     policy in its validation policy response (in the
>     defaultPolicyValues item).
>
> Basically, I agree that the validation algorithm adopt by the server 
> MUST be based
> on the basic path validation algorithm defined by RFC 3280 or its 
> descendant, but
> it is not necessary to force every organization to accept that "basic 
> path validation
> algorithm" as the alogorithm of their organizational default 
> validation policy. What
> if the organization want to adopt an extended/refined version of  path 
> validation
> algorithm in their organizational default validation policy? To allow 
> organizations
> to define their own organizational default validation policy, I still 
> think it is better to
> name the validation policy defined by the SCVP spec as "basic 
> validation policy".
> It is analogy to that RFC 3280 named its path validation algorithm as 
> "basic path
> validation algorithm" (not "default validation algorithm").
>  
> The point is that SCVP should give freedom to organizations to define 
> their own
> organizational default validation policy. Nevertheless, SCVP could ask 
> organization
> to adopt PKIX-compliant validation algorithm no mater if they define 
> their own
> organizational default validation policy.
>  
> I understand that it is good if SCVP defines a validat policy and its 
> OID for the
> convenience of organization unwilling/unable to define their own 
> validat policy/OID.
> However, it should not be "the default validation policy". It should 
> simply be "a basic
> validation policy".

I would not agree to changing the name from "default validation policy" 
to "basic validation policy" since SCVP does not define the policy.  
This is not the same as the "basic validation algorithm", since the 
"basic validation algorithm" is an actual algorithm.  That is, it is 
fully defined in SCVP.  SCVP has assigned an OID for the "default 
validation policy" but leaves it to each organization to define the 
validation policy that corresponds to that OID.  The only aspect of the 
"default validation policy" that SCVP defines is the "default validation 
algorithm".

I would have no objection to removing the requirement that the "default 
validation policy" MUST use the "basic validation algorithm" as its 
default algorithm, but I'd need some evidence that this change would 
satisfy working group consensus.  I also think there would still need to 
be some restrictions imposed.  For example, it would make no sense to 
use the "name validation algorithm" as a default validation algorithm 
since the "name validation algorithm" requires a query-specific 
parameter.  Since the client would need to include the validation 
algorithm in its request in order to specify the algorithm parameter 
(the subject name(s) to look for), the "name validation algorithm" would 
not make an appropriate default.  A default validation algorithm for a 
validation policy should either be one that does not have any parameters 
or only has parameters for which reasonable default values can be 
defined.  The "basic validation algorithm" satisfies this.  I would 
guess that a "proxy certificate validation algorithm" might satisfy this 
requirement as well, but it seems very unlikely that one would want to 
use that as part of an organizational default validation policy.

>
>
>     So, if a client wants to use the organizational default validation
>     policy, it simply specifies the OID for the default validation
>     policy.  Rather than make the validationPolicy field OPTIONAL, the
>     editors chose to define an OID for the default validation policy. 
>     The effect is the same, it is just a slightly different encoding. 
>     This was done before I became involved with SCVP, but it may have
>     been done in order to make it possible for the server to reject
>     requests that specify the default policy OID (the server can
>     simply not list that OID in the validationPolices item of its
>     validation policy response.
>
> I know that this is the way SCVP letting organizations overwrite the 
> globally
> defined "default validation policy". However, in the situation where 
> an organization
> only supports one validation policy and naturally uses that validation 
> policy as its
> default organizational validation policy, isn't it superfluous to 
> request all its clients
> to specify the organizational validation policy OID? In such 
> situation, clients usually
> want to omit the validation polict item in their request and let the 
> server use its
> default policy. With current syntax, it is impossible to do that.

Yes.  As written, the client would need to include the validationPolicy 
item with validationPolRef specifying the default validation policy OID 
and with all other fields of the validationPolicy absent.  While this 
does add a few bits to the request over making this validation policy 
the default in an ASN.1 encoding sense, it doesn't actually make things 
more difficult for the organization since these are just implementation 
details that would be hidden from the organization.

I also asked one of the other editors about this and was told that this 
issue was debated and that a decision was made to require the request to 
explicitly specify the validation policy it wanted the server to use.  
So, I don't think this is something that I could change without evidence 
that there is a working group consensus in favor of the change.  Without 
that, I have to assume that the consensus is in favor of the current ASN.1.

>>     7. The title of section 1.3 is "validation Policies", but
>>        in the middle of that section it mentions:
>>      
>>          "The inputs to the basic certification path processing
>>           algorithm used by SCVP are defined by [PKIX-1] in
>>           section 6.1.1 and comprise:
>>         
>>             Certificate to be validated (by value or by reference);
>>         
>>             Validation time;
>>         
>>             Set of Trust Anchors (by value or by reference);
>>         
>>             The initial policy set;
>>         
>>             Initial inhibit policy mapping setting;
>>         
>>             Initial inhibit anyPolicy setting; and
>>         
>>             Initial require explicit policy setting."
>>      
>>        Isn't it be odd to define inputs to "validation
>>        algorithm" in a section titled "validation
>>        policies"?
>>      
>>        It reveals that even the authors of SCVP have no
>>        good distinction between the notion of "validation
>>        policy" and the notion of "validation algorithm",
>>        no to say an implementator who try to implement SCVP.
>>      
>>        Even several reviewers (for example Denis and I)
>>        clearly express that the notion of "validation algorithm"
>>        is redundant to the notion of "validation policy"
>>        and can be removed, how strange it is that the
>>        authors always to reject the suggestions.
>>      
>>        Now, even with SCVP 17 which authors says "the text
>>        for validation policies, validation algoriothms and
>>        name validation algorithms has all been revised for
>>        clarity, the distinction still vague.
>>      
>>        I sugest to remove the notion of "validation
>>        algorithm" from SCVP, and change the text to:
>>      
>>          "The certification path specific parameters to the
>>           basic validation policy defined by this specification
>>           are defined by [PKIX-1] in its section 6.1.1 and
>>           comprise:
>>         
>>             Certificate to be validated (by value or by reference);
>>         
>>             Validation time;
>>         
>>             Set of Trust Anchors (by value or by reference);
>>         
>>             The initial policy set;
>>         
>>             Initial inhibit policy mapping setting;
>>         
>>             Initial inhibit anyPolicy setting; and
>>         
>>             Initial require explicit policy setting."
>
>     I still believe that it is useful to have both a validation policy
>     and a validation algorithm.  You suggest that it is odd for the
>     validation policy to specify the inputs to the validation
>     algorithm, but I disagree.  The basic validation algorithm, for
>     example, is simply an algorithm.  It specifies the rules for
>     creating a set of outputs from a set of inputs.  The validation
>     algorithm does not, however, specify the *values* for the inputs. 
>     The validation policy specifies not only what algorithm should be
>     used to determine whether the certificate is valid, but also the
>     *values* for the inputs to the algorithm (e.g., trust anchors,
>     user initial policy set, etc.).
>
>     If the validation algorithm were removed as a parameter then it
>     would not be possible to specify the use of an algorithm other
>     than the basic validation algorithm for determining whether a
>     certificate were valid given the other inputs specified by the policy.
>
>     At the moment, there are only two validation algorithms defined
>     for use with SCVP and as you stated, subject name checking could
>     have been implemented with defining a new validation algorithm. 
>     However, including the validation algorithm as a parameter of the
>     validation policy allows for other validation algorithms to be
>     specified in the future.  For example, someone could define a
>     validation algorithm that verifies whether a certificate is a
>     valid proxy certificate according to RFC 3820.  This proxy
>     certificate algorithm could either be used as the default
>     validation algorithm for a validation policy or it use could be
>     specified by the client in the request.  So, a client could, for
>     example, specify the use of the default validation policy, but
>     with the proxy certificate validation algorithm.  The result would
>     be that the organizational default values would be used for the
>     inputs (trusts anchors, user intial policy set, etc.), but the
>     certificate(s) would be validated as a proxy certificate (RFC
>     3820) rather than being validated using the normal validation
>     algorithm (RFC 3280).
>
> The question is what is the relationship between "validation policy" and
> "validation algorithm"? Will it be normally one-to-one relationship or
> one-to-many relationship? By one-to-one relationship, I mean one 
> validation
> policy can only support one validation algorithm. By one-to-many 
> relationship,
> I mean one validation policy can support multiple validation algorithms.
> In one-to-many relationship, a client might need to select one of the 
> multiple
> validation algorithms supported by the validation policy it specifies 
> in the request.
> In one-to-one relationship, since the validation policy implies the 
> validation
> algorithm, it is superfluous to ask the client to specify both of them.
>  
> I believe that it is easier to adopt one-to-one relationship model, 
> let one
> validation policy imply a validation algorithm, and remove the validation
> algorithm item from the syntax. With one-to-one relationship model, if
> an organization want to support multiple validation algorithm, they can
> define multiple validation policies and let each imply one validation 
> algorithm
> respectively.
>  
> The point is a validation policy can imply a validation algorithm, and 
> therefore
> the notion of validation algorithm can be removed from SCVP.

I do not understand the objection.  A validation policy MUST specify a 
default validation algorithm.  So, if there is a one-to-one relationship 
between policies and algorithms, the client would NEVER have to specify 
the validation algorithm.

As the document is currently written, an SCVP server could mandate a 
one-to-one relationship between policies and algorithms.  If the server 
supported multiple algorithms, it could define multiple policies with 
each specifying a different default validation algorithm.  The server 
could also reject any requests that specified a non-default validation 
algorithm.  Removing validationAlg from the validationPolicy item would 
simply force this one-to-one relationship on all SCVP servers.  Since 
the inclusion of validationAlg as an optional parameter of the 
validationPolicy does not preclude SCVP servers from having a one-to-one 
relationship between policies and algorithms, I don't see any benefit to 
preventing others from implementing a one-to-many relationship if they 
choose to do so.

>>     9. I give the following comment before but get no response,
>>        so here I raise it again.
>>      
>>        There are situations where the certificate-using
>>        applications need to check whether a certificate
>>        was valid during a period of time, not only validate
>>        it with respect to a specific moment. For example,
>>        an application verifying an archived long-term
>>        signature might need to check whether a certificate
>>        was valid during a period of time in which the
>>        signature was generated. Therefore, I suggest to
>>        extend the structure of the "validationTime" field
>>        of the "Query" data type to support this. A CHOICE
>>        between a moment and a period of time is sufficient.
>
>     I have not been involved with SCVP for very long, but I have not
>     heard this one before and it is not clear why it is needed.  If
>     you specify a validationTime equal to "end" (as defined in your
>     ASN.1 below) and the response is that the certificate is not
>     valid, then it was not valid.  If the certificate was valid at
>     time "end", then there must be a valid certification path in which
>     all of the certificates were valid at time "end".  If the
>     certificates were valid at time "end", then they could not have
>     been revoked before time "end".  So, the only way the
>     certification path could have been invalid at any point between
>     "start" and "end" is if "start" preceded the notBefore time in any
>     of the certificates in the certification path.  If this is a
>     concern, you could send a second query with a validationTime of
>     "start".  If the server reports that the certificate is valid at
>     both "start" and "end", then it seems that one can safely conclude
>     that the certificate was valid during the entire interval.
>
> The current SCVP syntax and semantics only support validating 
> certificates against
> a retrospective moment. Please not that it is not the same to say "a 
> certificate is
> valid at time t1" as to say "a certificate is valid before time t1", 
> because the validity of
> the certificate could be suspended and then resumed before time t1. It 
> is certainly
> different with "a certificate is valid from time t2 to time t1".

I would be against trying to add such a feature for two reasons.  First, 
there have been conflicting ideas about how certificate suspension 
should be interpreted.  In my opinion, if a certificate is suspended but 
then removed from suspension, then once it has been removed from 
suspension it can be treated as if it had always been good.  That is, 
one suspends a certificate if there is a question about the status of 
the certificate and then removes the certificate from suspension only if 
it turns out that there was no problem.  Since the conclusion was that 
there was no problem, there is no reason to suspect that the private key 
was misused.

I understand that some view suspension differently.  In their view, even 
if a certificate is removed from suspension any use of the private key 
while the certificate was suspended should be considered invalid.

Second, even if there was universal agreement that any use of the 
private key corresponding to a certificate while the certificate is 
suspended (on hold) is not legitimate, I don't believe that 
functionality you want could be implemented.  If the client provided the 
SCVP server with a certificate and a time interval, how could the server 
ensure that the certificate was never on hold during that time period?  
Remember that if a certificate is on hold (suspended) then the CA 
includes it on the CRL, but once the certificate is removed from hold it 
is simply no longer included on any subsequently issued CRLs.  Since no 
CRL issued after (or before) the certificate was removed from suspension 
would indicate that the certificate had ever been suspended, the SCVP 
server would only know that the certificate had been suspended if it 
looked at a CRL that was issued during the time that the certificate was 
on hold.

So, would the SCVP server be required to check every CRL issued in the 
interval [t2 ... t1] to verify that the certificate was not listed one 
any CRL during the interval?  If so, how could the SCVP server be sure 
that it really checked every CRL issued during that interval?  If not, 
how could the SCVP server be sure that the certificate had not been 
suspended at any point in the interval?

Dave

--------------060305000001010204020800
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Wen-Cheng Wang wrote:
<blockquote cite="mid032201c51830$70508870$4f85900a@wcwang" type="cite">
  <title></title>
  <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
  <meta content="MSHTML 6.00.2800.1491" name="GENERATOR">
  <style></style>
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang"
 type="cite">
      <div><font face="Courier New" size="2">5. After reading SCVP 17,
I finally understand the<br>
   purpose of name validation algorithm. Before SCVP 17,<br>
   I always thought it is used to specify the name<br>
   matching rule (binary matching or X.500 name matching)<br>
   during certificate chaining. Now I understand that it<br>
   is use to specify the request for checking subject<br>
   name of the "target certificate". If it is so, I think<br>
   it is unreasonalbe to say:</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">     "The name validation
is a refinement of the basic<br>
      validation algorithm"</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">   The basic validation
algorithm is an algorithm<br>
   specifying conditions and rules for validating<br>
   the whole certification path. In terms of RFC 3379,<br>
   the basic validation algorithm specifies<br>
   "certification path requirements". On th contrary,<br>
   the name validation algorithm only specifies the<br>
   request for checking subject name of the "target<br>
   certificate". In terms of RFC 3379, the so-called<br>
   name validation algorithm is simply one of the<br>
   "end-entity certificate specific requirements".<br>
   (Now I prefer to call them "target certificate<br>
    specific requirements".)<br>
   It is much like "keyUsages" and "extendedKeyUsages"<br>
   checks, which are also "target certificate<br>
   specific requirements". To make the protocol<br>
   more resonable and aligned with RFC 3379, I<br>
   suggest to take "name validation algorithm" out<br>
   of section 3.2.4.2 and group it with "keyUsages"<br>
   and "extendedKeyUsages", because they all belong<br>
   to the category of "target certificate specific<br>
   requirements".</font></div>
    </blockquote>
    <div>I believe that there is still a misunderstanding.  The name
validation algorithm does not *only* specify checking the subject name
in the end (or target) certificate.  When the name validation algorithm
is specified, the server MUST perform all of the checks required by the
Basic Validation Algorithm *in addition to* checking the subject name
in the end (target) certificate.  That is why the name validation
algorithm is referred to as a refinement of the basic validation
algorithm.  As is stated in section 3.2.4.2.1 (Basic Validation
Algorithm): "That is, none of the validation requirements in the basic
algorithm may be omitted from any newly defined validation algorithms."</div>
  </blockquote>
  <div><font face="新細明體" size="2">
  <div>
  <div><font face="Times New Roman"><font size="3">Believe me, I
understand the refinement relationship</font><font size="3">. </font></font><font
 face="Times New Roman" size="3">I simply feel that</font></div>
  <div><font face="Times New Roman" size="3">it is odd to say a "name
validation </font><font face="Times New Roman"><font size="3">algorithm"
  </font><font size="3">is a refinement of a path</font></font></div>
  <div><font face="Times New Roman"><font size="3">validation </font></font><font
 face="Times New Roman" size="3">algorithm. I believe that most people
will not associate</font></div>
  <div><font face="Times New Roman" size="3">path validation with the
term "name validation". </font><font face="Times New Roman" size="3">Maybe
you should name</font></div>
  <div><font face="Times New Roman" size="3">it "the basic validation
algorithm </font><font face="Times New Roman" size="3">with name
checking".</font></div>
  </div>
  </font></div>
</blockquote>
I am hesitant to change the name of the algorithm, since this would
seem to require making changes to the ASN.1.  However, we can certainly
re-word the first sentence of section 3.2.4.2.3 to remove the word
"refinement".<br>
<blockquote cite="mid032201c51830$70508870$4f85900a@wcwang" type="cite">
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <div><br>
    <br>
While name validation could have been implemented in a similar manner
to the verification of keyUsage and extendedKeyUsage, specifying name
validation as a different validation algorithm works just as well. 
Changing the ASN.1 to group name checking with keyUsages and
extendedKeyUsages would simply be a styistic change that would have no
real effect on the protocol.  While Tim and I made changes to the ASN.1
to clean up the tagging since so many people insisted that they wanted
the change, we really need to get this document finished, and so I
think we should try to avoid making changes to the protocol that are
unnecessary.</div>
  </blockquote>
  <div>
  <div>
  <div><font face="Times New Roman" size="3">I still believe that it is
better to group </font><font face="Times New Roman" size="3">"name
checking", "key usage checking"</font></div>
  <div><font face="Times New Roman" size="3">and </font><font
 face="Times New Roman" size="3">"extended key usage checking" into the
category </font><font face="Times New Roman" size="3">of "end/target
certificate</font></div>
  <div><font face="Times New Roman" size="3">requirements". </font><font
 face="Times New Roman" size="3">This is not a simply a stylistic
change. It is </font><font face="Times New Roman">a matter of
logicalness</font></div>
  <div><font face="Times New Roman">of the protocol design. </font><font
 face="Times New Roman" size="3">However, if we are really running out
of time, </font><font face="Times New Roman"><font size="3">I can live</font></font></div>
  <div><font face="Times New Roman"><font size="3">with </font><font
 size="3">"the basic validation algorithm </font></font><font
 face="Times New Roman" size="3">with name validation".</font></div>
  </div>
  </div>
</blockquote>
OK.  I believe that it is very important that we get this document
finished.  The -00 draft of SCVP was announced on June 28, 1999 and I
know several people who are anxious to see this document completed.  We
could argue forever about the best way to format the request, but the
changes that you propose would have no effect on the information that
the client could send to the server or that the server could return to
the client.  It would just shuffle the bits.<br>
<blockquote cite="mid032201c51830$70508870$4f85900a@wcwang" type="cite">
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang"
 type="cite">
      <div><font face="Courier New" size="2">6. The current text of
SCVP 17 tries to define a<br>
   "global" default validation policy and tries to<br>
   enforce all implementation to support that default<br>
   validation policy. This notion of "default validation<br>
   policy" does not align with the general understanding<br>
   of "default validation policy".<br>
   <br>
   The default validation policy defined in SCVP 17 is<br>
   actually simply a "basic" validation policy which<br>
   adopts the basic path validation algorithm defined<br>
   in RFC 3280, it is odd to specify it as the "global"<br>
   default validation policy. The general understanding<br>
   of "default validation policy" is the default one<br>
   among the organizational validation policies.<br>
    <br>
   I suggest to change term "default validation policy"<br>
   to "basic validation policy" to avoid confussion.<br>
   With this distinction of the notion of "default<br>
   validation policy" and the notion of the predefined<br>
   "basic validation policy, we can clearly say that</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">     The SCVP server can
define multiple vlidation<br>
     policies and nominate one as its default<br>
     policy. If the client does not select a<br>
     validation policy in its request, the server<br>
     will use the default validation policy.</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">     The SCVP server MAY
list the "basic validation<br>
     policy" defined in this specification as one<br>
     of its supported validation policies. The SCVP<br>
     server MAY select the "basic validation<br>
     policy" as its default policy.</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">   Please note that I also
suggest that the<br>
   "validationPolicy" field in the "Query" data type<br>
   should be changed to be an optional field. This<br>
   allow the client to ommit the selection of<br>
   the validation policy in its request and simply<br>
   let the server use its default policy.</font></div>
    </blockquote>
    <div>The "default validation policy" really is the default
validation policy for the organiztion; it is not a "global" validation
policy.<br>
    <br>
Section 3.2.4.1.1 states that the default validation policy MUST use
the basic validation algorithm as its default validation algorithm, but
each individual SCVP server is free to set the default values for all
other parameters (e.g., trust anchors) of the validation policy as it
wishes.  The server specifies the default parameter values that it uses
in its default validation policy in its validation policy response (in
the defaultPolicyValues item).</div>
  </blockquote>
  <div><font face="新細明體" size="2">
  </font>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3">Basically,
I agree that the validation algorithm adopt by the server MUST be </font><font
 face="Times New Roman" size="3">based</font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3">on
  </font><font face="Times New Roman" size="3">the basic path
validation algorithm defined by RFC 3280 or its descendant, but</font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3">it
is not necessary to force every organization to accept that "basic path
validation</font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3">algorithm"
as the alogorithm of their organizational default validation policy.
What</font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3">if
the organization want to adopt an extended/refined version of  path
validation</font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3">algorithm
in their organizational default validation policy? To allow
organizations</font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3">to
define their own organizational default validation policy, I still
think it is better to</font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3">name
  </font><font face="Times New Roman" size="3">the validation policy
defined by the SCVP</font> <font face="Times New Roman" size="3">spec
as "basic validation policy".</font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3">It
is analogy to that RFC 3280 named its path validation algorithm as
"basic path</font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3">validation
  <font face="Times New Roman" size="3">algorithm" (not "default
validation algorithm").</font></font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3"><font
 face="新細明體" size="2"> </font></font></font></div>
  <div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3"><font
 face="新細明體" size="2"><font face="Times New Roman" size="3">The point
is that SCVP should give freedom to organizations to define their own</font></font></font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3"><font
 face="新細明體" size="2"><font face="Times New Roman" size="3">organizational
default validation policy. Nevertheless, SCVP could ask organization</font></font></font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3"><font
 face="新細明體" size="2"><font face="Times New Roman" size="3">to adopt
PKIX-compliant validation algorithm no mater if they define their own</font></font></font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3"><font
 face="新細明體" size="2"><font face="Times New Roman" size="3">organizational
default validation policy.</font></font></font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3"><font
 face="新細明體" size="2"> </font></font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3"><font
 face="新細明體" size="2"><font face="Times New Roman" size="3">I
understand that it is good if SCVP defines a validat policy and its OID
for the</font></font></font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3"><font
 face="新細明體" size="2"><font face="Times New Roman" size="3">convenience
of organization unwilling/unable to define their own validat policy/OID.</font></font></font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3"><font
 face="新細明體" size="2"><font face="Times New Roman" size="3">However, it
should not be "the default validation policy". It should simply be "a
basic</font></font></font></font></div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3"><font
 face="新細明體" size="2"><font face="Times New Roman" size="3">validation
policy".</font></font></font></font></div>
  </div>
  </div>
</blockquote>
I would not agree to changing the name from "default validation policy"
to "basic validation policy" since SCVP does not define the policy. 
This is not the same as the "basic validation algorithm", since the
"basic validation algorithm" is an actual algorithm.  That is, it is
fully defined in SCVP.  SCVP has assigned an OID for the "default
validation policy" but leaves it to each organization to define the
validation policy that corresponds to that OID.  The only aspect of the
"default validation policy" that SCVP defines is the "default
validation algorithm".<br>
<br>
I would have no objection to removing the requirement that the "default
validation policy" MUST use the "basic validation algorithm" as its
default algorithm, but I'd need some evidence that this change would
satisfy working group consensus.  I also think there would still need
to be some restrictions imposed.  For example, it would make no sense
to use the "name validation algorithm" as a default validation
algorithm since the "name validation algorithm" requires a
query-specific parameter.  Since the client would need to include the
validation algorithm in its request in order to specify the algorithm
parameter (the subject name(s) to look for), the "name validation
algorithm" would not make an appropriate default.  A default validation
algorithm for a validation policy should either be one that does not
have any parameters or only has parameters for which reasonable default
values can be defined.  The "basic validation algorithm" satisfies
this.  I would guess that a "proxy certificate validation algorithm"
might satisfy this requirement as well, but it seems very unlikely that
one would want to use that as part of an organizational default
validation policy.<br>
<blockquote cite="mid032201c51830$70508870$4f85900a@wcwang" type="cite">
  <div>
  <div><font face="新細明體" size="2"><font face="Times New Roman" size="3"><font
 face="新細明體" size="2"> </font></font></font></div>
  </div>
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <div><br>
    <br>
So, if a client wants to use the organizational default validation
policy, it simply specifies the OID for the default validation policy. 
Rather than make the validationPolicy field OPTIONAL, the editors chose
to define an OID for the default validation policy.  The effect is the
same, it is just a slightly different encoding.  This was done before I
became involved with SCVP, but it may have been done in order to make
it possible for the server to reject requests that specify the default
policy OID (the server can simply not list that OID in the
validationPolices item of its validation policy response.</div>
  </blockquote>
  <div><font face="新細明體" size="2">
  <div>
  <div><font face="Times New Roman" size="3">I know that this is the
way SCVP letting organizations overwrite the globally</font></div>
  <div><font face="Times New Roman" size="3">defined "default
validation policy". However, in the situation where an organization</font></div>
  <div><font face="Times New Roman" size="3">only supports one
validation policy and naturally uses that validation policy as its</font></div>
  <div><font face="Times New Roman" size="3">default organizational
validation policy, isn't it superfluous to request all its clients</font></div>
  <div><font face="Times New Roman" size="3">to specify the
organizational validation policy OID? In such situation, clients usually</font></div>
  <div><font face="Times New Roman" size="3">want to omit the
validation polict item in their request and let the server use its</font></div>
  <div><font face="Times New Roman" size="3">default policy. With
current syntax, it is impossible to do that.</font></div>
  </div>
  </font></div>
</blockquote>
Yes.  As written, the client would need to include the validationPolicy
item with validationPolRef specifying the default validation policy OID
and with all other fields of the validationPolicy absent.  While this
does add a few bits to the request over making this validation policy
the default in an ASN.1 encoding sense, it doesn't actually make things
more difficult for the organization since these are just implementation
details that would be hidden from the organization.<br>
<br>
I also asked one of the other editors about this and was told that this
issue was debated and that a decision was made to require the request
to explicitly specify the validation policy it wanted the server to
use.  So, I don't think this is something that I could change without
evidence that there is a working group consensus in favor of the
change.  Without that, I have to assume that the consensus is in favor
of the current ASN.1.<br>
<br>
<blockquote cite="mid032201c51830$70508870$4f85900a@wcwang" type="cite">
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang"
 type="cite">
      <div><font face="Courier New" size="2">7. The title of section
1.3 is "validation Policies", but<br>
   in the middle of that section it mentions:</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">     "The inputs to the
basic certification path processing<br>
      algorithm used by SCVP are defined by [PKIX-1] in<br>
      section 6.1.1 and comprise: <br>
     <br>
        Certificate to be validated (by value or by reference); <br>
     <br>
        Validation time; <br>
     <br>
        Set of Trust Anchors (by value or by reference); <br>
     <br>
        The initial policy set; <br>
     <br>
        Initial inhibit policy mapping setting; <br>
     <br>
        Initial inhibit anyPolicy setting; and <br>
     <br>
        Initial require explicit policy setting."</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">   Isn't it be odd to
define inputs to "validation<br>
   algorithm" in a section titled "validation<br>
   policies"?</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">   It reveals that even
the authors of SCVP have no<br>
   good distinction between the notion of "validation<br>
   policy" and the notion of "validation algorithm",<br>
   no to say an implementator who try to implement SCVP.</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">   Even several reviewers
(for example Denis and I)<br>
   clearly express that the notion of "validation algorithm"<br>
   is redundant to the notion of "validation policy"<br>
   and can be removed, how strange it is that the<br>
   authors always to reject the suggestions.</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">   Now, even with SCVP 17
which authors says "the text<br>
   for validation policies, validation algoriothms and<br>
   name validation algorithms has all been revised for<br>
   clarity, the distinction still vague.</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">   I sugest to remove the
notion of "validation<br>
   algorithm" from SCVP, and change the text to:</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">     "The certification
path specific parameters to the<br>
      basic validation policy defined by this specification<br>
      are defined by [PKIX-1] in its section 6.1.1 and<br>
      comprise: <br>
     <br>
        Certificate to be validated (by value or by reference); <br>
     <br>
        Validation time; <br>
     <br>
        Set of Trust Anchors (by value or by reference); <br>
     <br>
        The initial policy set; <br>
     <br>
        Initial inhibit policy mapping setting; <br>
     <br>
        Initial inhibit anyPolicy setting; and <br>
     <br>
        Initial require explicit policy setting."</font></div>
    </blockquote>
    <div>I still believe that it is useful to have both a validation
policy and a validation algorithm.  You suggest that it is odd for the
validation policy to specify the inputs to the validation algorithm,
but I disagree.  The basic validation algorithm, for example, is simply
an algorithm.  It specifies the rules for creating a set of outputs
from a set of inputs.  The validation algorithm does not, however,
specify the *values* for the inputs.  The validation policy specifies
not only what algorithm should be used to determine whether the
certificate is valid, but also the *values* for the inputs to the
algorithm (e.g., trust anchors, user initial policy set, etc.).<br>
    <br>
If the validation algorithm were removed as a parameter then it would
not be possible to specify the use of an algorithm other than the basic
validation algorithm for determining whether a certificate were valid
given the other inputs specified by the policy.<br>
    <br>
At the moment, there are only two validation algorithms defined for use
with SCVP and as you stated, subject name checking could have been
implemented with defining a new validation algorithm.  However,
including the validation algorithm as a parameter of the validation
policy allows for other validation algorithms to be specified in the
future.  For example, someone could define a validation algorithm that
verifies whether a certificate is a valid proxy certificate according
to RFC 3820.  This proxy certificate algorithm could either be used as
the default validation algorithm for a validation policy or it use
could be specified by the client in the request.  So, a client could,
for example, specify the use of the default validation policy, but with
the proxy certificate validation algorithm.  The result would be that
the organizational default values would be used for the inputs (trusts
anchors, user intial policy set, etc.), but the certificate(s) would be
validated as a proxy certificate (RFC 3820) rather than being validated
using the normal validation algorithm (RFC 3280).</div>
  </blockquote>
  <div>
  <div>
  <div><font face="Times New Roman" size="3">The question is what is
the relationship between "validation policy" and</font></div>
  <div><font face="Times New Roman" size="3">"validation algorithm"?
Will it be normally one-to-one relationship or</font></div>
  <div><font face="Times New Roman">one-to-many relationship? By
one-to-one relationship, I mean one validation</font></div>
  <div><font face="Times New Roman">policy can only support one
validation algorithm. By one-to-many relationship,</font></div>
  <div><font face="Times New Roman">I mean one validation <font
 face="Times New Roman">policy can support multiple validation
algorithms.</font></font></div>
  <div><font face="Times New Roman">In one-to-many relationship, a
client might need to select one of the multiple</font></div>
  <div><font face="Times New Roman">validation algorithms supported by
the validation policy it specifies in the </font><font
 face="Times New Roman">request.</font></div>
  <div><font face="Times New Roman">In one-to-one relationship, since
the validation policy implies the validation</font></div>
  <div><font face="Times New Roman">algorithm, it is superfluous to ask
the client to specify both of them.</font></div>
  <div> </div>
  <div><font face="Times New Roman">I believe that it is easier to
adopt one-to-one relationship model, let one</font></div>
  <div><font face="Times New Roman">validation policy imply a
validation algorithm, and remove the validation</font></div>
  <div><font face="Times New Roman">algorithm item from the syntax.
With one-to-one relationship model, if</font></div>
  <div><font face="Times New Roman">an organization want to support
multiple validation algorithm, they can</font></div>
  <div><font face="Times New Roman">define multiple validation policies
and let each imply one validation algorithm</font></div>
  <div><font face="Times New Roman">respectively.</font></div>
  <div> </div>
  <div><font face="Times New Roman">The point is a validation policy
can imply a validation algorithm, and therefore</font></div>
  <div><font face="Times New Roman">the notion of validation algorithm
can be removed from SCVP.</font></div>
  </div>
  </div>
</blockquote>
I do not understand the objection.  A validation policy MUST specify a
default validation algorithm.  So, if there is a one-to-one
relationship between policies and algorithms, the client would NEVER
have to specify the validation algorithm.<br>
<br>
As the document is currently written, an SCVP server could mandate a
one-to-one relationship between policies and algorithms.  If the server
supported multiple algorithms, it could define multiple policies with
each specifying a different default validation algorithm.  The server
could also reject any requests that specified a non-default validation
algorithm.  Removing validationAlg from the validationPolicy item would
simply force this one-to-one relationship on all SCVP servers.  Since
the inclusion of validationAlg as an optional parameter of the
validationPolicy does not preclude SCVP servers from having a
one-to-one relationship between policies and algorithms, I don't see
any benefit to preventing others from implementing a one-to-many
relationship if they choose to do so.
<blockquote cite="mid032201c51830$70508870$4f85900a@wcwang" type="cite">
  <div>
  <div></div>
  </div>
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang"
 type="cite">
      <div><font face="Courier New" size="2">9. I give the following
comment before but get no response,<br>
   so here I raise it again.</font></div>
      <div> </div>
      <div><font face="Courier New" size="2">   There are situations
where the certificate-using<br>
   applications need to check whether a certificate<br>
   was valid during a period of time, not only validate<br>
   it with respect to a specific moment. For example,<br>
   an application verifying an archived long-term<br>
   signature might need to check whether a certificate<br>
   was valid during a period of time in which the<br>
   signature was generated. Therefore, I suggest to<br>
   extend the structure of the "validationTime" field<br>
   of the "Query" data type to support this. A CHOICE<br>
   between a moment and a period of time is sufficient.</font><br>
      </div>
    </blockquote>
    <div>I have not been involved with SCVP for very long, but I have
not heard this one before and it is not clear why it is needed.  If you
specify a validationTime equal to "end" (as defined in your ASN.1
below) and the response is that the certificate is not valid, then it
was not valid.  If the certificate was valid at time "end", then there
must be a valid certification path in which all of the certificates
were valid at time "end".  If the certificates were valid at time
"end", then they could not have been revoked before time "end".  So,
the only way the certification path could have been invalid at any
point between "start" and "end" is if "start" preceded the notBefore
time in any of the certificates in the certification path.  If this is
a concern, you could send a second query with a validationTime of
"start".  If the server reports that the certificate is valid at both
"start" and "end", then it seems that one can safely conclude that the
certificate was valid during the entire interval.</div>
  </blockquote>
  <div><font face="Times New Roman">The current SCVP syntax and
semantics only support validating certificates against</font></div>
  <div><font face="Times New Roman">a retrospective moment. Please not
that it is not the same to say "a certificate is</font></div>
  <div><font face="Times New Roman">valid at time t1" as to say "a
certificate is valid before time t1", because the validity of</font></div>
  <div><font face="Times New Roman">the certificate </font><font
 face="Times New Roman">could be suspended and then resumed before time
t1. It is certainly</font></div>
  <div><font face="Times New Roman">different with "a certificate is
valid from time t2 to time t1".</font></div>
</blockquote>
I would be against trying to add such a feature for two reasons. 
First, there have been conflicting ideas about how certificate
suspension should be interpreted.  In my opinion, if a certificate is
suspended but then removed from suspension, then once it has been
removed from suspension it can be treated as if it had always been
good.  That is, one suspends a certificate if there is a question about
the status of the certificate and then removes the certificate from
suspension only if it turns out that there was no problem.  Since the
conclusion was that there was no problem, there is no reason to suspect
that the private key was misused.<br>
<br>
I understand that some view suspension differently.  In their view,
even if a certificate is removed from suspension any use of the private
key while the certificate was suspended should be considered invalid.<br>
<br>
Second, even if there was universal agreement that any use of the
private key corresponding to a certificate while the certificate is
suspended (on hold) is not legitimate, I don't believe that
functionality you want could be implemented.  If the client provided
the SCVP server with a certificate and a time interval, how could the
server ensure that the certificate was never on hold during that time
period?  Remember that if a certificate is on hold (suspended) then the
CA includes it on the CRL, but once the certificate is removed from
hold it is simply no longer included on any subsequently issued CRLs. 
Since no CRL issued after (or before) the certificate was removed from
suspension would indicate that the certificate had ever been suspended,
the SCVP server would only know that the certificate had been suspended
if it looked at a CRL that was issued during the time that the
certificate was on hold.<br>
<br>
So, would the SCVP server be required to check every CRL issued in the
interval [t2 ... t1] to verify that the certificate was not listed one
any CRL during the interval?  If so, how could the SCVP server be sure
that it really checked every CRL issued during that interval?  If not,
how could the SCVP server be sure that the certificate had not been
suspended at any point in the interval?<br>
<br>
<br>
Dave<br>
<br>
</body>
</html>

--------------060305000001010204020800--

Date: Thu, 03 Mar 2005 21:22:57 +0000
From: Dr Stephen Henson <[email-masked]>
To: [email-masked]
Subject: Re: [saag] Another bad day at the hash function factory
Sender: [email-masked]

Eric Rescorla wrote:

> 
> First, let me say that I'm extremely skeptical of this entire
> line of argument and doubt that it would convince a judge. 
> 
> That said, even if I thought you could make a convincing argument
> against non-repudiation based on hash collisions I don't think this
> example shows what you think it shows:
> 
> We have available:
> 
> * A certificate containing key A (retained by the CA)
> * A certificate containing key B (retained by the relying party)
> 
> The CA can demonstrate (to the extent that they can demonstrate
> this at all) that the attesting party obtained certificate A.
> 
> It's also easy to verify that certificates A and B have the
> same interior message digest value, so it's clear that something
> is fishy. 
> 
> However, it's easy to demonstrate that the cert holder is the one who
> is cheating, because they are the only one who could have generated
> the A,B pair. By assumption, collision attacks are possible but 2nd
> preimages are not, and its undisputed that the cert holder generated
> key A, therefore he must ALSO have generated key B.
> 

I also notice that the examples don't include the subject public key ID 
extension. If the CA used an appropriate recommended algorithm to 
generate SKID then it could demonstrate that the certificate containing 
A contained a consistent SKID whereas the one containing B did not.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

From: Sharon Boeyen <[email-masked]>
To: "pkix (pkix)" <[email-masked]>
Subject: Comments on SCVP draft 18
Date: Thu, 3 Mar 2005 16:05:12 -0500 
Sender: [email-masked]

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

------_=_NextPart_001_01C52034.B0B05716
Content-Type: text/plain

I have reviewed the SCVP draft 18 spec and would first like to congratulate
and thank the authors for the vast improvement in readability, clarity and
specificity with this draft.
 
My technical concerns/comments follow.
 
1) In Section 3.2.2 I am pleased with the changes Tim stated in response to
issue 6 of Denis' list where servers will no longer be mandated to support
DPD as a minimum but can support DPV alone. My concern is with the ability
of servers to perform additional checks beyond what the client requested but
the requirement that the server not tell the client it performed those
additional checks. This leads to a situation where, for example, a client
that requested only path building may get a response from a server saying
that no path could be built where in fact a path could have been built had
that server NOT done the extra checks of revocation status and/or
validation. The client is never told that this is the reason so they have no
way to know whether or not to try another server (if they specifically
wanted ONLY the requested checks performed) and they are misled into
believing that no path can be built. If a server performs additional checks
beyond what the client requested, and is providing a successful response to
the client then I agree that there is no need for the server to inform the
client about these additional checks. However, if the server is responding
with an error and that error was due to the additional checks they
performed, I believe that information must be returned to the client. At
least the client would then have the information they need in order to
determine whether an attempt to another server that doesn't perform those
additional checks may result in a different response. I base this opinion on
the belief that a client requests the type of checks they do for specific
reasons. For example if a client requests DPV without revocation checking
they've made that choice for some specific reason. Either they have
revocation information already available and prefer to do the check
themselves or they absolutely (for whatever reason) don't care about
revocation status. If they did care and did want the check done by the
server they would have asked for it. In these situations, if the server did
the revocation checking anyway and found no valid path due to the fact that
a certificate was revoked, the server should inform the client that did the
checking and that was the reason for the failure.
 
2) In 1.5 various CRL schemes are mentioned, but partitioned CRLs are not.
These should be added to the list. 
3) In 3.2.4.2 the last paragraph mandates that both SCVP clients and servers
support both the basic and the name validation algorithms. While I can
understand the rationale for mandating this for servers, I don't understand
why it is also mandated for clients. I think that should be left to
implementers and/or profiles (e.g. a secure email client profile may
certainly mandate client support for name validation for email addresses),
but this shouldn't be mandated for all clients but left up to profiles to
determine the mandatory/optional requirements for deployment
scenarios/applications.
4) In 3.2.4.7 it states that servers must support trustAnchors. This is one
that I think should not be mandated. In particular deployment scenarios the
trust anchors may be mandated by local policy and the servers may only be
permitted to use a specific set which are populated directly at the server.
I think this should be changed to a "should" in the draft and leave it up to
profiles to determine environments where it is mandated. 
 
Cheers,
Sharon

Sharon Boeyen
Entrust Inc
[email-masked] <mailto:[email-masked]> 
www.entrust.com <http://www.entrust.com/> 

------_=_NextPart_001_01C52034.B0B05716
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2900.2604" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff><SPAN class=837395815-03032005>I have reviewed the SCVP 
draft 18 spec and would first like to congratulate and thank the authors for the 
vast improvement in readability, clarity and specificity&nbsp;<SPAN 
class=151584420-03032005>with this </SPAN>draft.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff><SPAN 
class=837395815-03032005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff><SPAN class=837395815-03032005><SPAN 
class=151584420-03032005>My technical concerns/comments 
follow.</SPAN></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff><SPAN class=837395815-03032005><SPAN 
class=151584420-03032005></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff><SPAN class=837395815-03032005><SPAN 
class=151584420-03032005>1) In Section 3.2.2 I am pleased with the changes Tim 
stated in response to issue 6 of Denis' list where servers will no longer be 
mandated to support DPD as a minimum but can support DPV alone. My concern is 
with the ability of servers to perform additional checks beyond what the client 
requested but the requirement that the server not tell the client it performed 
those additional checks. This leads to a situation&nbsp;where, for example, a 
client that requested only path building may get a response from a server saying 
that no path could be built where in fact a path could have been built had that 
server NOT done the extra checks of revocation status and/or validation. The 
client is never told that this is the reason so they have no way to know whether 
or not to try another server (if they specifically wanted ONLY the requested 
checks performed) and they are misled into believing that no path can be built. 
If a server performs additional checks beyond what the client requested, and is 
providing a successful response to the client then I agree that there is no need 
for the server to inform the client about these additional checks. However, if 
the server is responding with an error and that error was due to the additional 
checks they performed, I believe that information must be returned to the 
client. At least the client would then have the information they need in order 
to determine whether an attempt to another server that doesn't perform those 
additional checks may result in a different response. I base this opinion on the 
belief that a client requests the type of checks they do for specific reasons. 
For example if a client requests DPV without revocation checking they've made 
that choice for some specific reason. Either they have revocation information 
already available and prefer to do the check themselves or they absolutely (for 
whatever reason) don't care about revocation status. If they did care and did 
want the check done by the server they would have asked for it. In these 
situations, if the server did the revocation checking anyway and found no valid 
path due to the fact that a certificate was revoked, the server should inform 
the client that did the checking and that was the reason for the 
failure.</SPAN></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff><SPAN class=837395815-03032005><SPAN 
class=151584420-03032005></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=837395815-03032005><SPAN class=151584420-03032005><FONT 
color=#0000ff>2) In 1.5 various CRL schemes are mentioned, but partitioned CRLs 
are not. These should be added to the list.</FONT>
<DIV>
<DIV><SPAN class=837395815-03032005><FONT 
color=#0000ff></FONT></SPAN></DIV><SPAN class=837395815-03032005></SPAN></DIV>
<DIV><SPAN class=837395815-03032005><FONT color=#0000ff><SPAN 
class=151584420-03032005>3</SPAN>) In 3.2.4.2 the last paragraph mandates that 
both SCVP clients and servers support both the basic and the name validation 
algorithms. While I can understand the rationale for mandating this for servers, 
I don't understand why it is also mandated for clients. I think that should be 
left to implementers and/or profiles (e.g. a secure email client profile may 
certainly mandate client support for name validation for email addresses), but 
this shouldn't be mandated for all clients<SPAN class=151584420-03032005> but 
left up to profiles to determine the mandatory/optional requirements for 
deployment scenarios/applications</SPAN>.</FONT></SPAN></DIV>
<DIV>
<DIV><SPAN class=837395815-03032005><FONT 
color=#0000ff></FONT></SPAN></DIV><SPAN class=837395815-03032005></SPAN></DIV>
<DIV><SPAN class=837395815-03032005><FONT color=#0000ff><SPAN 
class=151584420-03032005>4</SPAN>) In 3.2.4.7 it states that servers must 
support trustAnchors. This is one that I think should not be mandated. In 
particular deployment scenarios the trust anchors may be mandated by local 
policy and the servers may only be permitted to use a specific set<SPAN 
class=151584420-03032005> which are populated directly at the 
server</SPAN>.&nbsp;<SPAN class=151584420-03032005>I think this should be 
changed to a "should" in the draft&nbsp;and leave it up to profiles to determine 
environments where it is mandated.</SPAN>&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=837395815-03032005><FONT 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=837395815-03032005><SPAN class=151584420-03032005><FONT 
color=#0000ff>Cheers,</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=837395815-03032005><SPAN class=151584420-03032005><FONT 
color=#0000ff>Sharon</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=837395815-03032005><FONT 
color=#0000ff></FONT></SPAN>&nbsp;</DIV></SPAN></SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV align=left>Sharon Boeyen</DIV>
<DIV align=left>Entrust Inc</DIV>
<DIV align=left><A 
href="mailto:[email-masked]">[email-masked]</A></DIV>
<DIV align=left><A href="http://www.entrust.com/">www.entrust.com</A></DIV>
<DIV align=left>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C52034.B0B05716--

Date: Thu, 03 Mar 2005 14:21:09 -0600
From: Eric Norman <[email-masked]>
Subject: Re: [saag] Another bad day at the hash function factory
To: "[email-masked]'" <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mar 3, 2005, at 8:23 AM, Eric Rescorla wrote:

> Eric Norman <[email-masked]> writes:
>>
>> What evidence does the relying party have?  He has a recording of a
>> public
>> key (B), mathematical evidence that someone knows the associated 
>> private
>> key (B), and a claim that I control private key B.  But he doesn't
>> have proof of
>> that binding between claim of identity and keypair; he has to get such
>> evidence
>> from the CA that signed the certificate.  So he asks the CA to 
>> testify.
>>
>> What evidence does the CA have?  The CA has evidence that keypair A
>> belongs to me, but the CA has never seen public key B and has no
>> evidence
>> about it whatsoever.
>
> First, let me say that I'm extremely skeptical of this entire
> line of argument and doubt that it would convince a judge.

I am also skeptical, now.

> That said, even if I thought you could make a convincing argument
> against non-repudiation based on hash collisions I don't think this
> example shows what you think it shows:
>
> We have available:
>
> * A certificate containing key A (retained by the CA)
> * A certificate containing key B (retained by the relying party)
>
> The CA can demonstrate (to the extent that they can demonstrate
> this at all) that the attesting party obtained certificate A.
>
> It's also easy to verify that certificates A and B have the
> same interior message digest value, so it's clear that something
> is fishy.

I didn't think of that.  That is indeed pretty substantial evidence, 
isn't it?
In this example, there's even more evidence of fishyness in the public
keys themselves.  Save for a few bits here and there, they are virtually
identical.

Nevertheless, one of the points to remember is that all this 
non-repudiation
stuff is eventually going to come down to what it will take to convince 
a
judge.  What that means to me is that it's important to think about what
evidence will be available when that time comes, how the parties should
preserve and protect that evidence, and so forth.

Now, wouldn't it be neat to turn on our TV sets some day in the future 
and
hear Judge Judy say, "judgment for the plaintiff; the Hamming distance 
is
too small"?

Eric Norman
University of Wisconsin -- DoIT

Date: Thu, 03 Mar 2005 14:27:11 -0500
To: Sam Roberts <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

Some CAs issue very few certificates, so it is very easy to predict the 
next serial number that will be used by looking at the last certificate 
that was issued.

Russ

At 11:46 AM 3/3/2005, Sam Roberts wrote:

>Wrote Ben Laurie <[email-masked]>, on Thu, Mar 03, 2005 at 02:54:35PM 
>+0000:
> > The issue is not the length of the serial number but its predictability.
>
>I thought most CAs put some random component into the serial number, and
>even for ones that just using a simple integer count, it would seem
>quite difficult to predict the number of the next cert to be issued.
>
>So, can anybody describe practical prediction strategies?
>
>Cheers,
>Sam
>
>--
>Sam Roberts <[email-masked]>

Date: Thu, 3 Mar 2005 11:46:58 -0500
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Wrote Ben Laurie <[email-masked]>, on Thu, Mar 03, 2005 at 02:54:35PM +0000:
> The issue is not the length of the serial number but its predictability. 

I thought most CAs put some random component into the serial number, and
even for ones that just using a simple integer count, it would seem
quite difficult to predict the number of the next cert to be issued.

So, can anybody describe practical prediction strategies?

Cheers,
Sam

-- 
Sam Roberts <[email-masked]>

Date: Thu, 03 Mar 2005 14:54:35 +0000
From: Ben Laurie <[email-masked]>
To: Tom Gindin <[email-masked]>
Cc: Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

Tom Gindin wrote:
>         Ben:
> 
>         The requirement for the attack is that the part of the 
> TBSCertificate up to the public key be an even multiple of 64 octets.  The 
> example is 256.  Using a 160 bit serial number instead of the 32 bits in 
> the example would just require decreasing the length of the subject and 
> issuer by a total of 16 octets or increasing it by a total of 48 octets. 
> In practice, the issuer name doesn't change for a given CA, although ones 
> shorter than 63 octets certainly exist, and subject names can exceed the 
> length of their issuer by amounts quite different than 35 octets.  In 
> fact, the example's junk subject OU is 27 octets long - reduce that to 11 
> and you've reproduced the attack with a 20 octet serial number.

The issue is not the length of the serial number but its predictability. 
You have to know the serial number in advance in order to generate the 
collision (because you have to know what they call the IV - i.e. the 
chaining values).

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

To: Eric Norman <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [saag] Another bad day at the hash function factory
Reply-To: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: Thu, 03 Mar 2005 06:23:53 -0800
Sender: [email-masked]

Eric Norman <[email-masked]> writes:
> Santosh seems to have asked the key question, "what is the threat?"
> I think Jean-Marc has come close to answering it.
>
> First of all, it doesn't have anything to do with serial numbers or
> anything else
> in certificates other than public keys.  The threat is against the
> non-repudiation
> support of PKI.  Here's how I would describe a possible attack.
>
> I generate two different bit strings that will cause an MD5 collision.
>
> I set my computers to work for a few hours to turn those bit strings
> into public
> keys that will also collide, and I know the associated private keys.
> Call these
> keypair A and keypair B.  This is what's detailed in the paper.
>
> I send public key A off to a certification authority, provide proof of
> possession
> (private key A), whatever identity information is appropriate, and
> receive a
> certificate from the CA.
>
> I replace the public key of that certificate with public key B to get
> certificate B.
> Everything in certificate B is identical to what's in certificate A
> except for the
> public key part.  And the signature by the CA in certificate B still
> verifies!
>
> I now sign something using private key B and send along certificate B
> for
> purposes of verification.
>
> The relying party uses public key B to verify my signature, the
> relying party
> relies on that and does whatever.  The relying party can even record the
> entire certificate (certificate B) as evidence to be used in case of
> repudiation.
>
> I come along later and claim that I didn't sign that and therefore I
> don't owe
> the relying party anything, or whatever.
>
> What evidence does the relying party have?  He has a recording of a
> public
> key (B), mathematical evidence that someone knows the associated private
> key (B), and a claim that I control private key B.  But he doesn't
> have proof of
> that binding between claim of identity and keypair; he has to get such
> evidence
> from the CA that signed the certificate.  So he asks the CA to testify.
>
> What evidence does the CA have?  The CA has evidence that keypair A
> belongs to me, but the CA has never seen public key B and has no
> evidence
> about it whatsoever.
>
> The only place evidence about keypair B exists is on my equipment and
> since
> I'm a very thorough miscreant, I have destroyed it just in case
> someone comes
> along with a search warrant.

First, let me say that I'm extremely skeptical of this entire
line of argument and doubt that it would convince a judge. 

That said, even if I thought you could make a convincing argument
against non-repudiation based on hash collisions I don't think this
example shows what you think it shows:

We have available:

* A certificate containing key A (retained by the CA)
* A certificate containing key B (retained by the relying party)

The CA can demonstrate (to the extent that they can demonstrate
this at all) that the attesting party obtained certificate A.

It's also easy to verify that certificates A and B have the
same interior message digest value, so it's clear that something
is fishy. 

However, it's easy to demonstrate that the cert holder is the one who
is cheating, because they are the only one who could have generated
the A,B pair. By assumption, collision attacks are possible but 2nd
preimages are not, and its undisputed that the cert holder generated
key A, therefore he must ALSO have generated key B.

It's worth mentioning that in current practice, facsimile copies of
holographic signatures are considered legally binding even though they
have essentially no binding to the underlying document and are trivial
to forge using photoshop. It's the intention that counts, not proof
that the signature occurred. Note also that when you sign a paper
document, nothing stops you from making some signature mark that
doesn't look at all like your real signature. I assure you that this
doesn't mean that you're not bound to the contract.
 
-Ekr

To: Ben Laurie <[email-masked]>
Cc: Russ Housley <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
From: Tom Gindin <[email-masked]>
Date: Thu, 3 Mar 2005 08:44:17 -0500
Sender: [email-masked]

        Ben:

        The requirement for the attack is that the part of the 
TBSCertificate up to the public key be an even multiple of 64 octets.  The 
example is 256.  Using a 160 bit serial number instead of the 32 bits in 
the example would just require decreasing the length of the subject and 
issuer by a total of 16 octets or increasing it by a total of 48 octets. 
In practice, the issuer name doesn't change for a given CA, although ones 
shorter than 63 octets certainly exist, and subject names can exceed the 
length of their issuer by amounts quite different than 35 octets.  In 
fact, the example's junk subject OU is 27 octets long - reduce that to 11 
and you've reproduced the attack with a 20 octet serial number.
        Of course, RFC 2459 (6 years ago now) recommended that SHA-1 be 
preferred over MD5, as did RFC 3279, so we don't need to change the format 
of any fields in a certificate to prevent this attack for MD5.  However, 
if this class of attacks should be successfully extended to SHA-1, we 
might need to do something about it.
        If an issuer actually worried about an attack similar to this 
against SHA-1, he might be best off disrupting it by putting padding into 
a certificate if needed to make the actual public key (including any 
leading zero) start at an offset between (say) 6 and 58 mod 64.  The 
interoperability effects of that, of course, are worrying, even if all you 
did was replace the signature parameter field (a NULL normally for RSA 
with a hash) by a junk octet string not to exceed 12 octets.  Since this 
octet string itself permits more collision possibilities if it contains 
random data, it would need to be regulated as if it were PKCS#5 padding or 
something like that (i.e., every octet contains the length of the pad, or 
perhaps every octet in the pad is one more than its predecessor).

                Tom Gindin

P.S.    The above suggestion is mine, solely intended as a basis for 
discussion, and not that of my employer.  Even personally, I am NOT 
suggesting that any issuer implement this suggestion at present.

Ben Laurie <[email-masked]>
Sent by: [email-masked]
03/02/2005 07:37 AM
 
        To:     Paul Hoffman <[email-masked]>
        cc:     Russ Housley <[email-masked]>, [email-masked], 
[email-masked]
        Subject:        Re: [saag] X.509 certificate collision, via MD5 
collisions

Paul Hoffman wrote:
> 
> At 6:24 PM -0500 3/1/05, Russ Housley wrote:
> 
>> I have not had an opportunity to review this document yet, but the 
>> findings need to be shared with the whole Internet security community.
>>
>>> We announce a method for the construction of pairs of valid X.509 
>>> certificates in which the "to
>>> be signed" parts form a collision for the MD5 hash function. As a 
>>> result the issuer signatures
>>> in the certificates will be the same when the issuer uses MD5 as its 
>>> hash function.
>>
>>
>> http://eprint.iacr.org/2005/067
> 
> 
>  From the description in the paper, it appears that step 1 requires that 

> the template for the certificate must be known before you create the two 

> RSA keys. If that is true, then a CA who uses long serial numbers either 

> randomly or based on a secret would automatically foil this attack. (I 
> could be misreading the requirement, of course.)

I believe that is correct.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Date: Wed, 02 Mar 2005 19:49:03 -0600
From: Eric Norman <[email-masked]>
Subject: Re: [saag] Another bad day at the hash function factory
To: "[email-masked]'" <[email-masked]>, [email-masked]
Sender: [email-masked]

Here's my take.

Santosh seems to have asked the key question, "what is the threat?"
I think Jean-Marc has come close to answering it.

First of all, it doesn't have anything to do with serial numbers or 
anything else
in certificates other than public keys.  The threat is against the 
non-repudiation
support of PKI.  Here's how I would describe a possible attack.

I generate two different bit strings that will cause an MD5 collision.

I set my computers to work for a few hours to turn those bit strings 
into public
keys that will also collide, and I know the associated private keys.  
Call these
keypair A and keypair B.  This is what's detailed in the paper.

I send public key A off to a certification authority, provide proof of 
possession
(private key A), whatever identity information is appropriate, and 
receive a
certificate from the CA.

I replace the public key of that certificate with public key B to get 
certificate B.
Everything in certificate B is identical to what's in certificate A 
except for the
public key part.  And the signature by the CA in certificate B still 
verifies!

I now sign something using private key B and send along certificate B 
for
purposes of verification.

The relying party uses public key B to verify my signature, the relying 
party
relies on that and does whatever.  The relying party can even record the
entire certificate (certificate B) as evidence to be used in case of 
repudiation.

I come along later and claim that I didn't sign that and therefore I 
don't owe
the relying party anything, or whatever.

What evidence does the relying party have?  He has a recording of a 
public
key (B), mathematical evidence that someone knows the associated private
key (B), and a claim that I control private key B.  But he doesn't have 
proof of
that binding between claim of identity and keypair; he has to get such 
evidence
from the CA that signed the certificate.  So he asks the CA to testify.

What evidence does the CA have?  The CA has evidence that keypair A
belongs to me, but the CA has never seen public key B and has no 
evidence
about it whatsoever.

The only place evidence about keypair B exists is on my equipment and 
since
I'm a very thorough miscreant, I have destroyed it just in case someone 
comes
along with a search warrant.

Eric Norman
University of WIsconsin -- DoIT

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Date: Wed, 2 Mar 2005 14:08:02 -0500
Importance: Normal
Sender: [email-masked]

Russ,

See responses in-line under [Santosh:]

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, March 02, 2005 1:41 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions

Santosh:

>When I read the paper, the primary concern I come away with and the 
>authors tend to communicate is "proof of possession" of private key.  
>That is not done using X.509 certificates.  It is done using PKCS-10 
>requests.  When you look at the PKCS-10 structure, there is no serial 
>number and the authors' attack is still plausible.  Randomizing the 
>serial number or adding a random number will not help there.

The serial number is selected by the CA; however, there are CAs that issue 
very few certificates, so it is easy to guess the serial number that they 
will pick.  In the past, I have recommended the use of large serial numbers 
where the first part is a monotonically increasing integer and the second 
part is random.  A 64-bit random value should thwart this attack.  I am 
totally confused by your assertion that it will not.  Please explain.

[Santosh: I am not saying that a subscriber who can predict the serial
number can not mint the second certificate.  She can.  But, them what?  What
practical break she can cause?  I am not in favor of changing the standard
when there is no practical threat and folks are using an algorithm that they
should have stopped using a while back, not just last summer.  64 bits of
unbroken MD5 security was not same is 78-80 bits of 1024 RSA.] 

>But, it does not seem to violate the security of PKI since all it does 
>is allow the subscriber to get one public key certified and have 
>another key that matches the certificate.

The concern is that it will appear that the subject has two 
certificates.  The CA's signature value is the same on both of the 
certificates.

[Santosh: And then how does some one exploit it?]

I disagree with this conclusion.  Consider a replying party that validates 
a signed message using such a certificate.  They take some action based on 
the content of the signed message; say they send 1000 widgets to an address 
in the message.  The relying party then sends a bill for the widgets.  The 
subject says: "Hey, I did not order these widgets, and I am not going to 
pay for them."  The subject then produces the second certificate, claiming 
that it is his, not the one used to sign the message.  He says: "If you 
produce a message ordering the widgets that can be validated with this 
certificate, then I will pay."

[Santosh: Both scenarios boil down to trusting the mathematics of
cryptography.  Just the way mathematics tells no one other than the
subscriber possesses the private key corresponding to a public key, the
Lenstra paper shows that the subscriber possesses both keys.]

Russ

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Date: Wed, 2 Mar 2005 13:59:20 -0500
Importance: Normal
Sender: [email-masked]

Jean-Marc,

I realize that the subscriber may be able to predict serial number can mint
a valid certificate, but needs to have both key pairs.

Thus, practically, I do not see what the threat is.

It is clearly something undesirable, but I am not in favor of trying to
accommodate something for MD5.  We should not be using that algorithm.  Why
beat a dead horse or spend money on a lost cause.

I am also worried about collisions that can cause you to masquerade as a CA
or another person.  But, this paper does not show that.

-----Original Message-----
From: Jean-Marc Desperrier [mailto:[email-masked]] 
Sent: Wednesday, March 02, 2005 1:42 PM
To: Santosh Chokhani; [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions

Santosh Chokhani wrote:

>But, it does not seem to violate the security of PKI since all it does 
>is allow the subscriber to get one public key certified and have 
>another key that matches the certificate.
>  
>
Did you read my description of the signature denial threat ?

There's quite a few mitigating factors, but it seems to me to be a very 
real threat.

>[...]
>In summary, I do not see a practical threat from the attack and any 
>mitigation should be for PKCS-10 and not X.509.
>  
>
And there I'm almost of complete opposite mind.

The attacker can only construct the attack by creating both key pairs, 
so owning both private keys.

Creating a collision over an already existing key would be IMO a very 
difficult extension of the attack.
I think we're more endangered by the risk someone may one day be able to 
extend the attack to finding a collision for two certificates where one 
or two bits of the content outside of the public modulus would be 
different, for exemple the CA bit in the Basic Property extension.

I know the author talk about what you say in the announcement. I'm pretty
confident they got it wrong. Either the owner of the key pair created the
collision, and owns both 
key pair, or we're talking of someone using a key pair he didn't create 
himself, which is an obvious security risk even without that attack.

Date: Wed, 02 Mar 2005 13:40:40 -0500
To: "Santosh Chokhani" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Cc: [email-masked]
Sender: [email-masked]

Santosh:

>When I read the paper, the primary concern I come away with and the authors
>tend to communicate is "proof of possession" of private key.  That is not
>done using X.509 certificates.  It is done using PKCS-10 requests.  When you
>look at the PKCS-10 structure, there is no serial number and the authors'
>attack is still plausible.  Randomizing the serial number or adding a random
>number will not help there.

The serial number is selected by the CA; however, there are CAs that issue 
very few certificates, so it is easy to guess the serial number that they 
will pick.  In the past, I have recommended the use of large serial numbers 
where the first part is a monotonically increasing integer and the second 
part is random.  A 64-bit random value should thwart this attack.  I am 
totally confused by your assertion that it will not.  Please explain.

>But, it does not seem to violate the security of PKI since all it does is
>allow the subscriber to get one public key certified and have another key
>that matches the certificate.

The concern is that it will appear that the subject has two 
certificates.  The CA's signature value is the same on both of the 
certificates.

I disagree with this conclusion.  Consider a replying party that validates 
a signed message using such a certificate.  They take some action based on 
the content of the signed message; say they send 1000 widgets to an address 
in the message.  The relying party then sends a bill for the widgets.  The 
subject says: "Hey, I did not order these widgets, and I am not going to 
pay for them."  The subject then produces the second certificate, claiming 
that it is his, not the one used to sign the message.  He says: "If you 
produce a message ordering the widgets that can be validated with this 
certificate, then I will pay."

Russ

Date: Wed, 02 Mar 2005 19:41:52 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: Santosh Chokhani <[email-masked]>, [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

Santosh Chokhani wrote:

>But, it does not seem to violate the security of PKI since all it does is
>allow the subscriber to get one public key certified and have another key
>that matches the certificate.
>  
>
Did you read my description of the signature denial threat ?

There's quite a few mitigating factors, but it seems to me to be a very 
real threat.

>[...]
>In summary, I do not see a practical threat from the attack and any
>mitigation should be for PKCS-10 and not X.509.
>  
>
And there I'm almost of complete opposite mind.

The attacker can only construct the attack by creating both key pairs, 
so owning both private keys.

Creating a collision over an already existing key would be IMO a very 
difficult extension of the attack.
I think we're more endangered by the risk someone may one day be able to 
extend the attack to finding a collision for two certificates where one 
or two bits of the content outside of the public modulus would be 
different, for exemple the CA bit in the Basic Property extension.

I know the author talk about what you say in the announcement.
I'm pretty confident they got it wrong.
Either the owner of the key pair created the collision, and owns both 
key pair, or we're talking of someone using a key pair he didn't create 
himself, which is an obvious security risk even without that attack.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: [saag] X.509 certificate collision, via MD5 collisions
Date: Wed, 2 Mar 2005 10:51:06 -0500
Importance: Normal
Sender: [email-masked]

When I read the paper, the primary concern I come away with and the authors
tend to communicate is "proof of possession" of private key.  That is not
done using X.509 certificates.  It is done using PKCS-10 requests.  When you
look at the PKCS-10 structure, there is no serial number and the authors'
attack is still plausible.  Randomizing the serial number or adding a random
number will not help there.

But, it does not seem to violate the security of PKI since all it does is
allow the subscriber to get one public key certified and have another key
that matches the certificate.

I also find the assertions at the beginning and at the end of the paper
contradictory.  The beginning of the paper says that the CA does not have
proof of possession, but the SPKI generator knows the four primes and hence
can deduce the two private keys and that is asserted at the end of the
paper.

In summary, I do not see a practical threat from the attack and any
mitigation should be for PKCS-10 and not X.509.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean-Marc Desperrier
Sent: Wednesday, March 02, 2005 6:33 AM
To: [email-masked]; [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions

Paul Hoffman wrote:

> At 6:24 PM -0500 3/1/05, Russ Housley wrote:
>
>>> We announce a method for the construction of pairs of valid X.509
>>> certificates in which the "to
>>> be signed" parts form a collision for the MD5 hash function. As a 
>>> result the issuer signatures
>>> in the certificates will be the same when the issuer uses MD5 as its 
>>> hash function.
>>
>>
>> http://eprint.iacr.org/2005/067
>
> From the description in the paper, it appears that step 1 requires
> that the template for the certificate must be known before you create 
> the two RSA keys. If that is true, then a CA who uses long serial 
> numbers either randomly or based on a secret would automatically foil 
> this attack. (I could be misreading the requirement, of course.)

I reach the following conclusion from reading the article :

- The attacker must be able to know beforehand the serial number
- The attacker must be able to know beforehand the validity limit
- The attacker must be able to choose both keys
- Everything in the two certificates will be identical except for the 
public key information
This can change if a method fo find a collision if the IV vector value 
is not identifical is found.
Also if a method can be found to create a delayed collision (I mean by 
that a collision where the choosen value does not directly create the 
collision, where the collision appears only after appending to it some 
fixed data), it will completely change the scale of the attack.

Right now, the attack I see enabled by this method is a deniability attack.

The method would be the following :
- construct a pair of colliding certificate with the two associated key 
pairs, A and B
- register key pair A with a public CA
- Require a service from a provider
- Sign to prove you required the service with key pair B.
- Show to the provider the certificate associated with key pair B to 
prove your identity. All verifications will succeed.
- To be usable, the method require that the provider, instead of keeping 
the certificat you provided for verification, only keeps it's 
identification with regard to the CA, for exemple issuer/serial
- Later, you can deny having signed the transaction, and verification 
using the certificate registered with the CA will fail, apparently 
showing that the provider had initially failed to correctly check the 
signature.

Signature scheme that include a hash of the certificat that was used to 
do the signature will protect against this attack. In the other case, 
people should be certain they keep a copy of the certficate they used to 
verify the signature, and not rely on the possibility to get it again 
from a directory.

(Have to remove [email-masked] from the distribution, I'm not registered)

**

To: Matt Crawford <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Reply-To: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: Wed, 02 Mar 2005 07:46:37 -0800
Sender: [email-masked]

Matt Crawford <[email-masked]> writes:

> On Mar 1, 2005, at 18:08, Paul Hoffman wrote:
>
>>> http://eprint.iacr.org/2005/067
>>
>> From the description in the paper, it appears that step 1 requires
>> that the template for the certificate must be known before you
>> create the two RSA keys. If that is true, then a CA who uses long
>> serial numbers either randomly or based on a secret would
>> automatically foil this attack. (I could be misreading the
>> requirement, of course.)
>
> What's more, the two certificates are identical in every field before
> the public RSA modulus -- including the SubjectDN.  This is less
> interesting than it might be.  But clearly it would be foolish to
> believe that collisions with different SubjectDNs won't follow soon.

That's probably true, but they're likely to be basically random.
In Wang attack is that the colliding values aren't very
controllable...

-Ekr

Date: Wed, 02 Mar 2005 12:37:01 +0000
From: Ben Laurie <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: Russ Housley <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

Paul Hoffman wrote:
> 
> At 6:24 PM -0500 3/1/05, Russ Housley wrote:
> 
>> I have not had an opportunity to review this document yet, but the 
>> findings need to be shared with the whole Internet security community.
>>
>>> We announce a method for the construction of pairs of valid X.509 
>>> certificates in which the "to
>>> be signed" parts form a collision for the MD5 hash function. As a 
>>> result the issuer signatures
>>> in the certificates will be the same when the issuer uses MD5 as its 
>>> hash function.
>>
>>
>> http://eprint.iacr.org/2005/067
> 
> 
>  From the description in the paper, it appears that step 1 requires that 
> the template for the certificate must be known before you create the two 
> RSA keys. If that is true, then a CA who uses long serial numbers either 
> randomly or based on a secret would automatically foil this attack. (I 
> could be misreading the requirement, of course.)

I believe that is correct.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Date: Wed, 02 Mar 2005 12:32:42 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

Paul Hoffman wrote:

> At 6:24 PM -0500 3/1/05, Russ Housley wrote:
>
>>> We announce a method for the construction of pairs of valid X.509 
>>> certificates in which the "to
>>> be signed" parts form a collision for the MD5 hash function. As a 
>>> result the issuer signatures
>>> in the certificates will be the same when the issuer uses MD5 as its 
>>> hash function.
>>
>>
>> http://eprint.iacr.org/2005/067
>
> From the description in the paper, it appears that step 1 requires 
> that the template for the certificate must be known before you create 
> the two RSA keys. If that is true, then a CA who uses long serial 
> numbers either randomly or based on a secret would automatically foil 
> this attack. (I could be misreading the requirement, of course.)

I reach the following conclusion from reading the article :

- The attacker must be able to know beforehand the serial number
- The attacker must be able to know beforehand the validity limit
- The attacker must be able to choose both keys
- Everything in the two certificates will be identical except for the 
public key information
This can change if a method fo find a collision if the IV vector value 
is not identifical is found.
Also if a method can be found to create a delayed collision (I mean by 
that a collision where the choosen value does not directly create the 
collision, where the collision appears only after appending to it some 
fixed data), it will completely change the scale of the attack.

Right now, the attack I see enabled by this method is a deniability attack.

The method would be the following :
- construct a pair of colliding certificate with the two associated key 
pairs, A and B
- register key pair A with a public CA
- Require a service from a provider
- Sign to prove you required the service with key pair B.
- Show to the provider the certificate associated with key pair B to 
prove your identity. All verifications will succeed.
- To be usable, the method require that the provider, instead of keeping 
the certificat you provided for verification, only keeps it's 
identification with regard to the CA, for exemple issuer/serial
- Later, you can deny having signed the transaction, and verification 
using the certificate registered with the CA will fail, apparently 
showing that the provider had initially failed to correctly check the 
signature.

Signature scheme that include a hash of the certificat that was used to 
do the signature will protect against this attack. In the other case, 
people should be certain they keep a copy of the certficate they used to 
verify the signature, and not rely on the possibility to get it again 
from a directory.

(Have to remove [email-masked] from the distribution, I'm not registered)

**

Date: Tue, 1 Mar 2005 16:08:30 -0800
To: Russ Housley <[email-masked]>, [email-masked], [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: [saag] X.509 certificate collision, via MD5 collisions
Sender: [email-masked]

At 6:24 PM -0500 3/1/05, Russ Housley wrote:
>I have not had an opportunity to review this document yet, but the 
>findings need to be shared with the whole Internet security 
>community.
>
>>We announce a method for the construction of pairs of valid X.509 
>>certificates in which the "to
>>be signed" parts form a collision for the MD5 hash function. As a 
>>result the issuer signatures
>>in the certificates will be the same when the issuer uses MD5 as 
>>its hash function.
>
>http://eprint.iacr.org/2005/067

 From the description in the paper, it appears that step 1 requires 
that the template for the certificate must be known before you create 
the two RSA keys. If that is true, then a CA who uses long serial 
numbers either randomly or based on a secret would automatically foil 
this attack. (I could be misreading the requirement, of course.)

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 01 Mar 2005 18:28:01 -0500
To: Denis Pinkas <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: Re: Comments to SCVP ID 17
Cc: [email-masked]
Sender: [email-masked]

<html>
At 10:23 AM 2/28/2005 +0100, you wrote:<br><br>
<blockquote type=cite class=cite cite>Here are some revised comments,
based on the previous e-mail.<br><br>
1. A new wording introduced in the document which is: �PKI policies�.
This<br>
term is defined nowhere in RFC 3280, nor in this document. When it
is<br>
used, it seems to mean �validation policy�. Please delete everywhere
�PKI<br>
policy� and replace it with �validation policy�.<br><br>
</blockquote><br>
Both occurrences of &quot;PKI policies&quot; have been changed to
&quot;validation policies&quot; to align with 3379.&nbsp; (There were no
occurrences of &quot;PKI policy&quot;.)<br><br>
<br>
<blockquote type=cite class=cite cite>2. On page 7 the new term �basic
certification path processing algorithm�<br>
is introduced whereas RFC 3280 uses a different wording :<br><br>
&nbsp;- �certification path validation� (that is the title of section 6)
and<br>
&nbsp;- �basic path validation� (that is the title of section
6.1).<br><br>
Please do not introduce a new term.<br>
</blockquote><br>
<font face="Times New Roman, Times">The sentence will be revised as
follows:<br><br>
SCVP defines a basic validation algorithm which implements the basic path
validation algorithm as defined in [PKIX-1], and permits the client to
request additional information about the certificate to be
validated.&nbsp; <br><br>
<br>
</font><blockquote type=cite class=cite cite>3. The text refers to
section 6.1.1 and it is said that one the input in<br>
section 6.1.1 is a �Set of Trust Anchors�. This is not consistent
with<br>
section 6.1.1 from RFC3280 which deals with a *single* trust 
anchor,<br>
while section 6.2 from RFC 3280 deals with multiple trust
anchors.<br><br>
 From the introduction, �a validation policy contains one or more
trust<br>
anchors�. The protocol should allow, with a single request-response,
to<br>
check if a certificate is valid against a validation policy which
has<br>
more than one trust anchor. These checks should be done in
accordance<br>
with section 6.2 from RFC 3280. The current ASN.1 is not conformant
with<br>
section 6.1 from RFC 3280.<br>
</blockquote><br>
The trust anchor text will be removed from the list associated with 6.1.1
and relegated to the following paragraph.&nbsp; The following paragraph
will state the options and use cases.&nbsp; <br><br>
<font face="Courier New, Courier">&nbsp;&nbsp;&nbsp; The inputs to the
basic certification path processing algorithm<br>
&nbsp;&nbsp;&nbsp; used by SCVP are defined by [PKIX-1] in section 6.1.1
and <br>
&nbsp;&nbsp;&nbsp; comprise:<br>

<dl>
<dl>
<dd>Certificate to be validated (by value or by reference);<br><br>

<dd>Validation time;<br><br>

<dd>The initial policy set;<br><br>

<dd>Initial inhibit policy mapping setting;<br><br>

<dd>Initial inhibit anyPolicy setting; and<br><br>

<dd>Initial require explicit policy setting.<br><br>
</font>
</dl>
</dl>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The basic certification path
processing algorithm also supports specification of one or <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; more Trust Anchors (by value or
reference) as an input.&nbsp; Where the client demands a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certification originating with a
specific CA, a single Trust Anchor is specified.&nbsp; Where<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the client is willing to accept
paths beginning with any of several CAs, a set of Trust<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; anchors is specified.<br><br>
<br>
<blockquote type=cite class=cite cite>4. Section 1.4 is about a
validation algorithm. Different rules may apply<br>
to every trust anchor and to the CA certificates from the
certification<br>
path under every trust anchor. The ASN.1 description of
ValidationPolicy<br>
starting on page 17 does not allow the client to define CA related<br>
different parameters for every trust anchor.<br><br>
We currently have:<br><br>
ValidationPolicy ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
validationPolRef&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValidationPolRef,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
validationAlg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [0]
ValidationAlg OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
userPolicySet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [1]
SEQUENCE SIZE (1..MAX) OF OBJECT<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IDENTIFIER OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; inhibitPolicyMapping&nbsp; [2]
BOOLEAN OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; requireExplicitPolicy [3] BOOLEAN
OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
inhibitAnyPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [4] BOOLEAN 
OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
trustAnchors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [6]
TrustAnchors OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
keyUsages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[7] KeyUsages OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
extendedKeyUsages&nbsp;&nbsp;&nbsp;&nbsp; [8] SEQUENCE OF KeyPurposeId
OPTIONAL}<br><br>
and<br><br>
ValidationAlg ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
valAlgId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OBJECT IDENTIFIER,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
parameters&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ANY DEFINED BY valAlgId OPTIONAL }<br><br>
If:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
trustAnchors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [6]
TrustAnchors OPTIONAL,<br><br>
is changed into:<br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
trustAnchor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [6]
TrustAnchor OPTIONAL,<br><br>
&nbsp;... then this would be conformant with the algorithm from section
6.1 of<br>
RFC 3280, but validation policies with multiple trust anchors and
their<br>
own parameters could not be used.<br><br>
The conditions that apply to CA certificates may be very complicated
and<br>
vary from one trust anchor to another. The goal if this document is
to<br>
support section 6.2 from FRC 3280.<br>
</blockquote><br><br>
Using your ASN.1, the client would need to repeat the request for each
Trust Anchor.<br><br>
Using the current ASN.1, the client could use a single request for each
set of Trust Anchors that shared the set of parameters.&nbsp; If the
client wishes to specify different parameters, then the client must use
multiple requests.<br><br>
In my opinion, the current ASN.1 provides a reasonable compromise between
complexity and functionality.<br><br>
<br>
<blockquote type=cite class=cite cite>A validation policy could
OPTIONALLY include several �target certificate<br>
specific parameters� as Wen-Cheng proposed, since they usually do
not<br>
change from one trust anchor to another.<br><br>
This would also solve the problem that Wen-Cheng noticed about the
�name<br>
validation algorithm�.<br><br>
Note that, as Wen-Cheng proposed, �target certificate� seems to be 
a<br>
better term rather than �end certificate�<br><br>
It is obvious that for each certification path, the algorithm from<br>
section 6.1 of RFC 3280 is being used. The validationAlg parameter is
not<br>
needed. </blockquote><br>
We have already given the counter example (proxy certs) where this
parameter *is* needed.<br><br>
<br>
<blockquote type=cite class=cite cite>We could then simply 
have:<br><br>
ValidationPolicy ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
validationPolRef&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ValidationPolRef,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
keyUsages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[0] KeyUsages OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
extendedKeyUsages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [1] SEQUENCE
OF KeyPurposeId OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nameValidationAlgParms&nbsp;&nbsp;
[2] NameValidationAlgParms OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
otherTests&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[3] OtherTests OPTIONAL<br>
&nbsp;&nbsp; }<br><br>
additionalTests could be used for example to test QCStatements
extensions<br>
presence and values, which would be very useful for Qualified<br>
Certificates.<br>
</blockquote><br>
Other tests are currently supported in conjunction with the validation
algorithm.<br><br>
<br>
<blockquote type=cite class=cite cite>5.Section 1.5 states: �However,
revocation checking is an optional<br>
feature in [PKIX-1], ... � This is incorrect.<br><br>
RFC 3280 does not say that revocation checking is optional. Only
CRLs<br>
processing is defined in RFC 3280 but we all know that OCSP is an<br>
alternative method. For DPV, revocation checking MUST be done to
validate<br>
a certification path, but this may be done using different means.
This<br>
means may be specified in the validation policy.<br>
</blockquote><br>
First, I am not sure what change(s) you are advocating here.&nbsp; Is the
problem this sentence or are you advocating additional restrictions on
DPV services?<br><br>
Second, I also do not agree with your interpretation of 3280.<br><br>
In RFC 3280, CAs are required to either issue CRLs or have another
mechanism to distribute that information.&nbsp; (No restrictions are
specified on that mechanism so I presume publishing it in the New York
Times would be okay.)&nbsp; RFC 3280 does not explicitly impose these
requireemnts on relying parties.&nbsp; In fact, there are indications in
both 3280 and 3647 that revocation checking need not be performed by
relying parties.&nbsp; <br><br>
 From the security considerations section in RFC 3280:<br><br>
&nbsp;&nbsp;&nbsp; Similarly, implementations of the certification path
validation mechanism described in<br>
&nbsp;&nbsp;&nbsp; section 6 that omit revocation checking provide less
assurance than those that support it. <br><br>
RFC 3647, section 4.4.9 bullet 6 implies that revocation checking is
optional:<br><br>
&nbsp;&nbsp; * The mechanisms, if any, that a relying party may use or
must use in order to<br>
&nbsp;&nbsp; check the status of certificates on which they wish to rely;
<br><br>
This text corresponds to the heading &quot;4.9.6 Revocation checking
requirement for relying parties&quot; in the suggested outline.<br><br>
<br><br>
<blockquote type=cite class=cite cite>6. It should be remembered that RFC
3379 makes the separation between DPV<br>
and DPD, while this document defines a single protocol for both of
them.<br>
At the minimum the document should be profiled so that implementers
may<br>
choose to support only DPV and not be forced to support also
DPD.</blockquote><br>
We will change section 3.2.2 so that DPV servers need not support the
id-stc-build-pkc-path check.&nbsp; <br><br>
&nbsp; Conforming SCVP server implementations that support delegated path
discovery (DPD) as<br>
&nbsp;&nbsp; defined in [RQMTS] MUST support the id-stc-build-pkc-path
check.&nbsp; <br><br>
We will change section 3.2.3 to clearly delineate the wantBacks that must
be supported by DPD and DPV server implementations.<br><br>
&nbsp;&nbsp; All conforming SCVP server implementations MUST support the
id-swb-pkc-cert and<br>
&nbsp;&nbsp; id-swb-pkc-public-key-info wantBacks.&nbsp; Conforming SCVP
server implementations that<br>
&nbsp;&nbsp; support delegated path discovery (DPD) as defined in [RQMTS]
MUST support the<br>
&nbsp;&nbsp; id-swb-pkc-best-cert-path and id-swb-pkc-revocation-info
wantBacks.&nbsp; Conforming SCVP<br>
&nbsp;&nbsp; server implementations that support delegated path
validation (DPV) as defined in [RQMTS]<br>
&nbsp;&nbsp; MUST support the id-swb-pkc-cert-status wantBack.<br><br>
<br>
<blockquote type=cite class=cite cite>7. �SCVP� is a not a good name when
the request is to only build a<br>
certification path - with or without revocation status (i.e. DPD,
leaving<br>
the validation to the client). The certificate is not VALIDATED by
the<br>
server, and even if it would, the client would not trust it. If
someone<br>
says : �I support SCVP�, how could it make clear that it only
supports<br>
the DPV variant of it ?<br><br>
Better names would be:<br><br>
&nbsp;- DPVP: Delegated Path Validation Protocol, and<br>
&nbsp;- DPDP: Delegated Path Discovery Protocol.<br>
</blockquote><br>
Regardless of the mode (DPD vs. DPV) the goal is to simplify certificate
validation.&nbsp; In one case we offload path discovery and perform
validation locally.&nbsp; In the second case, both processes are
offloaded to the server.<br><br>
It is not so hard to clarify which services are supported.&nbsp; They
could say &quot;Our DPV server (client) implements SCVP as specified in
RFC WXYZ&quot;.&nbsp;&nbsp; This is not new or too difficult.&nbsp; When
ever there are optional features in a standard, the simple statement
(&quot;I support RFC 3280/2560/whatever&quot;) is insufficient.&nbsp;
<br><br>
<br>
<blockquote type=cite class=cite cite>8. The text correctly states on
page 6: �An SCVP request needs only to<br>
contain the certificate to be validated, the referenced validation<br>
policy, and any run-time parameters for the request�.<br><br>
It would be very beneficial to be able to have implementations that
only<br>
support the above requirements for DPV, leaving the security
protection<br>
(i.e. integrity) to the communication link (i.e. using TLS) and not<br>
supporting other parameters (with the exception of the above
optional<br>
�target certificate specific parameters� as Wen-Cheng proposed). It
is<br>
currently not straightforward to derive from the current document a<br>
profile for this.<br><br>
It is suggested to revise the document so that this goal can be
achieved<br>
and that conformance clauses are added to be able to say that a
given<br>
implementation is conformant to this aspect only.<br><br>
Additional comments (up to page 8 only) follow.<br>
</blockquote><br>
Are you suggesting that userPolicySet and trustAnchors fields of the
request should be optional to support?<br><br>
It is certainly possible to draft a useful profile of SCVP that does not
make use of all the mandatory to support features.&nbsp; (For example,
David Cooper has drafted a profile for the FPKI that does not require the
use of several of the mandatory to implement features, including these
two fields.)&nbsp; However, in many environments it may be preferable to
have the client specify these values rather than attempting to define a
separate validation policy for every possible combination that may be
needed for every relying party for every application.<br><br>
<br>
<blockquote type=cite class=cite cite>9. Page 5. Section 1. Second
paragraph. The text states:<br><br>
&nbsp;&nbsp; The first class of applications wants just two things:
confirmation<br>
&nbsp;&nbsp; that the public key belongs to the identity named in the
certificate<br>
&nbsp;&nbsp; and confirmation that the public key can be used for the
intended<br>
&nbsp;&nbsp; purpose.<br><br>
This is not the main goal. Rephrase as:<br><br>
&nbsp;&nbsp; The first class of applications wants just 
confirmation<br>
&nbsp;&nbsp; that the certificate is valid according a given validation
policy.<br>
</blockquote><br>
Your text implies that validating the certificate is the ultimate
goal.&nbsp; The current text indicates that validating the certificate is
a necessary step towards achieving the goal - to use the key in a
certificate for an intended purpose.&nbsp; Your text is simpler, but I
don't think it gets to the heart of the matter.<br><br>
<br>
<blockquote type=cite class=cite cite>10. Page 5. Section 1. Second
paragraph. The text states:<br><br>
&nbsp;&nbsp; The second class of applications can perform certification
path<br>
&nbsp;&nbsp; validation, but they lack a reliable or efficient method
of<br>
&nbsp;&nbsp; constructing a valid certification path.<br><br>
Rephrase as:<br><br>
&nbsp;&nbsp; The second class of applications can perform certification
path<br>
&nbsp;&nbsp; validation, but they lack a reliable or efficient method
of<br>
&nbsp;&nbsp; constructing a valid certification path and the
associated<br>
&nbsp;&nbsp; revocation status information.<br>
</blockquote><br>
Clients may wish to retrieve status information directly to ensure
freshness.&nbsp; It is simple to retrieve status information if the certs
contain CDPs or AIAs that point to OCSP servers.<br><br>
Given that this is introductory information, I believe the current text
is acceptable.<br><br>
<br>
<blockquote type=cite class=cite cite>11. Page 5. Section 1.1. Second
paragraph.<br><br>
&nbsp;&nbsp; The primary goals of SCVP are to make it easier to deploy
PKI-enabled<br>
&nbsp;&nbsp; applications and to allow central administration of PKI
policies<br>
&nbsp;&nbsp; within an organization.<br><br>
Rephrase as:<br><br>
&nbsp;&nbsp; The primary goals of SCVP are to make it easier to deploy
PKI-enabled<br>
&nbsp;&nbsp; applications and to allow a server to support one or more
validation<br>
&nbsp;&nbsp; policies against which certificates can be tested by
applications.<br>
</blockquote><br>
First, central management of policies is a goal noted in 3379, so I
wouldn't want to delete it.<br><br>
How about:<br><br>
&nbsp;&nbsp; The primary goals of SCVP are to make it easier to deploy
PKI-enabled<br>
&nbsp;&nbsp; applications by delegating path discovery and/or validation
processing to<br>
&nbsp;&nbsp; a server, and to allow central administration of validation
policies<br>
&nbsp;&nbsp; within an organization.<br><br>
<br>
<blockquote type=cite class=cite cite>12. Page 5. Section 1.1. Second
paragraph.<br><br>
&nbsp;&nbsp; SCVP can be used by clients that do much of<br>
&nbsp;&nbsp; the certificate processing themselves but simply want an
untrusted<br>
&nbsp;&nbsp; server to collect information for them.&nbsp; However, when
the client has<br>
&nbsp;&nbsp; complete trust in the SCVP server, SCVP can be used to
delegate the<br>
&nbsp;&nbsp; work of certification path construction and validation, and
SCVP can<br>
&nbsp;&nbsp; be used to ensure that policies are consistently enforced
throughout<br>
&nbsp;&nbsp; an organization.<br><br>
Rephrase as:<br><br>
&nbsp;&nbsp; SCVP, used for DPV, can be used by clients that have
complete trust<br>
&nbsp;&nbsp; in a trusted DPV server. In such a case, the protocol can be
used to<br>
&nbsp;&nbsp; delegate the work of certification path construction and
validation.<br><br>
&nbsp;&nbsp; SCVP, used for DPD, can be used by clients that do much
of<br>
&nbsp;&nbsp; the certificate processing themselves but simply want an
untrusted<br>
&nbsp;&nbsp; DPD server to collect information for them.<br><br>
</blockquote><br>
This is just a repeat of the introductory text in Section 1 above.&nbsp;
We have already introduced the concepts, and there is no reason to assume
that all servers fit into a single category.&nbsp; A DPV server might
handle DPD requests as well.<br><br>
Since the current text is accurate let's leave it as is. <br><br>
<blockquote type=cite class=cite cite>Denis<br><br>
<br>
</blockquote><br><br>
Tim<br><br>
</html>

Date: Tue, 01 Mar 2005 18:24:00 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: X.509 certificate collision, via MD5 collisions 
Sender: [email-masked]

I have not had an opportunity to review this document yet, but the findings 
need to be shared with the whole Internet security community.

>We announce a method for the construction of pairs of valid X.509 
>certificates in which the "to
>be signed" parts form a collision for the MD5 hash function. As a result 
>the issuer signatures
>in the certificates will be the same when the issuer uses MD5 as its hash 
>function.

http://eprint.iacr.org/2005/067

Date: Tue, 1 Mar 2005 19:39:36 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: One final week of Last Call for SCVP
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> 
> Denis,
> 
> We are both sensitive to the fact that Tim is a co-editor of the 
> document and co-chair.  I believe that is why Tim made the comment 
> you quoted in his message, i.e., noting that I will act to determine 
> WG consensus for SCVP.
> 

There are several comments from 
Denis Pinkas, Nathalie Jolly, and Wen-Cheng Wang
which I support (not all).

Date: Tue, 01 Mar 2005 14:09:43 +0100
From: Nathalie Jolly <[email-masked]>
To: [email-masked]
Subject: Re: Comments to SCVP ID 17
Sender: [email-masked]

Hello,

I have been reading SCVP draft 17 in detail and I send you my reading 
notes. I hope it will help you work on this topic. Since I began 
reading, draft 18 has appeared but I kept working on draft 17. Sorry if 
any of the following remarks have already been addressed.

Please keep in mind that I did not read the previous drafts and thus may
miss some of the design context. I am though quite familiar with
RFCs 2560 and 3280.

The following email deals first with my major remarks/questions on draft
17. I have also written down a non-exhaustive list of minor remarks, 
which you will find at the end of this email.

1- Some general considerations

The abstract and introduction refer to a specification for
implementating DPD/DPV ("certificate path construction and validation"
as stated in the abstract), whereas the rest of the draft specifies 
certificate validation as a whole (certificate content validation + 
revocation status + building and validation of the certification paths, 
depending of the chosen checks).

I would suggest :
- that you rewrite the abstract and introduction so that the purpose of 
the document becomes clearer (SCVP includes DPD/DPV but also deals with 
certificate content and revocation)
- that you distinguish in the text the "DPD" and the "DPV" part.

2- Validation policies, checks and validation algorithms

2.1- The concepts
If I understand correctly :
- checks = the validations that the client wants done,
- validation policy = the values that the client wants the server to use
while performing the checks,
- validation algorithm = the algorithm to be used by the server for
performing the checks.

The server uses the "validation algorithm" in order to perform the
"checks" using the values of the "validation policy".

My feeling is that we need to define a name for (checks + validation
policy + validation algorithm). They are thinly correlated with
one another. In my opinion, the term "validation policy" should refer as
the whole (checks + validation policy + validation algorithm), since the
word "policy" means a global strategy more than just a few numerical values.

Especially the algorithm should be a part of the "validation policy",
since each algorithm is an implementation of a set of checks. We could
have an algorithm per check and combine algorithms for each checks
combination.

Then, the chapters 5 and 6 (Server Policy request and response) would
send to the client the validation policies available, including checks
and algorithms for each response, and not two separate lists for
validation policies and validation algorithms.

I read that reviewers Wen-Cheng Wang and Denis Pinkas are of this
opinion, at least for merging "validation policy" and "validation
algorithm" (maybe not for the "checks"), and I totally agree with them.

2.2- Checks, some complementary remarks

- �1 : Sentence "A server may choose to perform additional checks,
although the server cannot indicate in the response that the additional
checks have been performed." ->

What happens if an error occurs for one of these additional checks ? The
server should be able to send back an error message, which is not
possible if he cannot indicate the additional check in the response. Or
the client will not understand why the server returns an error.

- The text does not address the possibility of keeping the calculated
paths (DPD) in a cache on the server between validation queries (DPV). 
Certification paths should be able to be stored by the SCVP server and 
not calculated for each request, since they do not depend on the 
incoming certificate (2 certificates delivered by the same CA and been 
validated under the same validation policy have the same certification 
path at a given time). Thus, we need to state that the path building is 
optional, if it has been done before and if the CA / validation policy 
information have not been modified.

Therefore, we could have checks such as "id-stc-check-pkc-path" without
the "build" part.

More generally, the text should separate clearly what is the scope of 
DPD and what is the scope of DPV.

2.3- Validation policies

- Concerning the default values that can be overridden : a
simplification would be that the server does not return an error but
behaves as it should :

We could add an attribute : are_default_values_overridable

then the server behavior could be :
If (is_default_values_overridable) then :
- conflicts must not lead to server error
- and SCVP server takes new values
If !(is_default_values_overridable) then :
- conflicts must not lead to server error
- and SCVP server takes default values

- Concerning validation policy parameters :

The parameter list should be extensible. For example, we could make use
of a parameter stating if the certificate to validate must be a CA
certificate, a Enduser certificate or any type of certificate, ...

2.4- Client versus server authority

The text addresses the case where the client does not trust the server
and has to receive all the information used by the server, even if the
server validates the certification path, in order to be able to decide
not to trust the answer and query again the same or another server.

In organisations that want to centralize their PKI policies, the
projects that need a SCVP server cannot have the choice to contest the
authoritative answer of the SCVP server. Checks and validation policies
are contractually defined between the client and the server and the
client has to accept the answer received. In this context, we need a
protocol that gives the server the right to refuse subsequent requests
(which means : "SCVP servers MAY support serverContextInfo" - instead of
"SHOULD")

3- serverContextInfo

I can't really understand the choice to implement this
"serverContextInfo" instead of letting the server send all the paths at
once. It means we have to keep context on the server for each query
(with all the subsequent questions : how long do we keep it ? do we need
to backup it for replay/verification purpose ?)

The text states that this value is used by the client if if finds the
response "unacceptable". What does "unacceptable mean" ? If it is
possible to define these "unacceptability criteria", they could be
implemented in the validation policy on the server, so that the server
gives the correct response at first query.

4- basic validation algorithm errors (3.2.4.2.2)

IIRC, the validation algorithm defined in section 6 of [PKIX-1] does not
contain any keyusage / revocation check. Thus, the
id-bvae-invalid-key-usage and id-bvae-revoked values are not used.

5- ValidationTime

I am afraid I missed the "clock skew" concept. IIUC, the idea of 
introducing clock skew aims to solve the delay between the moment where 
the user revokes his certificats and the moment where the system is 
aware that the certificate is indeed revoked.

How does the SCVP server behave with the "clock stew" concept ?

- If the server builds a response concerning the state the
certificate was in 10 mn before the query, it increases the risk that a 
certificate has been revoked in the meantime and that the SVCP server is 
not yet aware of the revocation.

- If the server builds a response concerning the state the
certificate will be in 10 mn after the query, the server has to wait 10 
mn before checking the certificate and sending the response to the client.

It seems to me that the solution is not clear enough in the text.

6- Some minor remarks

*** $3.2.2 : Sentence "For each check specified in the request, the SCVP 
server MUST perform all of the requested checks, or return an error".

please rewrite : "For each check specified in the request, the SCVP 
server MUST perform the requested check, or return an error".

*** id-swb-pkc-best-cert-path : we lack a definition of what is the 
"best" certification path and how the choice is made by the SCVP server.

*** �3 Validation request
Please state that a SCVP server MUST process a protected request.

*** �3.2.7 validationTime
typo : valididationTime -> validationTime

I hope this contribution will help.

Sincerely yours,
Nathalie Jolly
Project manager for the development of a certificate validation service
for the french government.

-- 
Nathalie Jolly - inet6
-------------------------------------------------------------------
   o            Siege social: 51, rue de Verdun - 92 158 Suresnes
  /     _ __ _  Bureaux: 33, rue Benoit Malon - 92150 Suresnes
/ /\  /_ / /_  France
\/  \/_ / /_/  Tel. +33 (0) 1 41 44 85 45
-------------- Fax  +33 (0) 1 46 97 20 10
i n e t s y s  http://www.inet6.fr