Subject: RE: Web-PKI Keygen/Certreq Questions

From: Pierre Heuze <[email-masked]>
Date: Fri, 31 Oct 2003 23:29:29 -0000

Anders Rundgren wrote:
>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>for performing key generation or performing certificate requests.
Indeed there isn't a de-facto reference for this, by now you must realize
every PKI/Browser vendors have developed their ownn solution as mentionned
already, but don't forget the many token/smart card providers who also have
come-up with additional solutions. So it's the jungle out there, as any
request in a search engine for "browser certificate request" or similar will
show (cf Stephen's comment do some more homework.)

Stephen Kent wrote:
> both browsers have had facilities for generating an RSA key pair for 
> a user, and sending a cert request for years.
Indeed, at least 1998 from my own experience, but surely someone will claim
an earlier date. In practice, it is almost always based on free/liberal use
of PKCS#10; which has raised many interop issues as you all know, to mention
few (signature and extension format).

Jean-Marc Desperrier wrote:
>So, from the point of view of what should be put on a web page to get a 
>browser to generate a certificate request, there is no standard.
>This can be considered not to be a valable item of concern for pkix
thought.
Indeed this topic is somewhat out of the scope of PKIX, but few things to
consider:
- Requesting a certificate is one of the most basic operation to be
completed in the PKI world and browser based application have gained a large
acceptance. So it is a valid concern.
- Requesting a certificate is a somewhat complex operation, and the
browser-based solution too often overlooked basic consideration for the sake
of simplicity, the main drawbacks are:
	- No authentication, Proof of Possession (having the key pair) is
often taken as valid  
        authentication mechanism (sic).
      - No standard way to mandate what certificate profile should be used
to fulfil the request
      - No control of the certificate life-cycle, each request are handled
separately which 
        doesn't cater well when certificate need to be renewed, or
re-activated 
        after suspension.
The above points are in part covered by various PKIX message format, but to
be honest they haven't gained acceptance (yet?) for browser based operations
and if used they are highly not interoperable (i.e. to say the least no
improvement on the interop side compare to using PKCS#10). 

So is it the case that one should refine the standard to restrict the use of
existing messages to cover the above scenario as to achieve greater
interoperability and hence acceptance? To me this seems to be a genuine item
for the PKIX group.

Pierre Heuzé
http://www.cardbase.com

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: 31 October 2003 19:35
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Web-PKI Keygen/Certreq Questions

At 19:15 +0100 10/31/03, Jean-Marc Desperrier wrote:
>Stephen Kent wrote:
>
>>At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>>
>>>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>>>for performing key generation or performing certificate requests.
>>
>>yes, you are wrong.
>>
>>both browsers have had facilities for generating an RSA key pair 
>>for a user, and sending a cert request for years.
>
>Facilities is one thing, interoperability is another.

I have not worked this problem recently, but in my  experience 
developing three different CA products a few years ago, all were able 
to accept enrollment requests from both browsers, and all major 
providers of CA software did so as well. it was a necessary 
prerequisite for selling CA software.

we now have 2 PKIX standards for enrollment protocols: CMP and CMC. 
if the browser vendors choose to support these, then we have 
interoperable solutions as well, but vendors must choose to make use 
of them.

Steve

CardBASE Technologies® 
Address: BIM House, Crofton Road, Dun Laoghaire, Co Dublin, Ireland 
PH: +353-1-2843233  FAX: +353-1-2843220  WEB: http://www.cardbase.com 
 *********************************************************************** 
This e-mail and any attachment, contains information which is private 
and confidential and is intended for the addressee only. If you are not 
an addressee, you are not authorised to read, copy or use the e-mail 
or any attachments. If you have received this e-mail in error, please 
notify the sender by return e-mail and then destroy it. 
This message has been swept for viruses by anti-virus software. 
*********************************************************************** 

From: Pierre Heuze <[email-masked]>
To: Stephen Kent <[email-masked]>, Jean-Marc Desperrier <[email-masked]>
Cc: [email-masked]
Subject: RE: Web-PKI Keygen/Certreq Questions
Date: Fri, 31 Oct 2003 23:29:29 -0000
Sender: [email-masked]

Anders Rundgren wrote:
>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>for performing key generation or performing certificate requests.
Indeed there isn't a de-facto reference for this, by now you must realize
every PKI/Browser vendors have developed their ownn solution as mentionned
already, but don't forget the many token/smart card providers who also have
come-up with additional solutions. So it's the jungle out there, as any
request in a search engine for "browser certificate request" or similar will
show (cf Stephen's comment do some more homework.)

Stephen Kent wrote:
> both browsers have had facilities for generating an RSA key pair for 
> a user, and sending a cert request for years.
Indeed, at least 1998 from my own experience, but surely someone will claim
an earlier date. In practice, it is almost always based on free/liberal use
of PKCS#10; which has raised many interop issues as you all know, to mention
few (signature and extension format).

Jean-Marc Desperrier wrote:
>So, from the point of view of what should be put on a web page to get a 
>browser to generate a certificate request, there is no standard.
>This can be considered not to be a valable item of concern for pkix
thought.
Indeed this topic is somewhat out of the scope of PKIX, but few things to
consider:
- Requesting a certificate is one of the most basic operation to be
completed in the PKI world and browser based application have gained a large
acceptance. So it is a valid concern.
- Requesting a certificate is a somewhat complex operation, and the
browser-based solution too often overlooked basic consideration for the sake
of simplicity, the main drawbacks are:
	- No authentication, Proof of Possession (having the key pair) is
often taken as valid  
        authentication mechanism (sic).
      - No standard way to mandate what certificate profile should be used
to fulfil the request
      - No control of the certificate life-cycle, each request are handled
separately which 
        doesn't cater well when certificate need to be renewed, or
re-activated 
        after suspension.
The above points are in part covered by various PKIX message format, but to
be honest they haven't gained acceptance (yet?) for browser based operations
and if used they are highly not interoperable (i.e. to say the least no
improvement on the interop side compare to using PKCS#10). 

So is it the case that one should refine the standard to restrict the use of
existing messages to cover the above scenario as to achieve greater
interoperability and hence acceptance? To me this seems to be a genuine item
for the PKIX group.

Pierre Heuzé
http://www.cardbase.com

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: 31 October 2003 19:35
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Web-PKI Keygen/Certreq Questions

At 19:15 +0100 10/31/03, Jean-Marc Desperrier wrote:
>Stephen Kent wrote:
>
>>At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>>
>>>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>>>for performing key generation or performing certificate requests.
>>
>>yes, you are wrong.
>>
>>both browsers have had facilities for generating an RSA key pair 
>>for a user, and sending a cert request for years.
>
>Facilities is one thing, interoperability is another.

I have not worked this problem recently, but in my  experience 
developing three different CA products a few years ago, all were able 
to accept enrollment requests from both browsers, and all major 
providers of CA software did so as well. it was a necessary 
prerequisite for selling CA software.

we now have 2 PKIX standards for enrollment protocols: CMP and CMC. 
if the browser vendors choose to support these, then we have 
interoperable solutions as well, but vendors must choose to make use 
of them.

Steve

CardBASE Technologies® 
Address: BIM House, Crofton Road, Dun Laoghaire, Co Dublin, Ireland 
PH: +353-1-2843233  FAX: +353-1-2843220  WEB: http://www.cardbase.com 
 *********************************************************************** 
This e-mail and any attachment, contains information which is private 
and confidential and is intended for the addressee only. If you are not 
an addressee, you are not authorised to read, copy or use the e-mail 
or any attachments. If you have received this e-mail in error, please 
notify the sender by return e-mail and then destroy it. 
This message has been swept for viruses by anti-virus software. 
*********************************************************************** 

From: "Anders Rundgren" <[email-masked]>
To: "Jean-Marc Desperrier" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Web-PKI Keygen/Certreq Questions
Date: Fri, 31 Oct 2003 22:51:40 +0100
Sender: [email-masked]

>>Facilities is one thing, interoperability is another.

Thanx Jean Marc!

>I have not worked this problem recently, but in my  experience 
>developing three different CA products a few years ago, all were able 
>to accept enrollment requests from both browsers, and all major 
>providers of CA software did so as well. it was a necessary 
>prerequisite for selling CA software.

Sure, we all know that.  But with mobile internet we get a
set of new browsers and you must recognize them as well.

Also, I do no think that the key-gen facilities are indentical and
maybe, maybe these functions aren't even that fit for the purpose.
Otherwise I don't see why most new implementation of serious
Web-PKI bypass the whole thing.  One limitation I'm almost sure
of: You cannot generate multiple keys in one step.
Other likely limitations include CA-control of password
policy, and getting key container signatures (figuring out
its "quality" and tying it to a "device")

>we now have 2 PKIX standards for enrollment protocols: CMP and CMC. 
>if the browser vendors choose to support these, then we have 
>interoperable solutions as well, but vendors must choose to make use 
>of them.

But none of these define a browser interface beyond MIME type
which render these protocols incomplete (in this context nota bene).

As far as I can see Web-PKI (pretty much all aspects of it), is in
a really lousy shape and desperately needs a blood transfusion.
Particularly as it will have a couple of billion users within
five years or so.

Anders

Date: Fri, 31 Oct 2003 14:34:38 -0500
To: Jean-Marc Desperrier <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Web-PKI Keygen/Certreq Questions
Cc: [email-masked]
Sender: [email-masked]

At 19:15 +0100 10/31/03, Jean-Marc Desperrier wrote:
>Stephen Kent wrote:
>
>>At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>>
>>>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>>>for performing key generation or performing certificate requests.
>>
>>yes, you are wrong.
>>
>>both browsers have had facilities for generating an RSA key pair 
>>for a user, and sending a cert request for years.
>
>Facilities is one thing, interoperability is another.

I have not worked this problem recently, but in my  experience 
developing three different CA products a few years ago, all were able 
to accept enrollment requests from both browsers, and all major 
providers of CA software did so as well. it was a necessary 
prerequisite for selling CA software.

we now have 2 PKIX standards for enrollment protocols: CMP and CMC. 
if the browser vendors choose to support these, then we have 
interoperable solutions as well, but vendors must choose to make use 
of them.

Steve

Date: Fri, 31 Oct 2003 19:15:27 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Web-PKI Keygen/Certreq Questions
Sender: [email-masked]

Stephen Kent wrote:

> At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>
>> I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>> for performing key generation or performing certificate requests.
>
> yes, you are wrong.
>
> both browsers have had facilities for generating an RSA key pair for a 
> user, and sending a cert request for years.

Facilities is one thing, interoperability is another.

IE does fully rely on the page interacting with the proprietary xenroll 
to generate request.
Some people that were unhappy with some aspect of the behaviours of 
xenroll have even developped their own solution.

Netscape was using a propretary, little documented HTML tag to generate 
a request in the 4.x browser, KEYGEN.

Newer Mozilla and Netscape continue to support this, but can also use a 
significantly less ugly javascript-based solution with a call to the 
*generateCRMFRequest*() function .

So, from the point of view of what should be put on a web page to get a 
browser to generate a certificate request, there is no standard.
This can be considered not to be a valable item of concern for pkix thought.

Even the format of the request, which is much more of concern to pkix, 
is not fully standardised, because if IE was generating pkcs#10, the 
KEYGEN would create a netscape specific SPKAC format.
As can be guessed from the name, newer Netscape can generate a CRMF 
format request.
But I don't know if the idea of sending it raw without any CMC/CMP 
envelop makes it a very compatible solution.
Newer xenroll can generate CMC format request.
But it's not as standard-based as it may seem, because xenroll will 
always put a pkcs#10 inside, and never ever a crmf.
This even if the request include functionnalities that require a CRMF 
based CMC request, like private key exportation for key recovery.
There's probably few people outside of Microsoft who understand how the 
key is exported in this case, the solution used does not conform to any 
standard and has some platform specific elements.

Date: Fri, 31 Oct 2003 10:59:54 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Web-PKI Keygen/Certreq Questions
Cc: <[email-masked]>
Sender: [email-masked]

At 16:21 +0100 10/31/03, Anders Rundgren wrote:
>Dear List,
>
>After verifying that Web-signing is indeed both a much wanted
>thing, as well as being in a miserable state standards-wise, I took
>the liberty to check out another piece in the Web-PKI puzzle:
>
>I cannot find any "compilation" of browser (on-line)-adapted mechanisms
>for performing key generation or performing certificate requests.
>This may be due to a limited effort on my part, but I suspect this
>is just another "black hole" with respect to interoperability.
>Please tell me I'm wrong!

yes, you are wrong.

both browsers have had facilities for generating an RSA key pair for 
a user, and sending a cert request for years.

do some more homework.

Steve

Date: Fri, 31 Oct 2003 10:46:22 -0500
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Draft PKIX Agenda for 58th IETF
Sender: [email-masked]

Folks,

I have appended a draft agenda.  Okay, so I didn't meet my goal of 
Monday....sigh.

As Peter Sylvester pointed out to me, *that's* why the U.S. Men can't win 
the World Cup.  We keep missing the goal.  That means I come by it 
honestly, right?

Thanks!

Tim

[P.S.  If I was true to form, I will have missed at least one agenda 
request in my mail box.  If that is you, please let me know ASAP so I can 
correct it.]

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

PKIX WG (pkix-wg)

MONDAY, November 10, 2003 1530-1730

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

CHAIR Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>

AGENDA

1. WG Status and Direction

1.1 Document Status Review [Tim Polk (NIST)]

       The working group has a number of Internet-Drafts.  Many
       documents are with the ADs or in various stages of WG Last Call.
       Several others are ready for Last Call. (10 min.)

1.2 Proposed WG Milestones [Tim Polk (NIST)]

       The working group milestones are out of date.  New milestones are
       needed; these milestones need to satisfy IESG direction for an orderly
       closeout of WG activities. (10 min.)

2. PKIX WG Specifications

    2.1  Subject Identification Method  [TBD]

       http//www.ietf.org/internet-drafts/draft-ietf-pkix-sim-01.txt

       The current SIM draft introduces a number of new parameters.
       While these parameters add additional complexity, they were
       required to satisfy the draft's security requirements.  The presentation
       will focus on the security requirements and proposed solution.
       Open issues will also be identified.  (10 min.)

    2.2 LDAP Schemas, String Values, and more
                                - David Chadwick (Univ of Salford)

       The WG has a suite of LDAP-PKIX drafts forming a comprehensive solution
       for LDAP based PKI information distribution.  New drafts will be 
published
       soon after this meeting; the presenter will discuss changes that will
       appear in the new drafts.  (15 min.)

    2.3 Qualified Certificates             Stefan Santesson

       http//www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-02.txt

       Work on the QC document has continued in both PKIX and ETSI.
       At least one more draft is envisioned; this presentation will decsribe
       planned updates and propose a path for completion of the QC document.
       (10 min.)

    2.4 Certification Path Building        Peter Hesse (Orion Security)

       http//www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-01.txt

       This document was written to provide guidance and
       recommendations to developers building X.509 public-key certification
       paths within their applications.  The next draft is aimed for WG Last
       Call; the presenter will discuss changes since -00 and additional
       changes projected for the forthcoming -02 draft. (10 min.)

    2.5  Certstore HTTP                    Peter Gutmann

       http//www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-05.txt 

       This draft proposes new procedures for certificate retrieval from
       an HTTP based repository.  Progression of this document would
       result in conflicting PKI protocols for HTTP-based repositories,
       and has not been able to progress.  (5 min.)

    2.6  OCSP                               Mike Myers (FastQ)

       http//www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-05.txt 

       A number of issues regarding OCSP have resurfaced on the mailing
       list.  The presenter will summarize the issues from the mailing
       list and present a way forward.  (5 min.)

3. Liaison/Related Projects

    The following specifications will update the WG on related activities.

    3.1 OASIS PKI survey                        Steve Hanna (Sun)

       The OASIS Public Key Infrastructure Technical Committee
       conducted a web-based survey to identify the key barriers
       to PKI deployment and usage.  The TC is currently developing an Action
       to address these barriers.  The presentation will address the survey
       results and preview the action plan. (15 min.)

    3.2 Path Validation Protection Profiles     Tim Polk (NIST)

       NIST is currently performing the interoperability testing for RFC 3280.
       One aspect of that effort is the RFC 3280 path validation test suite
       developed jointly by NIST, DigitalNet, and NSA.  To promote independnet
       testing based on the test suite, NIST has submitted protection profiles
       for path validation modules for NIAP validation. (10 min.)

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Web-PKI Keygen/Certreq Questions
Date: Fri, 31 Oct 2003 16:21:23 +0100
Sender: [email-masked]

Dear List,

After verifying that Web-signing is indeed both a much wanted
thing, as well as being in a miserable state standards-wise, I took
the liberty to check out another piece in the Web-PKI puzzle:

I cannot find any "compilation" of browser (on-line)-adapted mechanisms
for performing key generation or performing certificate requests.
This may be due to a limited effort on my part, but I suspect this
is just another "black hole" with respect to interoperability. 
Please tell me I'm wrong!

Looking at Microsoft's CertSrv for W2K, I found that IE and
Navigator are supplied with very different code.  IE seems to
only rely on MSFT's proprietary "Xenroll" stuff, while Navigator
uses a Netscape proprietary HTML tag called "KeyGen".

Any comments or information on this subject?

Sincerely
Anders Rundgren
Consultant, PKI & e-business

PS This is indeed off-topic for PKIX but not for the "PKI community"
     which to some extent is represented in PKIX  DS

Date: Thu, 30 Oct 2003 18:36:40 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Request change in son-of-rfc2633
Sender: [email-masked]

At 8:02 PM -0500 10/30/03, jim wrote:
>After the KEYJACKING paper that was presented at the last PKI 
>Development Conference, I am not clear on the push for using SMIME 
>since we know that any transactions using SSL or VPN technologies 
>subject the key to being compromised.

The paper talks about scenarios that compromise the entire PC, not 
just S/MIME. So you are saying "if the user can use client-side 
certs, you cannot trust anything on the PC ever again". That may be 
true, but it is irrelevant to the discussion of S/MIME and probably 
to PKIX as well.

PCs are vulnerable. This doesn't mean we stop all development of 
things that run on PCs.

(FWIW, the paper can be found at 
<http://www.cs.dartmouth.edu/~sws/papers/keyjack.pdf>.)

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 30 Oct 2003 20:02:32 -0500
From: jim <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: Request change in son-of-rfc2633
Sender: [email-masked]

--------------040505080708010004040903
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

After the KEYJACKING paper that was presented at the last PKI 
Development Conference, I am not clear on the push for using SMIME since 
we know that any transactions using SSL or VPN technologies subject the 
key to being compromised.  Is there some new technology that I am not 
familiar with and has that been reviewed by the team from Dartmouth that 
presented the paper to see if it was truly better?

Jim Heimberg, ABC, Ph.D.

Santosh Chokhani wrote:

>Tom:
>
>If the new Sub CA is rogue, name chaining will not help.  The CA who now
>uses the compromise key can always issue certificates to those RP and assert
>its own name.
>
>If the new sub CA is not rogue and someone else compromised the original sub
>CA key, that "someone else" can use the compromised key under the new CA
>name to create bogus RPs.
>
>If everything is benign, the original CA was revoked and not compromised,
>some one could provide a certification path: root .....--> new CA --> RP
>under old CA.  Without name chaining, this path could be validated and thus,
>if the RP was compromised, that compromise can be exploited.  But, this is
>only if the two CAs benignly use the same key. 
>
>-----Original Message-----
>From: Tom Biskupic [mailto:[email-masked]] 
>Sent: Thursday, October 30, 2003 1:29 AM
>To: 'Santosh Chokhani'; [email-masked]
>Subject: RE: Request change in son-of-rfc2633
>
>
>Hello,
>
>Umm What about if you managed to have a Sub-CA certified using the
>compromised key of another Sub CA?
>
>The other sub CA was revoked (for key compromise) and therefore all the
>certificates it issued are dead but if RP applications ignore the
>name-chaining, wouldn't this effectively re-activate those certificates? RPs
>checking one of those dead certs (and ignoring name chaining) could use the
>newly certified Sub CA to build a (well bogus) path and would accept that
>path.
>
>Even POP won't save you as the entity applying to have the compromised CA
>key re-certified may have the private key (as it was compromised).
>
>Some CAs will check that the same key is not issued to two entities (and
>thus would refuse to re-certify the Sub CA with a different name) however do
>you want to rely on it?
>
>Ok this is a bit theoretical... A Sub-CA being revoked for instance.
>
>Tom
>
>  
>
>>-----Original Message-----
>>From: Santosh Chokhani [mailto:[email-masked]]
>>Sent: Thursday, 30 October 2003 07:51
>>To: [email-masked]; [email-masked]
>>Subject: RE: Request change in son-of-rfc2633
>>
>>
>>Steve Hanna:
>>
>>I agree with you that both 3280 and X.509 require name chaining. 
>>However, the security implications and security importance of name 
>>chaining is overstated.
>>
>>For example, if signatures chain properly for the certificate and CRL 
>>and the relying party has appropriate means (e.g., e-mail
>>address) to identify
>>the subscriber, name chaining offers little in terms of security.
>>
>>My statement should be read purely in security (and NOT
>>interoperability)
>>context.
>>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]]
>>On Behalf Of Steve Hanna
>>Sent: Wednesday, October 29, 2003 9:58 AM
>>To: Peter Gutmann
>>Cc: [email-masked]; [email-masked]; [email-masked]
>>Subject: Re: Request change in son-of-rfc2633
>>
>>
>>Anyone who "reads the PKIX tea leaves" and thinks that
>>it's fine to skip name chaining checks in path validation needs to
>>have their eyes checked. RFC 3280 says in many places that name 
>>chaining MUST be checked.
>>
>>In section 6.1:
>>
>> To meet this goal, the path validation process verifies, among other
>>things, that a prospective certification path (a sequence of n
>> certificates) satisfies the following conditions:
>>
>>    (a)  for all x in {1, ..., n-1}, the subject of certificate x is
>>    the issuer of certificate x+1;
>>
>>In section 6.1.3:
>>
>> (a)  Verify the basic certificate information.  The certificate  MUST
>>satisfy each of the following:
>>
>> [...]
>>
>>    (4)  The certificate issuer name is the working_issuer_name.
>>
>>In section 4.1.2.6:
>>
>>   If the subject is a CA (e.g., the basic constraints extension, as
>>   discussed in 4.2.1.10, is present and the value of cA is TRUE), 
>>then
>>   the subject field MUST be populated with a non-empty distinguished
>>   name matching the contents of the issuer field (section 4.1.2.4) in
>>   all certificates issued by the subject CA.
>>
>>RFC 2459 and X.509 both agree with this.
>>
>>Whatever PKI topology you use, there's no need to break
>>name chaining. I'm sure that some customers have created
>>PKIs where name chaining doesn't hold, but that's an error
>>on the customer's part. You can't just turn off critical security 
>>checks to keep them happy. What's next? Don't bother checking the 
>>signature on certificates. That takes too much time!
>>
>>If somebody has implemented path validation without name chaining 
>>checks, then they haven't implemented it according to IETF or X.509 
>>standards. In fact, they may have opened themselves and their 
>>customers up to security
>>holes and perhaps even legal liability. CAs have every right to expect
>>that certificates will be validated according to standards. Users also
>>have a reasonable expectation of this. If someone 
>>deliberately violates
>>the standards in a way that opens up security holes, that sounds like
>>gross negligence to me.
>>
>>This reminds me of Microsoft's decision to not check the Basic
>>Constraints extension, treating every certificate as a CA certificate. 
>>This decision, presumably made in to please a customer, resulted in a 
>>HUGE security hole.
>>
>>I hope that Microsoft (and anyone else who has skipped required parts
>>of the path validation algorithm for the sake of convenience) will see 
>>that security cannot be second to user convenience. If there's a 
>>serious problem with the specs, then let's fix them. But don't just 
>>bypass things because you find it convenient.
>>
>>Forgive me my rant. I'm just outraged that somebody would play fast
>>and loose with security this way.
>>
>>Thanks,
>>
>>Steve
>>
>>Peter Gutmann wrote:
>>    
>>
>>>[Cross-posted back to S/MIME, where the thread started]
>>>
>>>Eric Norman <[email-masked]> writes:
>>>
>>>      
>>>
>>>>Is there a claim (#1 above) that you can have the DN in the subject
>>>>of a parent's (signer's) certificate be different from (as in 
>>>>different bunch of
>>>>bytes) the DN in the issuer of one of its offspring and
>>>>        
>>>>
>>yet the chain
>>is
>>    
>>
>>>>still valid because the xKIDs match?
>>>>        
>>>>
>>>Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI
>>>that violates the original X.509 design, i.e. with re-parenting, 
>>>arbitrary cross- certification, etc etc where issuers no
>>>      
>>>
>>longer match
>>    
>>
>>>subjects).  For example MS apparently implemented chaining
>>>      
>>>
>>by sKID in
>>    
>>
>>>Windows because of user demand for this when the users
>>>      
>>>
>>broke chaining
>>    
>>
>>>by issuer name through spaghetti PKI design practices, and various
>>>other implementations no doubt do similar things, depending on how 
>>>they've read the PKIX tea leaves.
>>>
>>>Peter.
>>>      
>>>
>
>
>
>
>  
>

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

<!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>
After the KEYJACKING paper that was presented at the last PKI Development
Conference, I am not clear on the push for using SMIME since we know that
any transactions using SSL or VPN technologies subject the key to being compromised.
&nbsp;Is there some new technology that I am not familiar with and has that been
reviewed by the team from Dartmouth that presented the paper to see if it
was truly better?<br>
<br>
Jim Heimberg, ABC, Ph.D.<br>
<br>
<br>
Santosh Chokhani wrote:<br>
<blockquote type="cite"
 cite="[email-masked]">
  <pre wrap="">Tom:

If the new Sub CA is rogue, name chaining will not help.  The CA who now
uses the compromise key can always issue certificates to those RP and assert
its own name.

If the new sub CA is not rogue and someone else compromised the original sub
CA key, that "someone else" can use the compromised key under the new CA
name to create bogus RPs.

If everything is benign, the original CA was revoked and not compromised,
some one could provide a certification path: root .....--&gt; new CA --&gt; RP
under old CA.  Without name chaining, this path could be validated and thus,
if the RP was compromised, that compromise can be exploited.  But, this is
only if the two CAs benignly use the same key. 

-----Original Message-----
From: Tom Biskupic [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] 
Sent: Thursday, October 30, 2003 1:29 AM
To: 'Santosh Chokhani'; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Subject: RE: Request change in son-of-rfc2633

Hello,

Umm What about if you managed to have a Sub-CA certified using the
compromised key of another Sub CA?

The other sub CA was revoked (for key compromise) and therefore all the
certificates it issued are dead but if RP applications ignore the
name-chaining, wouldn't this effectively re-activate those certificates? RPs
checking one of those dead certs (and ignoring name chaining) could use the
newly certified Sub CA to build a (well bogus) path and would accept that
path.

Even POP won't save you as the entity applying to have the compromised CA
key re-certified may have the private key (as it was compromised).

Some CAs will check that the same key is not issued to two entities (and
thus would refuse to re-certify the Sub CA with a different name) however do
you want to rely on it?

Ok this is a bit theoretical... A Sub-CA being revoked for instance.

Tom

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: Santosh Chokhani [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]
Sent: Thursday, 30 October 2003 07:51
To: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Subject: RE: Request change in son-of-rfc2633

Steve Hanna:

I agree with you that both 3280 and X.509 require name chaining. 
However, the security implications and security importance of name 
chaining is overstated.

For example, if signatures chain properly for the certificate and CRL 
and the relying party has appropriate means (e.g., e-mail
address) to identify
the subscriber, name chaining offers little in terms of security.

My statement should be read purely in security (and NOT
interoperability)
context.

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> 
[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>]
On Behalf Of Steve Hanna
Sent: Wednesday, October 29, 2003 9:58 AM
To: Peter Gutmann
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>; <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Subject: Re: Request change in son-of-rfc2633

Anyone who "reads the PKIX tea leaves" and thinks that
it's fine to skip name chaining checks in path validation needs to
have their eyes checked. RFC 3280 says in many places that name 
chaining MUST be checked.

In section 6.1:

 To meet this goal, the path validation process verifies, among other
things, that a prospective certification path (a sequence of n
 certificates) satisfies the following conditions:

    (a)  for all x in {1, ..., n-1}, the subject of certificate x is
    the issuer of certificate x+1;

In section 6.1.3:

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

 [...]

    (4)  The certificate issuer name is the working_issuer_name.

In section 4.1.2.6:

   If the subject is a CA (e.g., the basic constraints extension, as
   discussed in 4.2.1.10, is present and the value of cA is TRUE), 
then
   the subject field MUST be populated with a non-empty distinguished
   name matching the contents of the issuer field (section 4.1.2.4) in
   all certificates issued by the subject CA.

RFC 2459 and X.509 both agree with this.

Whatever PKI topology you use, there's no need to break
name chaining. I'm sure that some customers have created
PKIs where name chaining doesn't hold, but that's an error
on the customer's part. You can't just turn off critical security 
checks to keep them happy. What's next? Don't bother checking the 
signature on certificates. That takes too much time!

If somebody has implemented path validation without name chaining 
checks, then they haven't implemented it according to IETF or X.509 
standards. In fact, they may have opened themselves and their 
customers up to security
holes and perhaps even legal liability. CAs have every right to expect
that certificates will be validated according to standards. Users also
have a reasonable expectation of this. If someone 
deliberately violates
the standards in a way that opens up security holes, that sounds like
gross negligence to me.

This reminds me of Microsoft's decision to not check the Basic
Constraints extension, treating every certificate as a CA certificate. 
This decision, presumably made in to please a customer, resulted in a 
HUGE security hole.

I hope that Microsoft (and anyone else who has skipped required parts
of the path validation algorithm for the sake of convenience) will see 
that security cannot be second to user convenience. If there's a 
serious problem with the specs, then let's fix them. But don't just 
bypass things because you find it convenient.

Forgive me my rant. I'm just outraged that somebody would play fast
and loose with security this way.

Thanks,

Steve

Peter Gutmann wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">[Cross-posted back to S/MIME, where the thread started]

Eric Norman <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> writes:

      </pre>
      <blockquote type="cite">
        <pre wrap="">Is there a claim (#1 above) that you can have the DN in the subject
of a parent's (signer's) certificate be different from (as in 
different bunch of
bytes) the DN in the issuer of one of its offspring and
        </pre>
      </blockquote>
    </blockquote>
    <pre wrap="">yet the chain
is
    </pre>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">still valid because the xKIDs match?
        </pre>
      </blockquote>
      <pre wrap="">Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI
that violates the original X.509 design, i.e. with re-parenting, 
arbitrary cross- certification, etc etc where issuers no
      </pre>
    </blockquote>
    <pre wrap="">longer match
    </pre>
    <blockquote type="cite">
      <pre wrap="">subjects).  For example MS apparently implemented chaining
      </pre>
    </blockquote>
    <pre wrap="">by sKID in
    </pre>
    <blockquote type="cite">
      <pre wrap="">Windows because of user demand for this when the users
      </pre>
    </blockquote>
    <pre wrap="">broke chaining
    </pre>
    <blockquote type="cite">
      <pre wrap="">by issuer name through spaghetti PKI design practices, and various
other implementations no doubt do similar things, depending on how 
they've read the PKIX tea leaves.

Peter.
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
<br>
</body>
</html>

--------------040505080708010004040903--

To: "Michael Myers" <[email-masked]>
Cc: "David Engberg" <[email-masked]>, [email-masked]
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
From: Tom Gindin <[email-masked]>
Date: Thu, 30 Oct 2003 19:04:12 -0500
Sender: [email-masked]

        I should have been more precise in my suggestion.  The unilateral 
server-specified practice I can think of that would most effectively ban 
relays is for an extension called nonceSupported to be defined, whose 
syntax is a single Boolean.  A responder supporting this extension should 
include it, with the appropriate value, in every response other than those 
which contain nonces.  This extension is of limited value in responses 
which do contain nonces, although you could put it in them.  With such an 
extension, any replay of a response from a responder with nonce support 
would be detectable by the client.  If the client doesn't use nonces, or 
the responder doesn't support them, I don't see what you can do to detect 
replays.
        It would be possible to make the value of such an extension a 
3-valued enumeration: unsupported, deprecated (meaning it's expensive but 
we'll do it if you insist), and supported.  That variant would probably be 
called "nonceSupport", and it might be desirable to include that in 
responses which include nonces as well as in those which don't.  However, 
we'd need yet another mechanism to demand a response including a nonce in 
order to support the deprecated value.
        I am not suggesting that anyone standardize both of these 
variants, which would be egregious bloat.  I won't be at Minneapolis, so 
I'm getting my suggestions in early.

                Tom Gindin

        IMHO, a client should take the following action where the 
requestor includes a nonce:
a)      Nonce present, accept if response.nonce == request.nonce
b)      NonceSupported == false (with no nonce), accept (also NonceSupport 
== unsupported)
c)      NonceSupported == true but no nonce, reject             (also 
NonceSupport == supported)
d)      NonceUnsupported present (with no nonce), accept
e)      Neither nonce nor extension present, DEBATABLE (see this thread 
for the debate)
f)      NonceSupport == deprecated (with no nonce), accept or rerequest 
(BUT there's no good rerequest technique)

"Michael Myers" <[email-masked]>
10/22/2003 12:49 PM

        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     "David Engberg" <[email-masked]>, <[email-masked]>
        Subject:        RE: DISCUSSION: Nonce-specific error code for OCSP

Tom,

Your proposal certainly provides an opportunity for compromise.
But I think we first need to see what emerges from Minneapolis.

Mike

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: Wednesday, October 22, 2003 9:19 AM
> To: Michael Myers
> Cc: David Engberg; [email-masked]
> Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
>
>
>         Michael:
>
>         Does your skepticism about the usefulness of
> unilateral
> server-side extensions mean that we should permit a
> variant of nonce in
> which the client specifies how strongly he needs a
> nonce?  Since the
> current syntax of nonce is not officially published,
> I posted a possible
> extension several weeks ago.  The options were
> original (with unclear
> semantics in this respect), nonce required in
> response, and nonce optional
> in response.
>         For a server to actually prevent
> misunderstandings of whether or
> not he supports nonces by using a unilateral
> server-side extension, you'd
> need a server-side extension called "nonceSupported"
> with boolean syntax,
> which would have to be placed in EVERY response
> whether nonces are present
> in the request or not.  The "nonceUnsupported"
> extension strikes me as
> less useful than that.
>
>                 Tom Gindin
>

From: "Anders Rundgren" <[email-masked]>
To: "Karl Scheibelhofer" <[email-masked]>, "Florian Oelmaier" <[email-masked]>, <[email-masked]>
Cc: "'James Jing'" <[email-masked]>, "'Markus Lorch'" <[email-masked]>
Subject: Re: Standards for Web-signing II
Date: Thu, 30 Oct 2003 17:41:04 +0100
Sender: [email-masked]

Karl,

Thanx for the pointer!
However, although DSS indeed talks about the Web, Interfaces
and Signatures, this is AFAIU an entirely "programmatic"
web where things like WYSIWYS is of no importance.

To really screw up things, you need users and that calls for
something else.  Like a new standard :-)

Best
Anders

----- Original Message ----- 
From: "Karl Scheibelhofer" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; "Florian Oelmaier" <[email-masked]>; <[email-masked]>
Cc: "'James Jing'" <[email-masked]>; "'Markus Lorch'" <[email-masked]>
Sent: Thursday, October 30, 2003 17:14
Subject: Re: Standards for Web-signing II

as far as i know OASIS has started related efforts. see
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss

  Karl

--

Karl Scheibelhofer, IAIK - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Fax: +43 316 873 5520
http://jce.iaik.tugraz.at

----- Original Message ----- 
From: "Anders Rundgren" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>; <[email-masked]>
Cc: "'James Jing'" <[email-masked]>; "'Markus Lorch'"
<[email-masked]>
Sent: Thursday, October 30, 2003 2:49 PM
Subject: Re: Standards for Web-signing II

>
> Apologizes Steven.   Last comment.  This one is actually a bit
> interesting for any die-hard cryptographer.
>
> Thanx Florian,
>
> The manual to "Personal" is thick but leaves out all "hardcore" stuff
like:
>
> If MIME is "text/html" does it calculate hash of embedded objects?
> Actually what algorithm does it use for cononicalization of HTML or
> even for TXT?
>
> And what happens if you use "PKCS7SIGNED_Attached" and
> have MIME "text/html" and use embedded objects (IMGs)?  I don't
> think I want to know!  It will probably explode and crash my hard-disk :-)
> Or does it falsely just include the HTML disregarding WYSIWYS
> completely?
>
> My firm belief is that on-line signatures is a very different "animal"
> compared to signed e-mails, and MUST be designed from the ground
> and up in order to EVER work in an interoperable and useful manner.
>
> So where do we go now?  To CEN/ISSS, W3C, OASIS, IETF or what?
>
> Regards
> Anders Rundgren
>
> ----- Original Message -----
> From: "Florian Oelmaier" <[email-masked]>
> To: "'Anders Rundgren'" <[email-masked]>; "'James Jing'"
<[email-masked]>; "'Markus Lorch'" <[email-masked]>;
> <[email-masked]>
> Sent: Wednesday, October 29, 2003 17:23
> Subject: RE: Standards for Web-signing II
>
>
> > However, Identrus is a bank-controlled operation and
> > therefore operate in the same way as banks regarding their
> > technology. I.e. by acting "possessive" and most of all being
> > scared that a competitor would ever be able to profit on the
> > work done.
>
> We all know that acting "possessive" does not work really good on the
> internet. After all a secrect shared by more than three people isnt a
> secret anymore. If you need a hint at how the identrus Websigning works
> you may look at
> http://www.s-d.no/filer/manualer/Technical%20Description%203_1Rev1.pdf
> and read the identrus section there.
>
> --
> Florian Oelmaier
> SyTrust
>
>

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request change in son-of-rfc2633
Date: Thu, 30 Oct 2003 11:10:57 -0500
Importance: Normal
Sender: [email-masked]

Walt:

My comment was purely for checking the names during path validation.  I did
not say that you do not assert the names and do not make these available to
the RP as part of certification path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 30, 2003 9:19 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Request change in son-of-rfc2633

> I agree with you that both 3280 and X.509 require name chaining.
However,
> the security implications and security importance of name chaining is 
> overstated.
>
> For example, if signatures chain properly for the certificate and CRL 
> and the relying party has appropriate means (e.g., e-mail address) to
identify
> the subscriber, name chaining offers little in terms of security.
>
> My statement should be read purely in security (and NOT 
> interoperability) context.

I think this isn't quite right, if you intended it the way I'm interpreting
what you've written.

You seem to be saying only that "the relying-party must have appropriate
means to identify the *leaf* subscriber".  But surely, the RP must also have
appropriate means to identify the intermediate CAs as well, else the RP
cannot evaluate the degree of trust it places in the cert-chain.  And, for
better or worse, the standard means of identifying CAs is DN (not, e.g.,
email addr).

As with your note, this comment is security-relevant, not an observation on
interoperability.

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request change in son-of-rfc2633
Date: Thu, 30 Oct 2003 11:10:12 -0500
Importance: Normal
Sender: [email-masked]

Tom:

If the new Sub CA is rogue, name chaining will not help.  The CA who now
uses the compromise key can always issue certificates to those RP and assert
its own name.

If the new sub CA is not rogue and someone else compromised the original sub
CA key, that "someone else" can use the compromised key under the new CA
name to create bogus RPs.

If everything is benign, the original CA was revoked and not compromised,
some one could provide a certification path: root .....--> new CA --> RP
under old CA.  Without name chaining, this path could be validated and thus,
if the RP was compromised, that compromise can be exploited.  But, this is
only if the two CAs benignly use the same key. 

-----Original Message-----
From: Tom Biskupic [mailto:[email-masked]] 
Sent: Thursday, October 30, 2003 1:29 AM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: Request change in son-of-rfc2633

Hello,

Umm What about if you managed to have a Sub-CA certified using the
compromised key of another Sub CA?

The other sub CA was revoked (for key compromise) and therefore all the
certificates it issued are dead but if RP applications ignore the
name-chaining, wouldn't this effectively re-activate those certificates? RPs
checking one of those dead certs (and ignoring name chaining) could use the
newly certified Sub CA to build a (well bogus) path and would accept that
path.

Even POP won't save you as the entity applying to have the compromised CA
key re-certified may have the private key (as it was compromised).

Some CAs will check that the same key is not issued to two entities (and
thus would refuse to re-certify the Sub CA with a different name) however do
you want to rely on it?

Ok this is a bit theoretical... A Sub-CA being revoked for instance.

Tom

> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Thursday, 30 October 2003 07:51
> To: [email-masked]; [email-masked]
> Subject: RE: Request change in son-of-rfc2633
> 
> 
> Steve Hanna:
> 
> I agree with you that both 3280 and X.509 require name chaining. 
> However, the security implications and security importance of name 
> chaining is overstated.
> 
> For example, if signatures chain properly for the certificate and CRL 
> and the relying party has appropriate means (e.g., e-mail
> address) to identify
> the subscriber, name chaining offers little in terms of security.
> 
> My statement should be read purely in security (and NOT
> interoperability)
> context.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Steve Hanna
> Sent: Wednesday, October 29, 2003 9:58 AM
> To: Peter Gutmann
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Request change in son-of-rfc2633
> 
> 
> Anyone who "reads the PKIX tea leaves" and thinks that
> it's fine to skip name chaining checks in path validation needs to
> have their eyes checked. RFC 3280 says in many places that name 
> chaining MUST be checked.
> 
> In section 6.1:
> 
>  To meet this goal, the path validation process verifies, among other
> things, that a prospective certification path (a sequence of n
>  certificates) satisfies the following conditions:
> 
>     (a)  for all x in {1, ..., n-1}, the subject of certificate x is
>     the issuer of certificate x+1;
> 
> In section 6.1.3:
> 
>  (a)  Verify the basic certificate information.  The certificate  MUST
> satisfy each of the following:
> 
>  [...]
> 
>     (4)  The certificate issuer name is the working_issuer_name.
> 
> In section 4.1.2.6:
> 
>    If the subject is a CA (e.g., the basic constraints extension, as
>    discussed in 4.2.1.10, is present and the value of cA is TRUE), 
> then
>    the subject field MUST be populated with a non-empty distinguished
>    name matching the contents of the issuer field (section 4.1.2.4) in
>    all certificates issued by the subject CA.
> 
> RFC 2459 and X.509 both agree with this.
> 
> Whatever PKI topology you use, there's no need to break
> name chaining. I'm sure that some customers have created
> PKIs where name chaining doesn't hold, but that's an error
> on the customer's part. You can't just turn off critical security 
> checks to keep them happy. What's next? Don't bother checking the 
> signature on certificates. That takes too much time!
> 
> If somebody has implemented path validation without name chaining 
> checks, then they haven't implemented it according to IETF or X.509 
> standards. In fact, they may have opened themselves and their 
> customers up to security
> holes and perhaps even legal liability. CAs have every right to expect
> that certificates will be validated according to standards. Users also
> have a reasonable expectation of this. If someone 
> deliberately violates
> the standards in a way that opens up security holes, that sounds like
> gross negligence to me.
> 
> This reminds me of Microsoft's decision to not check the Basic
> Constraints extension, treating every certificate as a CA certificate. 
> This decision, presumably made in to please a customer, resulted in a 
> HUGE security hole.
> 
> I hope that Microsoft (and anyone else who has skipped required parts
> of the path validation algorithm for the sake of convenience) will see 
> that security cannot be second to user convenience. If there's a 
> serious problem with the specs, then let's fix them. But don't just 
> bypass things because you find it convenient.
> 
> Forgive me my rant. I'm just outraged that somebody would play fast
> and loose with security this way.
> 
> Thanks,
> 
> Steve
> 
> Peter Gutmann wrote:
> >
> > [Cross-posted back to S/MIME, where the thread started]
> >
> > Eric Norman <[email-masked]> writes:
> >
> > >Is there a claim (#1 above) that you can have the DN in the subject
> > >of a parent's (signer's) certificate be different from (as in 
> > >different bunch of
> > >bytes) the DN in the issuer of one of its offspring and
> yet the chain
> is
> > >still valid because the xKIDs match?
> >
> > Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI
> > that violates the original X.509 design, i.e. with re-parenting, 
> > arbitrary cross- certification, etc etc where issuers no
> longer match
> > subjects).  For example MS apparently implemented chaining
> by sKID in
> > Windows because of user demand for this when the users
> broke chaining
> > by issuer name through spaghetti PKI design practices, and various
> > other implementations no doubt do similar things, depending on how 
> > they've read the PKIX tea leaves.
> >
> > Peter.
> 

From: [email-masked]
Subject: RE: Request change in son-of-rfc2633
To: "Santosh Chokhani" <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 30 Oct 2003 09:18:41 -0500
Sender: [email-masked]

> I agree with you that both 3280 and X.509 require name chaining.
However,
> the security implications and security importance of name chaining is
> overstated.
>
> For example, if signatures chain properly for the certificate and CRL and
> the relying party has appropriate means (e.g., e-mail address) to
identify
> the subscriber, name chaining offers little in terms of security.
>
> My statement should be read purely in security (and NOT interoperability)
> context.

I think this isn't quite right, if you intended it the way I'm interpreting
what you've written.

You seem to be saying only that "the relying-party must have appropriate
means to identify the *leaf* subscriber".  But surely, the RP must also
have appropriate means to identify the intermediate CAs as well, else the
RP cannot evaluate the degree of trust it places in the cert-chain.  And,
for better or worse, the standard means of identifying CAs is DN (not,
e.g., email addr).

As with your note, this comment is security-relevant, not an observation on
interoperability.

From: "Anders Rundgren" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, <[email-masked]>
Cc: "'James Jing'" <[email-masked]>, "'Markus Lorch'" <[email-masked]>
Subject: Re: Standards for Web-signing II
Date: Thu, 30 Oct 2003 14:49:03 +0100
Sender: [email-masked]

Apologizes Steven.   Last comment.  This one is actually a bit
interesting for any die-hard cryptographer.

Thanx Florian,

The manual to "Personal" is thick but leaves out all "hardcore" stuff like:

If MIME is "text/html" does it calculate hash of embedded objects?
Actually what algorithm does it use for cononicalization of HTML or
even for TXT?

And what happens if you use "PKCS7SIGNED_Attached" and
have MIME "text/html" and use embedded objects (IMGs)?  I don't
think I want to know!  It will probably explode and crash my hard-disk :-)
Or does it falsely just include the HTML disregarding WYSIWYS
completely?

My firm belief is that on-line signatures is a very different "animal"
compared to signed e-mails, and MUST be designed from the ground
and up in order to EVER work in an interoperable and useful manner.

So where do we go now?  To CEN/ISSS, W3C, OASIS, IETF or what?

Regards
Anders Rundgren

----- Original Message -----
From: "Florian Oelmaier" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>; "'James Jing'" <[email-masked]>; "'Markus Lorch'" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, October 29, 2003 17:23
Subject: RE: Standards for Web-signing II

> However, Identrus is a bank-controlled operation and
> therefore operate in the same way as banks regarding their
> technology. I.e. by acting "possessive" and most of all being
> scared that a competitor would ever be able to profit on the
> work done.

We all know that acting "possessive" does not work really good on the
internet. After all a secrect shared by more than three people isnt a
secret anymore. If you need a hint at how the identrus Websigning works
you may look at
http://www.s-d.no/filer/manualer/Technical%20Description%203_1Rev1.pdf
and read the identrus section there.

--
Florian Oelmaier
SyTrust

From: Tom Biskupic <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: RE: Request change in son-of-rfc2633
Date: Thu, 30 Oct 2003 11:56:28 -0000
Sender: [email-masked]

Oops my appologies the previous version of this message went out signed with
a test certificate.

Here is the text again.

Tom

> -----Original Message-----
> From: Tom Biskupic [mailto:[email-masked]]
> Sent: Thursday, 30 October 2003 17:29
> To: 'Santosh Chokhani'; [email-masked]
> Subject: RE: Request change in son-of-rfc2633
> 
> 
> Hello,
> 
> Umm What about if you managed to have a Sub-CA certified using the
> compromised key of another Sub CA?
> 
> The other sub CA was revoked (for key compromise) and 
> therefore all the
> certificates it issued are dead but if RP applications ignore the
> name-chaining, wouldn't this effectively re-activate those 
> certificates?
> RPs checking one of those dead certs (and ignoring name 
> chaining) could
> use the newly certified Sub CA to build a (well bogus) path and would
> accept that path.
> 
> Even POP won't save you as the entity applying to have the compromised
> CA key re-certified may have the private key (as it was compromised).
> 
> Some CAs will check that the same key is not issued to two 
> entities (and
> thus would refuse to re-certify the Sub CA with a different name)
> however do you want to rely on it?
> 
> Ok this is a bit theoretical... A Sub-CA being revoked for instance.
> 
> Tom
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Thursday, 30 October 2003 07:51
> > To: [email-masked]; [email-masked]
> > Subject: RE: Request change in son-of-rfc2633
> > 
> > 
> > Steve Hanna:
> > 
> > I agree with you that both 3280 and X.509 require name 
> > chaining.  However,
> > the security implications and security importance of name 
> chaining is
> > overstated.
> > 
> > For example, if signatures chain properly for the certificate 
> > and CRL and
> > the relying party has appropriate means (e.g., e-mail 
> > address) to identify
> > the subscriber, name chaining offers little in terms of security.
> > 
> > My statement should be read purely in security (and NOT 
> > interoperability)
> > context.
> > 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]
> > On Behalf Of Steve Hanna
> > Sent: Wednesday, October 29, 2003 9:58 AM
> > To: Peter Gutmann
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: Request change in son-of-rfc2633
> > 
> > 
> > Anyone who "reads the PKIX tea leaves" and thinks that
> > it's fine to skip name chaining checks in path validation
> > needs to have their eyes checked. RFC 3280 says in many
> > places that name chaining MUST be checked.
> > 
> > In section 6.1:
> > 
> >  To meet this goal, the path validation process verifies, 
> among other
> > things, that a prospective certification path (a sequence of n
> >  certificates) satisfies the following conditions:
> > 
> >     (a)  for all x in {1, ..., n-1}, the subject of certificate x is
> >     the issuer of certificate x+1;
> > 
> > In section 6.1.3:
> > 
> >  (a)  Verify the basic certificate information.  The 
> certificate  MUST
> > satisfy each of the following:
> > 
> >  [...]
> > 
> >     (4)  The certificate issuer name is the working_issuer_name.
> > 
> > In section 4.1.2.6:
> > 
> >    If the subject is a CA (e.g., the basic constraints extension, as
> >    discussed in 4.2.1.10, is present and the value of cA is 
> > TRUE), then
> >    the subject field MUST be populated with a non-empty 
> distinguished
> >    name matching the contents of the issuer field (section 
> 4.1.2.4) in
> >    all certificates issued by the subject CA.
> > 
> > RFC 2459 and X.509 both agree with this.
> > 
> > Whatever PKI topology you use, there's no need to break
> > name chaining. I'm sure that some customers have created
> > PKIs where name chaining doesn't hold, but that's an error
> > on the customer's part. You can't just turn off critical 
> > security checks
> > to keep them happy. What's next? Don't bother checking the 
> > signature on
> > certificates. That takes too much time!
> > 
> > If somebody has implemented path validation without name 
> > chaining checks,
> > then they haven't implemented it according to IETF or X.509 
> > standards. In
> > fact, they may have opened themselves and their customers up 
> > to security
> > holes and perhaps even legal liability. CAs have every 
> right to expect
> > that certificates will be validated according to standards. 
> Users also
> > have a reasonable expectation of this. If someone 
> > deliberately violates
> > the standards in a way that opens up security holes, that 
> sounds like
> > gross negligence to me.
> > 
> > This reminds me of Microsoft's decision to not check the
> > Basic Constraints extension, treating every certificate
> > as a CA certificate. This decision, presumably made in
> > to please a customer, resulted in a HUGE security hole.
> > 
> > I hope that Microsoft (and anyone else who has skipped
> > required parts of the path validation algorithm for the
> > sake of convenience) will see that security cannot be
> > second to user convenience. If there's a serious problem
> > with the specs, then let's fix them. But don't just bypass 
> > things because
> > you find it convenient.
> > 
> > Forgive me my rant. I'm just outraged that somebody would
> > play fast and loose with security this way.
> > 
> > Thanks,
> > 
> > Steve
> > 
> > Peter Gutmann wrote:
> > >
> > > [Cross-posted back to S/MIME, where the thread started]
> > >
> > > Eric Norman <[email-masked]> writes:
> > >
> > > >Is there a claim (#1 above) that you can have the DN in 
> the subject
> > > >of a parent's (signer's) certificate be different from (as in
> > > >different bunch of
> > > >bytes) the DN in the issuer of one of its offspring and 
> > yet the chain
> > is
> > > >still valid because the xKIDs match?
> > >
> > > Sure, in a spaghetti PKI (I'm using that as a generic 
> term for a PKI
> > > that violates the original X.509 design, i.e. with re-parenting,
> > > arbitrary cross- certification, etc etc where issuers no 
> > longer match
> > > subjects).  For example MS apparently implemented chaining 
> > by sKID in
> > > Windows because of user demand for this when the users 
> > broke chaining
> > > by issuer name through spaghetti PKI design practices, and various
> > > other implementations no doubt do similar things, depending on how
> > > they've read the PKIX tea leaves.
> > >
> > > Peter.
> > 
> 

From: Tom Biskupic <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: RE: Request change in son-of-rfc2633
Date: Thu, 30 Oct 2003 06:29:18 -0000
Sender: [email-masked]

Date: Thu, 30 Oct 2003 17:05:15 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Request change in son-of-rfc2633
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Steve Hanna <[email-masked]> writes:

>Anyone who "reads the PKIX tea leaves" and thinks that it's fine to skip name 
>chaining checks in path validation needs to have their eyes checked. RFC 3280 
>says in many places that name chaining MUST be checked.

Uhh, I'm not sure who that was directed at, but if it was at me then I should 
point out that the tea leaves comment was an observation that no-one seemed to 
be able to agree on the role of the sKID, with all manner of possible 
interpretations having been presented in the recent thread.  Seeing everyone 
trying to figure out how to interpret the sKID requirements reminded me of 
people trying to read tea leaves.

Getting somewhat more tongue-in-cheek now:

>I'm sure that some customers have created PKIs where name chaining doesn't 
>hold, 

Standard practice for cross-certification, re-parenting, and all the other 
stuff that I gave the generic label "spaghetti PKI" to (you can tell from the 
label I use for it what I think of it :-).

>but that's an error on the customer's part.

That's what I've been saying for years (see e.g. my statement a couple of months
back "There is a special name for a PKI of this kind.  It's called 'Broken' or
'Defective'"), but I guess that's something the spaghetti PKI fans and myself 
will have to agree to disagree on.

>In fact, they may have opened themselves and their customers up to security 
>holes and perhaps even legal liability.

When was anyone ever held liable for implementing a broken PKI?  Usually any 
investment of large amounts of money that results in a broken PKI is followed 
by the investment of even more money in it (either that or the quiet 
cancellation of the project).  No-one ever gets held liable.  Why do you think
we have products like the ones you mentioned out there?

>This reminds me of Microsoft's decision to not check the Basic Constraints 
>extension, treating every certificate as a CA certificate. This decision, 
>presumably made in to please a customer, resulted in a HUGE security hole.

It wasn't a conscious decision, just bad programming.  Mozilla (and no doubt 
some others that didn't get any publicity) did the same thing, and I'm sure 
they didn't get asked to do that by customers.  The flaw had been known for at 
least five years, but no-one cared until the scaremongering in the media forced 
vendors to fix things (see the above comments about liability - you can get 
away with calling anything you like "X.509 standards-compliant", so why bother 
doing the job properly?).

Peter.

Date: Wed, 29 Oct 2003 21:26:12 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Standards for Web-signing II
Cc: <[email-masked]>
Sender: [email-masked]

At 17:29 +0100 10/29/03, Anders Rundgren wrote:
>  >since you obviously don't believe the IETF creates "real standards"
>>and since this topic is not a PKIX work item, I suggest you take the
>>"web-sigbing" discussion elsewhere.
>
>As the off-list response to "web-signing" has been pretty good, I
>just need to figure out where to go next.
>
>You did probably not read more than the first paragraph.  To go
>through a "real standardization process" was ONE of the stated
>alternatives.
>
>Anders

if your off-list response was so good, then you should have no 
trouble moving this discussion elsewhere.

I read all of the traffic re the subject topic, and as I noted, it is 
off topic for this WG, as have been most of your messages threads.

steve

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Request change in son-of-rfc2633
Date: Wed, 29 Oct 2003 15:50:35 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0060_01C39E1C.EE435990
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Steve Hanna:

I agree with you that both 3280 and X.509 require name chaining.  However,
the security implications and security importance of name chaining is
overstated.

For example, if signatures chain properly for the certificate and CRL and
the relying party has appropriate means (e.g., e-mail address) to identify
the subscriber, name chaining offers little in terms of security.

My statement should be read purely in security (and NOT interoperability)
context.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Steve Hanna
Sent: Wednesday, October 29, 2003 9:58 AM
To: Peter Gutmann
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Request change in son-of-rfc2633

Anyone who "reads the PKIX tea leaves" and thinks that
it's fine to skip name chaining checks in path validation
needs to have their eyes checked. RFC 3280 says in many
places that name chaining MUST be checked.

In section 6.1:

 To meet this goal, the path validation process verifies, among other
things, that a prospective certification path (a sequence of n
 certificates) satisfies the following conditions:

    (a)  for all x in {1, ..., n-1}, the subject of certificate x is
    the issuer of certificate x+1;

In section 6.1.3:

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

 [...]

    (4)  The certificate issuer name is the working_issuer_name.

In section 4.1.2.6:

   If the subject is a CA (e.g., the basic constraints extension, as
   discussed in 4.2.1.10, is present and the value of cA is TRUE), then
   the subject field MUST be populated with a non-empty distinguished
   name matching the contents of the issuer field (section 4.1.2.4) in
   all certificates issued by the subject CA.

RFC 2459 and X.509 both agree with this.

Whatever PKI topology you use, there's no need to break
name chaining. I'm sure that some customers have created
PKIs where name chaining doesn't hold, but that's an error
on the customer's part. You can't just turn off critical security checks
to keep them happy. What's next? Don't bother checking the signature on
certificates. That takes too much time!

If somebody has implemented path validation without name chaining checks,
then they haven't implemented it according to IETF or X.509 standards. In
fact, they may have opened themselves and their customers up to security
holes and perhaps even legal liability. CAs have every right to expect
that certificates will be validated according to standards. Users also
have a reasonable expectation of this. If someone deliberately violates
the standards in a way that opens up security holes, that sounds like
gross negligence to me.

This reminds me of Microsoft's decision to not check the
Basic Constraints extension, treating every certificate
as a CA certificate. This decision, presumably made in
to please a customer, resulted in a HUGE security hole.

I hope that Microsoft (and anyone else who has skipped
required parts of the path validation algorithm for the
sake of convenience) will see that security cannot be
second to user convenience. If there's a serious problem
with the specs, then let's fix them. But don't just bypass things because
you find it convenient.

Forgive me my rant. I'm just outraged that somebody would
play fast and loose with security this way.

Thanks,

Steve

Peter Gutmann wrote:
>
> [Cross-posted back to S/MIME, where the thread started]
>
> Eric Norman <[email-masked]> writes:
>
> >Is there a claim (#1 above) that you can have the DN in the subject
> >of a parent's (signer's) certificate be different from (as in
> >different bunch of
> >bytes) the DN in the issuer of one of its offspring and yet the chain
is
> >still valid because the xKIDs match?
>
> Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI
> that violates the original X.509 design, i.e. with re-parenting,
> arbitrary cross- certification, etc etc where issuers no longer match
> subjects).  For example MS apparently implemented chaining by sKID in
> Windows because of user demand for this when the users broke chaining
> by issuer name through spaghetti PKI design practices, and various
> other implementations no doubt do similar things, depending on how
> they've read the PKIX tea leaves.
>
> Peter.

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

------=_NextPart_000_0060_01C39E1C.EE435990--

From: "Anders Rundgren" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Standards for Web-signing II
Date: Wed, 29 Oct 2003 17:29:20 +0100
Sender: [email-masked]

>since you obviously don't believe the IETF creates "real standards" 
>and since this topic is not a PKIX work item, I suggest you take the 
>"web-sigbing" discussion elsewhere.

As the off-list response to "web-signing" has been pretty good, I
just need to figure out where to go next.

You did probably not read more than the first paragraph.  To go
through a "real standardization process" was ONE of the stated
alternatives.

Anders

From: "Florian Oelmaier" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "'James Jing'" <[email-masked]>, "'Markus Lorch'" <[email-masked]>, <[email-masked]>
Subject: RE: Standards for Web-signing II
Date: Wed, 29 Oct 2003 17:23:03 +0100
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> However, Identrus is a bank-controlled operation and 
> therefore operate in the same way as banks regarding their 
> technology. I.e. by acting "possessive" and most of all being 
> scared that a competitor would ever be able to profit on the 
> work done.

We all know that acting "possessive" does not work really good on the
internet. After all a secrect shared by more than three people isnt a
secret anymore. If you need a hint at how the identrus Websigning works
you may look at
http://www.s-d.no/filer/manualer/Technical%20Description%203_1Rev1.pdf
and read the identrus section there.

-- 
Florian Oelmaier
SyTrust

Date: Wed, 29 Oct 2003 09:57:46 -0500
From: Steve Hanna <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Request change in son-of-rfc2633
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms58E8539260192E6D326EA0C4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Anyone who "reads the PKIX tea leaves" and thinks that
it's fine to skip name chaining checks in path validation
needs to have their eyes checked. RFC 3280 says in many
places that name chaining MUST be checked.

In section 6.1:

 To meet this goal, the path validation process verifies, among other
 things, that a prospective certification path (a sequence of n
 certificates) satisfies the following conditions:

    (a)  for all x in {1, ..., n-1}, the subject of certificate x is
    the issuer of certificate x+1;

In section 6.1.3:

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

 [...]

    (4)  The certificate issuer name is the working_issuer_name.

In section 4.1.2.6:

   If the subject is a CA (e.g., the basic constraints extension, as
   discussed in 4.2.1.10, is present and the value of cA is TRUE), then
   the subject field MUST be populated with a non-empty distinguished
   name matching the contents of the issuer field (section 4.1.2.4) in
   all certificates issued by the subject CA.

RFC 2459 and X.509 both agree with this.

Whatever PKI topology you use, there's no need to break
name chaining. I'm sure that some customers have created
PKIs where name chaining doesn't hold, but that's an error
on the customer's part. You can't just turn off critical
security checks to keep them happy. What's next? Don't
bother checking the signature on certificates. That takes
too much time!

If somebody has implemented path validation without name
chaining checks, then they haven't implemented it according
to IETF or X.509 standards. In fact, they may have opened
themselves and their customers up to security holes and
perhaps even legal liability. CAs have every right to expect
that certificates will be validated according to standards.
Users also have a reasonable expectation of this. If someone
deliberately violates the standards in a way that opens
up security holes, that sounds like gross negligence to me.

This reminds me of Microsoft's decision to not check the
Basic Constraints extension, treating every certificate
as a CA certificate. This decision, presumably made in
to please a customer, resulted in a HUGE security hole.

I hope that Microsoft (and anyone else who has skipped
required parts of the path validation algorithm for the
sake of convenience) will see that security cannot be
second to user convenience. If there's a serious problem
with the specs, then let's fix them. But don't just bypass
things because you find it convenient.

Forgive me my rant. I'm just outraged that somebody would
play fast and loose with security this way.

Thanks,

Steve

Peter Gutmann wrote:
> 
> [Cross-posted back to S/MIME, where the thread started]
> 
> Eric Norman <[email-masked]> writes:
> 
> >Is there a claim (#1 above) that you can have the DN in the subject of a
> >parent's (signer's) certificate be different from (as in different bunch of
> >bytes) the DN in the issuer of one of its offspring and yet the chain is
> >still valid because the xKIDs match?
> 
> Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI that
> violates the original X.509 design, i.e. with re-parenting, arbitrary cross-
> certification, etc etc where issuers no longer match subjects).  For example
> MS apparently implemented chaining by sKID in Windows because of user demand
> for this when the users broke chaining by issuer name through spaghetti PKI
> design practices, and various other implementations no doubt do similar
> things, depending on how they've read the PKIX tea leaves.
> 
> Peter.
--------------ms58E8539260192E6D326EA0C4
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms58E8539260192E6D326EA0C4--

Date: Wed, 29 Oct 2003 09:56:16 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Standards for Web-signing II
Cc: <[email-masked]>
Sender: [email-masked]

At 14:06 +0100 10/29/03, Anders Rundgren wrote:
>I believe this is a very good opportunity to study how
>"Real Standards" actually are made:
>

since you obviously don't believe the IETF creates "real standards" 
and since this topic is not a PKIX work item, I suggest you take the 
"web-sigbing" discussion elsewhere.

Steve

Date: Wed, 29 Oct 2003 15:53:29 +0100
From: Hans-Peter Schwebler <[email-masked]>
To: James Jing <[email-masked]>
CC: Anders Rundgren <[email-masked]>, [email-masked]
Subject: Re: Standards for Web-signing II
Sender: [email-masked]

James,

Identrus defined two methods for web signing (ISPI (Identrus Signing 
Plugin Interface ) and ISIL (Identrus Signing Interface Library)).
However, the latest version of the documentation allows for so called
standalone applications (e.g. Adobe Acrobat and Microsoft Office) to
use a "native" signature mechanism which, of course, needs to satisfy
a couple of requirements set be Identrus.

I just want to point this out. I don't want to comment on it because
I am not yet sure whether I like this move or not.

And Anders, yes of course, Identrus is such an organization that 
provides technical documents under NDA only. Unless they have
changed their policy on that in the last weeks.

Regards,
Hans-Peter 

James Jing wrote:
> 
> Identrus, a global banking PKI body, defined two methods for web 
> signing. One is defined as a Netscape style browser plug-in, the 
> other defined as an abstract Java interface. It also requires the 
> content that is being signed to be separately displayed, and the 
> digest of the content to be calculated by the "trusted subsystem".
> 
> I personally think the best approach would be for a unified standard 
> to be adopted by all browsers, invocable by all common scripts like 
> JavaScript, regardless of what the underlying implementation of the 
> signature layer might be. I believe both PKCS#7 and XML standards 
> must be supported. Content-to-be-signed should be defined by MIME-type 
> so if the browser needs to popup another screen, it can be properly 
> display the content. Whether a separate popup should be displayed must 
> be determined by signature layer based on the type of key being used 
> to sign the content.
> 
> Regards
> James

From: "Anders Rundgren" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "'James Jing'" <[email-masked]>, "'Markus Lorch'" <[email-masked]>, <[email-masked]>
Subject: Re: Standards for Web-signing II
Date: Wed, 29 Oct 2003 14:06:35 +0100
Sender: [email-masked]

I believe this is a very good opportunity to study how
"Real Standards" actually are made:

If a vendor has a nice browser add-in solution that it believes
is worth the title "standard", there are a number of ways to
pursue this such as:

- Submitting the solution as "input" to a standards process.
  Costly, time-consuming, and potentially dangerous as you
  have to give up the control (well, maybe not if you are a
  BIG enough vendor...)

- Make the code available for free download in order to
  spread the solution, and blocking competing efforts.
  A vey popular method indeed!

- Submitting the code to let's say Microsoft, Mozilla.org etc
  for free inclusion, and by that establishing a "de-facto" standard

However, Identrus is a bank-controlled operation and therefore
operate in the same way as banks regarding their technology.
I.e. by acting "possessive" and most of all being scared that
a competitor would ever be able to profit on the work done.

A similar thing is the EMV-card that surely could replace most
other PKI cards on the market, but since it is also owned by a
bank-controlled entity, they will probably never make the client
software downloadable, a preinstall in Windows, or make the
card purchasable in small quantities on the web by anybody, and
will therefore most likely fail to establish EMV as a "de-facto"
standard.

If bank executives ever go to the Cinema(?), or rent a video,
they should take a look on the movie "A beautiful mind"
while at the same time thinking on the establishment of
important e-infrastructures.  Unfortunately, when you get
a fresh view on things, you often fail to apply it to your
own backyard because that "is a different thing".  But
it isn't, the problems with establishing common e-standards
are pretty universal and so are the "workarounds".  Unless
you are Microsoft and actually can do whatever you want,
and most of the time it even get it to work fairly well.

Anders Rundgren

----- Original Message -----
From: "Florian Oelmaier" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>; "'James Jing'" <[email-masked]>; "'Markus Lorch'" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, October 29, 2003 11:41
Subject: RE: Standards for Web-signing II

> >Identrus, a global banking PKI body, defined two methods for web
> >signing. One is defined as a Netscape style browser plug-in,
> the other
> >defined as an abstract Java interface.
>
> The Netscape plugin interface was dropped in IE V6 and Java
> does not look like an MSFT favorite.  This was just a side note.

Identrus defined a MIME-type to be used within an <EMBED>- or an
<OBJECT>-tag to include the signing plugin into HTML-pages. What type of
plugin processes this tag is not of concern to the identrus
specification. Netscape plugins or IE native plugins: both plugin
architectures should be able to handle the defined tag.

--
Florian Oelmaier
SyTrust

From: "Florian Oelmaier" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "'James Jing'" <[email-masked]>, "'Markus Lorch'" <[email-masked]>, <[email-masked]>
Subject: RE: Standards for Web-signing II
Date: Wed, 29 Oct 2003 11:41:01 +0100
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> >Identrus, a global banking PKI body, defined two methods for web 
> >signing. One is defined as a Netscape style browser plug-in, 
> the other 
> >defined as an abstract Java interface.
> 
> The Netscape plugin interface was dropped in IE V6 and Java 
> does not look like an MSFT favorite.  This was just a side note.

Identrus defined a MIME-type to be used within an <EMBED>- or an
<OBJECT>-tag to include the signing plugin into HTML-pages. What type of
plugin processes this tag is not of concern to the identrus
specification. Netscape plugins or IE native plugins: both plugin
architectures should be able to handle the defined tag.

-- 
Florian Oelmaier
SyTrust

From: "Anders Rundgren" <[email-masked]>
To: "James Jing" <[email-masked]>, "Markus Lorch" <[email-masked]>, <[email-masked]>, "Florian Oelmaier" <[email-masked]>
Subject: Re: Standards for Web-signing II
Date: Wed, 29 Oct 2003 07:37:40 +0100
Sender: [email-masked]

>Identrus, a global banking PKI body, defined two methods for
>web signing. One is defined as a Netscape style
>browser plug-in, the other defined as an abstract Java interface. 

The Netscape plugin interface was dropped in IE V6 and Java
does not look like an MSFT favorite.  This was just a side note.

>It also requires the content that is being signed to be
>separately displayed, and the digest of the content to be
>calculated by the "trusted subsystem".

Identrus, is I guess one of these parties requiring NDA?

>I personally think the best approach would be for a unified standard to
>be adopted by all browsers, invocable by all common scripts like
>JavaScript, regardless of what the underlying implementation of the
>signature layer might be. 
>I believe both PKCS#7 and XML standards
>must be supported. Content-to-be-signed should be defined by
>MIME-type so if the browser needs to popup another screen, it
>can be properly display the content. Whether a separate popup
>should be displayed must be determined by signature layer based
>on the type of key being used to sign the content.

I agree!
Although I do believe on-line signing is still a field that needs a
little more research as it is really very different to off-line.

Anders

Regards
James

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Wednesday, 29 October 2003 6:59 AM
To: Markus Lorch; [email-masked]
Subject: Re: Standards for Web-signing II

Markus,

XML Signature standard essentially define something like
CMS/PKCS #7 in XML.  The standard "talks" about the signing
process but does not define any interface between the browser
and the signature requester which is what is needed among
many things in order to achieve a web-signing standard.

But this one is just for starters, the browser-interface for
on-line certfication processes (which seem to be the future)
is also not standardized.  MSFT's Xenroll has no implementation
in Mozilla or Netscape.  Few serious systems for this reason
build on Xenroll but rather on proprietary solutions.  Xenroll
is also in my opinion an unsatisfactory solution as the GUI
should be the same for each CA rather than all over the map.

rgds
Anders

----- Original Message ----- 
From: "Markus Lorch" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 28, 2003 20:01
Subject: RE: Standards for Web-signing II

Anders,

isn't the XML Signature a standard that can be used for this

see
Mark Bartel et al, "XML Signature Syntax and Processing", World Wide Web
Consortium Recommendation, February 2002

Markus

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anders Rundgren
> Sent: Tuesday, October 28, 2003 8:47 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Standards for Web-signing II
> 
> 
> 
> The answer to my earlier request seems to be:
> 
> There are apparently no standards and nothing in the works either
> with respect to signing on-line data on the web using 
> Internet browsers.
> 
> Since web-signing is today [*] used by many, many, more people
> and organizations than there are users of signed e-email, I 
> remain puzzled.
> 
> Is the PKI community really just a bunch of "nerds", mostly
> out of touch with the needs of the market?  The question is open.
> 
> *] Like Scandinavian banks having > 0.5M of users.
> All current systems rely on entirely proprietary mechanisms.
> Most of the vendors even require NDAs for getting the documentation.
> 
> Anders Rundgren
> 
> 
> ----- Original Message -----
> From: "Anders Rundgren" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> Sent: Tuesday, September 02, 2003 14:07
> Subject: [pki-tc] Standards for Web-signing
> 
> 
> Folks,
> I just wanted to know the status of possible standardization
> efforts regarding signing on-line forms etc. on web.  As web-signing
> is a core function of many e-governments when communicating
> with their citizens it seems that this should be standardized if
> not already is.
> 
> Pointers are welcome.  Off-list or on-list.
> 
> rgds
> Anders Rundgren
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/le
ave_workgroup.php.

Date: Wed, 29 Oct 2003 16:37:56 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Request change in son-of-rfc2633
Cc: [email-masked]
Sender: [email-masked]

[Cross-posted back to S/MIME, where the thread started]

Eric Norman <[email-masked]> writes:

>Is there a claim (#1 above) that you can have the DN in the subject of a
>parent's (signer's) certificate be different from (as in different bunch of
>bytes) the DN in the issuer of one of its offspring and yet the chain is
>still valid because the xKIDs match?

Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI that
violates the original X.509 design, i.e. with re-parenting, arbitrary cross-
certification, etc etc where issuers no longer match subjects).  For example
MS apparently implemented chaining by sKID in Windows because of user demand
for this when the users broke chaining by issuer name through spaghetti PKI
design practices, and various other implementations no doubt do similar
things, depending on how they've read the PKIX tea leaves.

Peter.

From: "Florian Oelmaier" <[email-masked]>
To: "'Markus Lorch'" <[email-masked]>, "'Anders Rundgren'" <[email-masked]>, <[email-masked]>
Subject: RE: Standards for Web-signing II
Date: Wed, 29 Oct 2003 01:37:05 +0100
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> > Folks,
> > I just wanted to know the status of possible 
> standardization efforts 
> > regarding signing on-line forms etc. on web.  As 
> web-signing is a core 
> > function of many e-governments when communicating with 
> their citizens 
> > it seems that this should be standardized if not already is.
> > 
> > Pointers are welcome.  Off-list or on-list.

Most products out there are more or less compliant with the identrus
specifications for websigning (ISIL & ISPI). These specifications are
not openly available but from a technical point of view these specs are
not limited to identrus usage.

-- 
Florian Oelmaier
SyTrust

content-class: urn:content-classes:message
Subject: RE: Standards for Web-signing II
Date: Wed, 29 Oct 2003 10:02:20 +1100
From: "James Jing" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, "Markus Lorch" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Identrus, a global banking PKI body, defined two methods for web signing. One is defined as a Netscape style browser plug-in, the other defined as an abstract Java interface. It also requires the content that is being signed to be separately displayed, and the digest of the content to be calculated by the "trusted subsystem".

I personally think the best approach would be for a unified standard to be adopted by all browsers, invocable by all common scripts like JavaScript, regardless of what the underlying implementation of the signature layer might be. I believe both PKCS#7 and XML standards must be supported. Content-to-be-signed should be defined by MIME-type so if the browser needs to popup another screen, it can be properly display the content. Whether a separate popup should be displayed must be determined by signature layer based on the type of key being used to sign the content.

Regards
James

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Wednesday, 29 October 2003 6:59 AM
To: Markus Lorch; [email-masked]
Subject: Re: Standards for Web-signing II

Markus,

XML Signature standard essentially define something like
CMS/PKCS #7 in XML.  The standard "talks" about the signing
process but does not define any interface between the browser
and the signature requester which is what is needed among
many things in order to achieve a web-signing standard.

But this one is just for starters, the browser-interface for
on-line certfication processes (which seem to be the future)
is also not standardized.  MSFT's Xenroll has no implementation
in Mozilla or Netscape.  Few serious systems for this reason
build on Xenroll but rather on proprietary solutions.  Xenroll
is also in my opinion an unsatisfactory solution as the GUI
should be the same for each CA rather than all over the map.

rgds
Anders

----- Original Message ----- 
From: "Markus Lorch" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 28, 2003 20:01
Subject: RE: Standards for Web-signing II

Anders,

isn't the XML Signature a standard that can be used for this

see
Mark Bartel et al, "XML Signature Syntax and Processing", World Wide Web
Consortium Recommendation, February 2002

Markus

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anders Rundgren
> Sent: Tuesday, October 28, 2003 8:47 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Standards for Web-signing II
> 
> 
> 
> The answer to my earlier request seems to be:
> 
> There are apparently no standards and nothing in the works either
> with respect to signing on-line data on the web using 
> Internet browsers.
> 
> Since web-signing is today [*] used by many, many, more people
> and organizations than there are users of signed e-email, I 
> remain puzzled.
> 
> Is the PKI community really just a bunch of "nerds", mostly
> out of touch with the needs of the market?  The question is open.
> 
> *] Like Scandinavian banks having > 0.5M of users.
> All current systems rely on entirely proprietary mechanisms.
> Most of the vendors even require NDAs for getting the documentation.
> 
> Anders Rundgren
> 
> 
> ----- Original Message -----
> From: "Anders Rundgren" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> Sent: Tuesday, September 02, 2003 14:07
> Subject: [pki-tc] Standards for Web-signing
> 
> 
> Folks,
> I just wanted to know the status of possible standardization
> efforts regarding signing on-line forms etc. on web.  As web-signing
> is a core function of many e-governments when communicating
> with their citizens it seems that this should be standardized if
> not already is.
> 
> Pointers are welcome.  Off-list or on-list.
> 
> rgds
> Anders Rundgren
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/le
ave_workgroup.php.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sonof3039-02.txt
Date: Tue, 28 Oct 2003 15:44:22 -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:Qualified Certificates Profile
	Author(s)	: S. Santesson, M. Nystrom
	Filename	: draft-ietf-pkix-sonof3039-02.txt
	Pages		: 35
	Date		: 2003-10-28
	
This document forms a certificate profile, based on RFC 3280, for
dentity certificates issued to physical persons.
The goal of this document is to define a general syntax independent
of local legal requirements.  The profile is however designed to
allow further profiling in order to meet specific local needs.
The profile defines specific conventions for certificates that are
qualified within a defined legal framework, named Qualified
Certificates. The profile does however not define any legal
requirements for such Qualified Certificates.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-sonof3039-02.txt".

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

From: "Anders Rundgren" <[email-masked]>
To: "Markus Lorch" <[email-masked]>, <[email-masked]>
Subject: Re: Standards for Web-signing II
Date: Tue, 28 Oct 2003 20:58:59 +0100
Sender: [email-masked]

Markus,

XML Signature standard essentially define something like
CMS/PKCS #7 in XML.  The standard "talks" about the signing
process but does not define any interface between the browser
and the signature requester which is what is needed among
many things in order to achieve a web-signing standard.

But this one is just for starters, the browser-interface for
on-line certfication processes (which seem to be the future)
is also not standardized.  MSFT's Xenroll has no implementation
in Mozilla or Netscape.  Few serious systems for this reason
build on Xenroll but rather on proprietary solutions.  Xenroll
is also in my opinion an unsatisfactory solution as the GUI
should be the same for each CA rather than all over the map.

rgds
Anders

----- Original Message ----- 
From: "Markus Lorch" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 28, 2003 20:01
Subject: RE: Standards for Web-signing II

Anders,

isn't the XML Signature a standard that can be used for this

see
Mark Bartel et al, "XML Signature Syntax and Processing", World Wide Web
Consortium Recommendation, February 2002

Markus

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anders Rundgren
> Sent: Tuesday, October 28, 2003 8:47 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Standards for Web-signing II
> 
> 
> 
> The answer to my earlier request seems to be:
> 
> There are apparently no standards and nothing in the works either
> with respect to signing on-line data on the web using 
> Internet browsers.
> 
> Since web-signing is today [*] used by many, many, more people
> and organizations than there are users of signed e-email, I 
> remain puzzled.
> 
> Is the PKI community really just a bunch of "nerds", mostly
> out of touch with the needs of the market?  The question is open.
> 
> *] Like Scandinavian banks having > 0.5M of users.
> All current systems rely on entirely proprietary mechanisms.
> Most of the vendors even require NDAs for getting the documentation.
> 
> Anders Rundgren
> 
> 
> ----- Original Message -----
> From: "Anders Rundgren" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> Sent: Tuesday, September 02, 2003 14:07
> Subject: [pki-tc] Standards for Web-signing
> 
> 
> Folks,
> I just wanted to know the status of possible standardization
> efforts regarding signing on-line forms etc. on web.  As web-signing
> is a core function of many e-governments when communicating
> with their citizens it seems that this should be standardized if
> not already is.
> 
> Pointers are welcome.  Off-list or on-list.
> 
> rgds
> Anders Rundgren
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/le
ave_workgroup.php.

From: "Markus Lorch" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, <[email-masked]>
Subject: RE: Standards for Web-signing II
Date: Tue, 28 Oct 2003 14:01:14 -0500
Importance: Normal
Sender: [email-masked]

Anders,

isn't the XML Signature a standard that can be used for this

see
Mark Bartel et al, "XML Signature Syntax and Processing", World Wide Web
Consortium Recommendation, February 2002

Markus

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anders Rundgren
> Sent: Tuesday, October 28, 2003 8:47 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Standards for Web-signing II
> 
> 
> 
> The answer to my earlier request seems to be:
> 
> There are apparently no standards and nothing in the works either
> with respect to signing on-line data on the web using 
> Internet browsers.
> 
> Since web-signing is today [*] used by many, many, more people
> and organizations than there are users of signed e-email, I 
> remain puzzled.
> 
> Is the PKI community really just a bunch of "nerds", mostly
> out of touch with the needs of the market?  The question is open.
> 
> *] Like Scandinavian banks having > 0.5M of users.
> All current systems rely on entirely proprietary mechanisms.
> Most of the vendors even require NDAs for getting the documentation.
> 
> Anders Rundgren
> 
> 
> ----- Original Message -----
> From: "Anders Rundgren" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> Sent: Tuesday, September 02, 2003 14:07
> Subject: [pki-tc] Standards for Web-signing
> 
> 
> Folks,
> I just wanted to know the status of possible standardization
> efforts regarding signing on-line forms etc. on web.  As web-signing
> is a core function of many e-governments when communicating
> with their citizens it seems that this should be standardized if
> not already is.
> 
> Pointers are welcome.  Off-list or on-list.
> 
> rgds
> Anders Rundgren
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/le
ave_workgroup.php.

Date: Tue, 28 Oct 2003 18:43:58 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: SCVP additions
Sender: [email-masked]

hello,

It would be nice to hear whether all or which comments
about SCVP have been addressed. Unless I have overlooked
something, my remarks about the definitions of requestor
and responder have not received any treatment. 

I simplify the content of my comments:

requestor and responder should be GENERALNAMES which
indicate and identify in global the partipating parties.  

IMO Using arbitrary octets with only LOCAL significance
is not compatible with the procedure to detect loops.

4.6 indicates the there MUST NOt be null characters,
something which is explicitly allowed for a server
acting as a relay.

What is the sense of 4.7? The responder field is
never used anywhere in the actual protocol, what
is the meaning of such an opaque value?

4.8.5 What is the reason of having an additional octet string
encapsulation instead of an any defined by construct? Is it
that some tools may break decodeing when they find an OID
that is not known? If so, whay are there ANY DEFINED BYs at
other places?

can someone indicate me how a relay would return the response
of the next server to a client as part of his response?

regards

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-scvp-13.txt
Date: Tue, 28 Oct 2003 09:30:56 -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		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-scvp-13.txt
	Pages		: 49
	Date		: 2003-10-27
	
SCVP allows a client to offload certificate handling to a server.  
The server can provide the client with a variety of valuable 
information about the certificate, such as whether the certificate 
is valid, a certification path to a trust anchor, and revocation 
status.  SCVP has many purposes, including simplifying client 
implementations and allowing companies to centralize trust and 
policy management.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-13.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sim-01.txt
Date: Tue, 28 Oct 2003 09:30:49 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
	Author(s)	: J. Park
	Filename	: draft-ietf-pkix-sim-01.txt
	Pages		: 12
	Date		: 2003-10-27
	
This document provides the new straightforward approach to generate 
and verify unique information for identifying of the certificate 
subject. 
A Virtual ID(VID) may be put into the 'othername' field of the X.509 
subjectAltName certificate extension to make provisions for 
identifying the subject.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-sim-01.txt".

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Standards for Web-signing II
Date: Tue, 28 Oct 2003 14:46:37 +0100
Sender: [email-masked]

The answer to my earlier request seems to be:

There are apparently no standards and nothing in the works either
with respect to signing on-line data on the web using Internet browsers.

Since web-signing is today [*] used by many, many, more people
and organizations than there are users of signed e-email, I remain puzzled.

Is the PKI community really just a bunch of "nerds", mostly
out of touch with the needs of the market?  The question is open.

*] Like Scandinavian banks having > 0.5M of users.
All current systems rely on entirely proprietary mechanisms.
Most of the vendors even require NDAs for getting the documentation.

Anders Rundgren

----- Original Message -----
From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 02, 2003 14:07
Subject: [pki-tc] Standards for Web-signing

Folks,
I just wanted to know the status of possible standardization
efforts regarding signing on-line forms etc. on web.  As web-signing
is a core function of many e-governments when communicating
with their citizens it seems that this should be standardized if
not already is.

Pointers are welcome.  Off-list or on-list.

rgds
Anders Rundgren

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/leave_workgroup.php.

Content-class: urn:content-classes:message
Subject: Finalizing sonOfRFC3039
Date: Tue, 28 Oct 2003 12:23:10 -0000
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Cc: "Tim Polk" <[email-masked]>, "Nystrom, Magnus" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C39D4E.6E308D7D"

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

All,

=20

It is time to close the son of RFC 3039 work item and move on.

A new draft was submitted before the cut-off 09.00 yesterday and will
hopefully appear on the IETF PKIX web soon.

=20

In this mail I will summarize the edits that has been done to this
document since RFC 3039.

It is my hope that any issues that anyone may have with this update can
be resolved during IETF in Minneapolis by either direct discussions or
e-mail.

=20

/Stefan

=20

Background:

=20

RFC 3039 is widely adopted and referenced throughout Europe as RFC 3039
together with the ETSI standard TS 101 862 is the common profile for
issuing Qualified Certificates (QC).

TS 101862 defines how to comply with the European electronic signature
directive and RFC 3039 forms the base profile on which TS 101862 is
based.

RFC 3039, however is widely used also for non-QC where TS 101862 doesn't
apply.

=20

This year ETSI initiated a work item (STF 220 Task 3) to further
harmonize public certificates issued to physical persons in Europe. The
deliverables are to:

-          Contribute to the update of RFC 3039

-          Update TS 101862

-          Generate new Technical Specification (TS 102 280) based on
the updated standards above.

=20

The new standard TS 102280 is intended as a generic ID-certificate
profile recognized throughout EU CA:s and service providers.

A first draft of TS 102280 has been produced and can be obtained by me
upon request.

=20

Updates to RFC 3039

=20

As stated above, it is important to finalize son of RFC 3039 in order to
finalize TS 102280 within its time frame (publication in April 04)

STF 220 Task 3 has produced, as part of its work, input to the update of
RFC 3039 (included below) that has been circulated among CA:s and
application providers mainly in Europe.

=20

Summary of updates are:

-          Various editorial updates of document scope and introductory
sections

-          Reference updates (e.g. changed RFC 2459 to RFC 3280)

-          domainComponent attribute added to subject field attribute
list

-          title attribute added to subject field attribute list

-          postalAddress removed from subject field attribute list

-          title removed from subjectDirectoryAttribute extension
attribute list

-          Key usage: Recommendation that NR SHOULD be exclusive if set
has been removed

-          Scope update of qcStatements extension

=20

It is important to note that NO syntax changes has been made to the
document.

=20

Further actions before producing RFC:

- finalize reference updates (X.509 is still old reference)

- Finalize ASN.1 parts (get new assigned numbers)

=20

=20

Recommendations from ETSI STF 220 Task 3

=20

Following is the section 2 from the STF 220 Task 3 requirements
document. The whole document can be obtained from me upon request.

=20

2   Recommendations on RFC 3039 updates=20

As part of this task, STF will seek to influence the update of RFC 3039
to adapt the following changes:

=20

2.1 Scope

RFC 3039 defines a number of aspects that are generic for both Qualified
Certificates as well as certificates to physical persons that are not
"Qualified". Examples are defined attributes, biometricInfo extension,
and aspects of the qcStatements extension. The scope of RFC 3039 should
be updated to more clearly reflect this reality, as well as other
proposed changes to the profile.

=20

2.2 References

References need to be updated. E.g. from RFC 2459 to RFC 3280

=20

2.3 Key usage

As a result of generalizing RFC 3039, the current requirement of having
non-repudiation exclusive if set, becomes too specific and cause
confusion in term of for which cases this applies and which cases it
does not. This has shown to diminish the use of other functions of RFC
3039 in certificates where RFC 3039 in general applies, but this
paragraph does not.

=20

=20

2.4 Subject field

The set of attributes should be updated.

=20

postalAddress should be removed from the list of attributes in the
subject field and title attribute should be included and removed from
the subjectDirectoryAttributes extension.

=20

PostalAddress is not supported by RFC 3280 for use in the subject field
and no records of its use in the subject field in public certificates,
as a distinguishing attribute, has been encountered. It is also a
structured attribute and therefore not appropriate for use as an RDN.=20

=20

Title on the other hand is frequently used. The common place to put this
attribute is in the subject field. Since we recommend against use of the
subjectDirectoryAttribute extension, the recommended location of the
title attribute should be in the subject field.

=20

domainComponent attribute should be added to the list of distingushing
subject attributes. This attribute is commonly used in Subject field,
primary as alternative to Country and Organization.

=20

2.5 qcStatements extension

The defined scope of this extension should be considered for update and
adaptation to its current and potential use.

=20

The important thing is thus to preserve the syntax of the qcStatements
extension in order to secure backwards compatibility.=20

=20

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

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:337537144;
	mso-list-type:hybrid;
	mso-list-template-ids:1206391600 -2061464258 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";}
@list l1
	{mso-list-id:887566121;
	mso-list-type:hybrid;
	mso-list-template-ids:597996132 -2061464258 67698691 67698693 67698689 =
67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>It is time to close the son of RFC 3039 work item and =
move
on.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>A new draft was submitted before the cut-off 09.00 =
yesterday
and will hopefully appear on the IETF PKIX web =
soon.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In this mail I will summarize the edits that has been =
done
to this document since RFC 3039.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>It is my hope that any issues that anyone may have =
with this
update can be resolved during IETF in <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Minneapolis</st1:place></st1:City>
by either direct discussions or e-mail.<o:p></o:p></span></font></p>

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

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

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

<p class=3DMsoNormal><b><u><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Background:<o:p></o:p></span></font><=
/u></b></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>RFC 3039 is widely adopted and referenced throughout =
Europe
as RFC 3039 together with the ETSI standard TS 101&nbsp;862 is the =
common profile
for issuing Qualified Certificates (QC).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>TS 101862 defines how to comply with the European =
electronic
signature directive and RFC 3039 forms the base profile on which TS =
101862 is
based.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>RFC 3039, however is widely used also for non-QC =
where TS
101862 doesn&#8217;t apply.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This year ETSI initiated a work item (STF 220 Task 3) =
to
further harmonize public certificates issued to physical persons in =
<st1:place
w:st=3D"on">Europe</st1:place>. The deliverables are =
to:<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Contribute to the update of =
RFC 3039<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Update TS =
101862<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l1 level1 =
lfo1'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Generate new Technical =
Specification
(TS 102&nbsp;280) based on the updated standards =
above.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The new standard TS 102280 is intended as a generic
ID-certificate profile recognized throughout <st1:place =
w:st=3D"on"><st1:City
 w:st=3D"on">EU</st1:City> <st1:State =
w:st=3D"on">CA</st1:State></st1:place>:s and
service providers.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>A first draft of TS 102280 has been produced and can =
be
obtained by me upon request.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><b><u><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Updates to RFC =
3039<o:p></o:p></span></font></u></b></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>As stated above, it is important to finalize son of =
RFC 3039
in order to finalize TS 102280 within its time frame (publication in =
April 04)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>STF 220 Task 3 has produced, as part of its work, =
input to
the update of RFC 3039 (included below) that has been circulated among =
CA:s and
application providers mainly in <st1:place =
w:st=3D"on">Europe</st1:place>.<o:p></o:p></span></font></p>

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

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

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Various editorial updates =
of document
scope and introductory sections<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Reference updates (e.g. =
changed RFC
2459 to RFC 3280)<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>domainComponent attribute =
added to
subject field attribute list<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>title attribute added to =
subject
field attribute list<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>postalAddress removed from =
subject
field attribute list<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>title removed from
subjectDirectoryAttribute extension attribute =
list<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Key usage: Recommendation =
that NR
SHOULD be exclusive if set has been removed<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:36.0pt;text-indent:-18.0pt;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Scope update of =
qcStatements
extension<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>It is important to note that NO syntax changes has =
been made
to the document.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Further actions before producing =
RFC:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>- finalize reference updates (X.509 is still old =
reference)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>- Finalize ASN.1 parts (get new assigned =
numbers)<o:p></o:p></span></font></p>

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

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

<p class=3DMsoNormal><b><u><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>Recommendations from ETSI STF 220 =
Task 3<o:p></o:p></span></font></u></b></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Following is the section 2 from the STF 220 Task 3
requirements document. The whole document can be obtained from me upon =
request.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>2&nbsp;&nbsp; =
Recommendations on RFC
3039 updates <o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>As part of this task, STF will seek to influence the update of =
RFC 3039
to adapt the following changes:<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>2.1 =
Scope<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>RFC 3039 defines a number of aspects that are generic for both
Qualified Certificates as well as certificates to physical persons that =
are not
&#8220;Qualified&#8221;. Examples are defined attributes, biometricInfo
extension, and aspects of the qcStatements extension. The scope of RFC =
3039
should be updated to more clearly reflect this reality, as well as other =
proposed
changes to the profile.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>2.2 =
References<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>References need to be updated. E.g. from RFC 2459 to RFC =
3280<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>2.3 Key =
usage<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>As a result of generalizing RFC 3039, the current requirement of =
having
non-repudiation exclusive if set, becomes too specific and cause =
confusion in
term of for which cases this applies and which cases it does not. This =
has
shown to diminish the use of other functions of RFC 3039 in certificates =
where
RFC 3039 in general applies, but this paragraph does =
not.<o:p></o:p></span></font></p>

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

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

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>2.4 Subject =
field<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>The set of attributes should be =
updated.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>postalAddress should be removed from the list of attributes in =
the
subject field and title attribute should be included and removed from =
the
subjectDirectoryAttributes extension.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>PostalAddress is not supported by RFC 3280 for use in the =
subject field
and no records of its use in the subject field in public certificates, =
as a
distinguishing attribute, has been encountered. It is also a structured
attribute and therefore not appropriate for use as an RDN. =
<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Title on the other hand is frequently used. The common place to =
put
this attribute is in the subject field. Since we recommend against use =
of the
subjectDirectoryAttribute extension, the recommended location of the =
title
attribute should be in the subject field.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>domainComponent attribute should be added to the list of =
distingushing
subject attributes. This attribute is commonly used in Subject field, =
primary
as alternative to Country and Organization.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-weight:bold'>2.5 qcStatements =
extension<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>The defined scope of this extension should be considered for =
update and
adaptation to its current and potential =
use.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>The important thing is thus to preserve the syntax of the =
qcStatements
extension in order to secure backwards compatibility. =
<o:p></o:p></span></font></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C39D4E.6E308D7D--

--------------InterScan_NT_MIME_Boundary--

Date: Tue, 28 Oct 2003 11:51:26 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: RE: Request change in son-of-rfc2633
Sender: [email-masked]

I always thought that the semantics of an SKID/AKID pair
(if keyidentifier is used) of just an AKID(choice issue/serial)
is the following:

During path building among all certificates that have the
chain correctly with the issuer/subject take all those
as candidates that have the same public key as the
one that is identified by the SKID/AKID. 

This is done in order to avoid unnecessary verification
of the certificate signature for all candidates.

Peter

Date: Tue, 28 Oct 2003 00:18:52 -0600 (CST)
From: Eric Norman <[email-masked]>
To: PKIX list <[email-masked]>
Subject: RE: Request change in son-of-rfc2633
Sender: [email-masked]

On Tue, 28 Oct 2003, Peter Gutmann wrote:

> As was almost everyone else.  The problem is that there are two incompatible
> interpretations of the sKID:
>
> 1. Alternative chaining mechanism if chaining by DN fails, e.g. with cert
>    reparenting or some types of spaghetti PKIs.
>
> 2. Disambiguating factor if chaining by DN leads to multiple issuers, e.g.
>    with other types of spaghetti PKIs.

Is there a claim (#1 above) that you can have the DN in the subject of a
parent's (signer's) certificate be different from (as in different bunch
of bytes) the DN in the issuer of one of its offspring and yet the chain
is still valid because the xKIDs match?  That doesn't seem like an
incompatible interpretation; it seems more like a totally unreasonable
(as in incorrect) interpretation.

Even if some issuer were changing its name but not its signing key, the
old certificates with the old name in the subject field would still be
used, wouldn't they?

Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-12.txt
Date: Mon, 27 Oct 2003 17:10:56 -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: Logotypes in X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-12.txt
	Pages		: 23
	Date		: 2003-10-24
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [email-masked]
mailing list.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-logotypes-12.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-logotypes-12.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-logotypes-12.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-12.txt
Date: Mon, 27 Oct 2003 09:18:38 -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: Logotypes in X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-12.txt
	Pages		: 23
	Date		: 2003-10-24
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [email-masked]
mailing list.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-logotypes-12.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-logotypes-12.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-logotypes-12.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-12.txt
Date: Mon, 27 Oct 2003 09:18:35 -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: Logotypes in X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-12.txt
	Pages		: 23
	Date		: 2003-10-24
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [email-masked]
mailing list.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-logotypes-12.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-logotypes-12.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-logotypes-12.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 27 Oct 2003 09:37:04 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'Warranty Certificate Extension' to  Informational RFC
Sender: [email-masked]

Russ,

It is normal that your own "mail archive does not show any message to the 
IESG regarding this document" since the e-mail was NOT sent to you directly 
since the original message said:

"send any comments to the [email-masked] or [email-masked]"

So my message was sent to these both addresses in due time, with a copy to 
the PKIX co-chairs.

Denis

> The message below was sent to the PKIX mail list, and it clearly 
> indicates that the document was submitted to the IESG by the chairs.  
> And, it clearly asks for comments to be sent to the IESG.  My mail 
> archive does not show any message from you to the IESG regarding this 
> document.
> 
> Russ
> 
>> To: IETF-Announce: ;
>> Cc: [email-masked]
>> From: The IESG <[email-masked]>
>> Subject: Last Call: 'Internet X.509 Public Key Infrastructure Warranty
>>          Certificate Extension' to Informational RFC
>> Reply-To: [email-masked]
>> Date: Tue, 12 Aug 2003 14:44:07 -0400
>> Sender: [email-masked]
>>
>> The IESG has received a request from the Public-Key Infrastructure 
>> (X.509)
>> WG to consider 'Internet X.509 Public Key Infrastructure Warranty
>> Certificate Extension' <draft-ietf-pkix-warranty-extn-03.txt> as an
>> Informational RFC.
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send any comments to the
>> [email-masked] or [email-masked] mailing lists by 2003-08-26.
>>
>>
>> File(s) can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-03.txt
> 
> 
> 

Date: Sun, 26 Oct 2003 11:36:51 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

Oops, now I understand the scenario Steve Hanna was referring to:
   1. Subject CA picks it's own AKI using a computation
      technique, assuming issing CAs will use the same value
      for SKI (as they should).
   2. Issuing CA issues a cross-cert with an SKI using a different
      computation technique, blindly assuming that subject CA will
      take what he has been given to use as AKI as if subject were
      a child in issuer's hierarchy.

Sorry, Steve for my rant.  A working system has to have a common
set of assumptions, such as SKIs flow from the top down (works only
for hierarchies), or SKIs flow from the subject CAs to the issuers
(works in any topology), or every CA uses the same SKI computation
technique (works in any topology).  I didn't consider the situation
where the issuing CA and subject CA operate using different concepts
of who does what to whom.  Thanks, Stefan, for pointing out that
some CAs that were designed for use only in hierarchies are being
misused to issue cross certificates.

Dave

Stefan Santesson wrote:

> The problem is that RFC 3280 in practice require a CA, issuing a CA
> certs, to ask the subordinate CA for its preferred SKI rather than
> generating it.
> 
> To my knowledge there is no CA software that has implemented that
> behavior. If I'm not wrong they are all counting on that subordinate CAs
> will adopt the SKI generated by the parent CA, as the AKI placed in
> issued certs.
> 
> This works for strict hierarchical structures but not for generic cross
> certification (such as Bridge CA) unless CAs use the same SKI generation
> algorithm.
> 
> /Stefan
>  
> 
> 
>>-----Original Message-----
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of David P. Kemp
>>Sent: den 25 oktober 2003 00:54
>>To: [email-masked]
>>Subject: Re: AKI and SKI problem with RFC 3280?
>>
>>
>>Santosh,
>>
>>I agree that Section 4.2.1.2 of 3280 unambiguously states
>>that an "issuing CA" that does not populate SKI with the value
>>of AKI used by the "subject CA" is not compliant.
>>
>>It appeared that Steve Hanna was referring to non-3280-compliant
>>CAs, where
>>   "the CA certificate may have been issued by a CA that uses
>>    a different AKI/SKI computation technique than the CA
>>    who's the subject of the CA certificate."
>>
>>A compliant "subject CA" may have an AKI computation technique,
>>but a compliant "issuing CA" must not have an SKI computation
>>technique for CA certs - it must import the subject CA's AKI.
>>
>>Outside the realm of 3280 compliance, where the situation
>>of N different SKIs might occur and AKI/SKI don't necessarily
>>chain, the chaining problem occurs when two issuing CAs use
>>two different computation techniques to assign SKIs to the
>>subject, *not* when the issuing CA uses a different technique
>>than the subject CA.  The subject CA's techniques for choosing
>>an AKI for itself and SKIs to go in its issued certs is
>>completely irrelevant.
>>
>>Dave
>>
>>
>>Santosh Chokhani wrote:
>>
>>>David:
>>>
>>>Some of us are interpreting 3280 (specifically Section
> 
> 4.2.1.2,Subject
> 
>>Key
>>
>>>Identifier) to state that all N SKI should be the same and match the
> 
> AKI
> 
>>>used by the subject CA in the certificates it issues.  If not, the
> 
> CAs
> 
>>that
>>
>>>do not populate the
>>>SKI, may not be RFC 3280 compliant.
>>>
>>>Thus, your suggestion of the subject CA using one of the SKI is a
> 
> more
> 
>>>liberal interpretation of 3280 and is covered by our interpretation
> 
> of
> 
>>3280.
>>
>>>At the risk of being redundant, if all CAs are 3280 compliant all N
> 
> SKI
> 
>>in N
>>
>>>certificates issued to a CA for the same SPKI X == AKI in all
>>
>>certificates
>>
>>>signed by the CA, where the signature can be verified using X
>>>
>>>-----Original Message-----
>>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On
>>
>>>Behalf Of David P. Kemp
>>>Sent: Friday, October 24, 2003 12:19 PM
>>>To: [email-masked]
>>>Subject: Re: AKI and SKI problem with RFC 3280?
>>>
>>>
>>>
>>>Isn't the raison d'etre of AKI/SKI to allow a verifier
>>>to select the correct CA cert when multiple certs of the
>>>same issuer with different public keys are available
>>>(i.e. during rollover)?
>>>
>>>A CA may use any computation technique to populate the
>>>SKI of certs that it issues, but it MUST chain its own
>>>SKI into the AKI of certs that it issues.  Otherwise
>>>what's the point of populating AKI at all?
>>>
>>>The reason AKI/SKI chaining MUST NOT be enforced during
>>>path validation is because one CA could have one
>>>signing public key identified by N different SKIs
>>>in N different certs. (That's a bad thang, and cross-certificates
> 
> should
> 
>>>follow precedent rather than using a different SKI for the same
> 
> public
> 
>>key.)
>>
>>>But the CA MUST choose one of it's N SKIs to use as AKI, not make up
>>
>>some
>>
>>>different N+1th value. If it picks one of the N, then AKI is helpful
>>
>>1/Nth
>>
>>>of the time.  If it picks something else, then AKI can never be
> 
> helpful.
> 
>>>Dave
>>>
>>>
>>>Steve Hanna wrote:
>>>
>>>
>>>
>>>>Note also that AKI/SKI chaining SHOULD NOT be checked
>>>>during path validation. To be more explicit, it's
>>>>NOT true that the SKI of a CA certificate must match
>>>>the AKI of a certificate signed by that CA. Why?
>>>>Because the CA certificate may have been issued by
>>>>a CA that uses a different AKI/SKI computation technique
>>>>than the CA who's the subject of the CA certificate.
>>>
>>>
>>>
>>>
> 
> 

Date: Sun, 26 Oct 2003 10:43:44 -0500
From: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

Hi Stefan,

Someone (sorry, I looked back through this thread but couldn't find it) 
said "we all know what's right; the question is what do real products do 
about it?"  In this instance, doing it the way real products do it is 
not useful, and a standard has no choice but to stand up for what's right.

Saying "this CA behavior works for hierarchies but not for meshes" is 
equivalent to saying "the AKI/SKI extensions work for hierarchies but 
not for meshes".  It is theoretically impossible for AKI/SKI to work 
reliably (i.e. 100% of the time instead of 1/N of the time) unless all 
CAs that issue CA certs implement chaining.

For the first subject CA cert there are two timing options: either the 
subject CA first picks its own AKI and issues some certs and then the 
issuing CA imports subject's SKI, or the issuing CA picks SKI first and 
then subject CA uses it for AKI.  But for all remaining subject CA certs 
(cross-certs) there is only one useful option - use the subject's 
existing AKI as SKI.  The cross-certifying CAs must either use subject's 
AKI or they must issue the cross-cert without an SKI extension; the 
third option of picking an SKI using some computation technique other 
than the one already used for the subject CA is a worthless and 
misleading waste of bits - it can cause RPs to discard valid paths 
(potentially the only valid path for that RP) during path construction.

I vote for keeping 3280 the way it is.  But if it is changed, it should 
say conforming CAs MUST NOT populate SKI unless they do it as specified 
in 4.2.1.2.  Fixing every CA is surely easier than "fixing" every 
application to do path construction by checking signatures, including 
even paths with the wrong SKIs.

Dave

Stefan Santesson wrote:
> The problem is that RFC 3280 in practice require a CA, issuing a CA
> certs, to ask the subordinate CA for its preferred SKI rather than
> generating it.
> 
> To my knowledge there is no CA software that has implemented that
> behavior. If I'm not wrong they are all counting on that subordinate CAs
> will adopt the SKI generated by the parent CA, as the AKI placed in
> issued certs.
> 
> This works for strict hierarchical structures but not for generic cross
> certification (such as Bridge CA) unless CAs use the same SKI generation
> algorithm.
> 
> /Stefan
>  
> 
> 
>>-----Original Message-----
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of David P. Kemp
>>Sent: den 25 oktober 2003 00:54
>>To: [email-masked]
>>Subject: Re: AKI and SKI problem with RFC 3280?
>>
>>
>>Santosh,
>>
>>I agree that Section 4.2.1.2 of 3280 unambiguously states
>>that an "issuing CA" that does not populate SKI with the value
>>of AKI used by the "subject CA" is not compliant.
>>
>>It appeared that Steve Hanna was referring to non-3280-compliant
>>CAs, where
>>   "the CA certificate may have been issued by a CA that uses
>>    a different AKI/SKI computation technique than the CA
>>    who's the subject of the CA certificate."
>>
>>A compliant "subject CA" may have an AKI computation technique,
>>but a compliant "issuing CA" must not have an SKI computation
>>technique for CA certs - it must import the subject CA's AKI.
>>
>>Outside the realm of 3280 compliance, where the situation
>>of N different SKIs might occur and AKI/SKI don't necessarily
>>chain, the chaining problem occurs when two issuing CAs use
>>two different computation techniques to assign SKIs to the
>>subject, *not* when the issuing CA uses a different technique
>>than the subject CA.  The subject CA's techniques for choosing
>>an AKI for itself and SKIs to go in its issued certs is
>>completely irrelevant.
>>
>>Dave
>>
>>
>>Santosh Chokhani wrote:
>>
>>>David:
>>>
>>>Some of us are interpreting 3280 (specifically Section
> 
> 4.2.1.2,Subject
> 
>>Key
>>
>>>Identifier) to state that all N SKI should be the same and match the
> 
> AKI
> 
>>>used by the subject CA in the certificates it issues.  If not, the
> 
> CAs
> 
>>that
>>
>>>do not populate the
>>>SKI, may not be RFC 3280 compliant.
>>>
>>>Thus, your suggestion of the subject CA using one of the SKI is a
> 
> more
> 
>>>liberal interpretation of 3280 and is covered by our interpretation
> 
> of
> 
>>3280.
>>
>>>At the risk of being redundant, if all CAs are 3280 compliant all N
> 
> SKI
> 
>>in N
>>
>>>certificates issued to a CA for the same SPKI X == AKI in all
>>
>>certificates
>>
>>>signed by the CA, where the signature can be verified using X
>>>
>>>-----Original Message-----
>>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On
>>
>>>Behalf Of David P. Kemp
>>>Sent: Friday, October 24, 2003 12:19 PM
>>>To: [email-masked]
>>>Subject: Re: AKI and SKI problem with RFC 3280?
>>>
>>>
>>>
>>>Isn't the raison d'etre of AKI/SKI to allow a verifier
>>>to select the correct CA cert when multiple certs of the
>>>same issuer with different public keys are available
>>>(i.e. during rollover)?
>>>
>>>A CA may use any computation technique to populate the
>>>SKI of certs that it issues, but it MUST chain its own
>>>SKI into the AKI of certs that it issues.  Otherwise
>>>what's the point of populating AKI at all?
>>>
>>>The reason AKI/SKI chaining MUST NOT be enforced during
>>>path validation is because one CA could have one
>>>signing public key identified by N different SKIs
>>>in N different certs. (That's a bad thang, and cross-certificates
> 
> should
> 
>>>follow precedent rather than using a different SKI for the same
> 
> public
> 
>>key.)
>>
>>>But the CA MUST choose one of it's N SKIs to use as AKI, not make up
>>
>>some
>>
>>>different N+1th value. If it picks one of the N, then AKI is helpful
>>
>>1/Nth
>>
>>>of the time.  If it picks something else, then AKI can never be
> 
> helpful.
> 
>>>Dave
>>>
>>>
>>>Steve Hanna wrote:
>>>
>>>
>>>
>>>>Note also that AKI/SKI chaining SHOULD NOT be checked
>>>>during path validation. To be more explicit, it's
>>>>NOT true that the SKI of a CA certificate must match
>>>>the AKI of a certificate signed by that CA. Why?
>>>>Because the CA certificate may have been issued by
>>>>a CA that uses a different AKI/SKI computation technique
>>>>than the CA who's the subject of the CA certificate.
>>>
>>>
>>>
>>>
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Sun, 26 Oct 2003 10:03:34 -0500
Importance: Normal
Sender: [email-masked]

David:

The problem of different CAs populating different SKI is the reason path
development by the relying parties should not require AKI/SKI match, but
rather use AKI/SKI match as a prioritization or weighting function.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David P. Kemp
Sent: Friday, October 24, 2003 6:54 PM
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?

Santosh,

I agree that Section 4.2.1.2 of 3280 unambiguously states
that an "issuing CA" that does not populate SKI with the value of AKI used
by the "subject CA" is not compliant.

It appeared that Steve Hanna was referring to non-3280-compliant CAs, where
   "the CA certificate may have been issued by a CA that uses
    a different AKI/SKI computation technique than the CA
    who's the subject of the CA certificate."

A compliant "subject CA" may have an AKI computation technique, but a
compliant "issuing CA" must not have an SKI computation technique for CA
certs - it must import the subject CA's AKI.

Outside the realm of 3280 compliance, where the situation
of N different SKIs might occur and AKI/SKI don't necessarily chain, the
chaining problem occurs when two issuing CAs use two different computation
techniques to assign SKIs to the subject, *not* when the issuing CA uses a
different technique than the subject CA.  The subject CA's techniques for
choosing an AKI for itself and SKIs to go in its issued certs is completely
irrelevant.

Dave

Santosh Chokhani wrote:
> David:
> 
> Some of us are interpreting 3280 (specifically Section 4.2.1.2,Subject 
> Key
> Identifier) to state that all N SKI should be the same and match the AKI
> used by the subject CA in the certificates it issues.  If not, the CAs
that
> do not populate the 
> SKI, may not be RFC 3280 compliant.
> 
> Thus, your suggestion of the subject CA using one of the SKI is a more 
> liberal interpretation of 3280 and is covered by our interpretation of 
> 3280. At the risk of being redundant, if all CAs are 3280 compliant 
> all N SKI in N certificates issued to a CA for the same SPKI X == AKI 
> in all certificates signed by the CA, where the signature can be 
> verified using X
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David P. Kemp
> Sent: Friday, October 24, 2003 12:19 PM
> To: [email-masked]
> Subject: Re: AKI and SKI problem with RFC 3280?
> 
> 
> 
> Isn't the raison d'etre of AKI/SKI to allow a verifier
> to select the correct CA cert when multiple certs of the
> same issuer with different public keys are available
> (i.e. during rollover)?
> 
> A CA may use any computation technique to populate the
> SKI of certs that it issues, but it MUST chain its own
> SKI into the AKI of certs that it issues.  Otherwise
> what's the point of populating AKI at all?
> 
> The reason AKI/SKI chaining MUST NOT be enforced during
> path validation is because one CA could have one
> signing public key identified by N different SKIs
> in N different certs. (That's a bad thang, and cross-certificates 
> should follow precedent rather than using a different SKI for the same 
> public key.) But the CA MUST choose one of it's N SKIs to use as AKI, 
> not make up some different N+1th value. If it picks one of the N, then 
> AKI is helpful 1/Nth of the time.  If it picks something else, then 
> AKI can never be helpful.
> 
> Dave
> 
> 
> Steve Hanna wrote:
> 
> 
>>Note also that AKI/SKI chaining SHOULD NOT be checked
>>during path validation. To be more explicit, it's
>>NOT true that the SKI of a CA certificate must match
>>the AKI of a certificate signed by that CA. Why?
>>Because the CA certificate may have been issued by
>>a CA that uses a different AKI/SKI computation technique
>>than the CA who's the subject of the CA certificate.
> 
> 
> 
> 

From: Gregory Lebovitz <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: BOF: pki4ipsec
Date: Sat, 25 Oct 2003 16:06:10 -0700
Sender: [email-masked]

Folks,
As IPsec working group is finishing up its chartered work, some of the
works-in-progress have been moved to other or new WGs. The effort of
profiling the use of PKI for IPsec is one such effort.

We will start with a BOF in MN. Details below.

Profiling Use of PKI in IPSEC BOF (pki4ipsec)

Thursday, November 13 at 0900-1130
==================================

Full charter and mail list info at:
  http://www.icsalabs.com/pki4ipsec

We are looking forward to your participation!

Gregory Lebovitz (Co-chair)

Content-class: urn:content-classes:message
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Sat, 25 Oct 2003 18:41:23 +0100
From: "Stefan Santesson" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

The problem is that RFC 3280 in practice require a CA, issuing a CA
certs, to ask the subordinate CA for its preferred SKI rather than
generating it.

To my knowledge there is no CA software that has implemented that
behavior. If I'm not wrong they are all counting on that subordinate CAs
will adopt the SKI generated by the parent CA, as the AKI placed in
issued certs.

This works for strict hierarchical structures but not for generic cross
certification (such as Bridge CA) unless CAs use the same SKI generation
algorithm.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of David P. Kemp
> Sent: den 25 oktober 2003 00:54
> To: [email-masked]
> Subject: Re: AKI and SKI problem with RFC 3280?
> 
> 
> Santosh,
> 
> I agree that Section 4.2.1.2 of 3280 unambiguously states
> that an "issuing CA" that does not populate SKI with the value
> of AKI used by the "subject CA" is not compliant.
> 
> It appeared that Steve Hanna was referring to non-3280-compliant
> CAs, where
>    "the CA certificate may have been issued by a CA that uses
>     a different AKI/SKI computation technique than the CA
>     who's the subject of the CA certificate."
> 
> A compliant "subject CA" may have an AKI computation technique,
> but a compliant "issuing CA" must not have an SKI computation
> technique for CA certs - it must import the subject CA's AKI.
> 
> Outside the realm of 3280 compliance, where the situation
> of N different SKIs might occur and AKI/SKI don't necessarily
> chain, the chaining problem occurs when two issuing CAs use
> two different computation techniques to assign SKIs to the
> subject, *not* when the issuing CA uses a different technique
> than the subject CA.  The subject CA's techniques for choosing
> an AKI for itself and SKIs to go in its issued certs is
> completely irrelevant.
> 
> Dave
> 
> 
> Santosh Chokhani wrote:
> > David:
> >
> > Some of us are interpreting 3280 (specifically Section
4.2.1.2,Subject
> Key
> > Identifier) to state that all N SKI should be the same and match the
AKI
> > used by the subject CA in the certificates it issues.  If not, the
CAs
> that
> > do not populate the
> > SKI, may not be RFC 3280 compliant.
> >
> > Thus, your suggestion of the subject CA using one of the SKI is a
more
> > liberal interpretation of 3280 and is covered by our interpretation
of
> 3280.
> > At the risk of being redundant, if all CAs are 3280 compliant all N
SKI
> in N
> > certificates issued to a CA for the same SPKI X == AKI in all
> certificates
> > signed by the CA, where the signature can be verified using X
> >
> > -----Original Message-----
> > From: [email-masked]
[mailto:[email-masked]]
> On
> > Behalf Of David P. Kemp
> > Sent: Friday, October 24, 2003 12:19 PM
> > To: [email-masked]
> > Subject: Re: AKI and SKI problem with RFC 3280?
> >
> >
> >
> > Isn't the raison d'etre of AKI/SKI to allow a verifier
> > to select the correct CA cert when multiple certs of the
> > same issuer with different public keys are available
> > (i.e. during rollover)?
> >
> > A CA may use any computation technique to populate the
> > SKI of certs that it issues, but it MUST chain its own
> > SKI into the AKI of certs that it issues.  Otherwise
> > what's the point of populating AKI at all?
> >
> > The reason AKI/SKI chaining MUST NOT be enforced during
> > path validation is because one CA could have one
> > signing public key identified by N different SKIs
> > in N different certs. (That's a bad thang, and cross-certificates
should
> > follow precedent rather than using a different SKI for the same
public
> key.)
> > But the CA MUST choose one of it's N SKIs to use as AKI, not make up
> some
> > different N+1th value. If it picks one of the N, then AKI is helpful
> 1/Nth
> > of the time.  If it picks something else, then AKI can never be
helpful.
> >
> > Dave
> >
> >
> > Steve Hanna wrote:
> >
> >
> >>Note also that AKI/SKI chaining SHOULD NOT be checked
> >>during path validation. To be more explicit, it's
> >>NOT true that the SKI of a CA certificate must match
> >>the AKI of a certificate signed by that CA. Why?
> >>Because the CA certificate may have been issued by
> >>a CA that uses a different AKI/SKI computation technique
> >>than the CA who's the subject of the CA certificate.
> >
> >
> >
> >
> 

Date: Fri, 24 Oct 2003 18:53:53 -0400
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

Santosh,

I agree that Section 4.2.1.2 of 3280 unambiguously states
that an "issuing CA" that does not populate SKI with the value
of AKI used by the "subject CA" is not compliant.

It appeared that Steve Hanna was referring to non-3280-compliant
CAs, where
   "the CA certificate may have been issued by a CA that uses
    a different AKI/SKI computation technique than the CA
    who's the subject of the CA certificate."

A compliant "subject CA" may have an AKI computation technique,
but a compliant "issuing CA" must not have an SKI computation
technique for CA certs - it must import the subject CA's AKI.

Outside the realm of 3280 compliance, where the situation
of N different SKIs might occur and AKI/SKI don't necessarily
chain, the chaining problem occurs when two issuing CAs use
two different computation techniques to assign SKIs to the
subject, *not* when the issuing CA uses a different technique
than the subject CA.  The subject CA's techniques for choosing
an AKI for itself and SKIs to go in its issued certs is
completely irrelevant.

Dave

Santosh Chokhani wrote:
> David:
> 
> Some of us are interpreting 3280 (specifically Section 4.2.1.2,Subject Key
> Identifier) to state that all N SKI should be the same and match the AKI
> used by the subject CA in the certificates it issues.  If not, the CAs that
> do not populate the 
> SKI, may not be RFC 3280 compliant.
> 
> Thus, your suggestion of the subject CA using one of the SKI is a more
> liberal interpretation of 3280 and is covered by our interpretation of 3280.
> At the risk of being redundant, if all CAs are 3280 compliant all N SKI in N
> certificates issued to a CA for the same SPKI X == AKI in all certificates
> signed by the CA, where the signature can be verified using X
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of David P. Kemp
> Sent: Friday, October 24, 2003 12:19 PM
> To: [email-masked]
> Subject: Re: AKI and SKI problem with RFC 3280?
> 
> 
> 
> Isn't the raison d'etre of AKI/SKI to allow a verifier
> to select the correct CA cert when multiple certs of the
> same issuer with different public keys are available
> (i.e. during rollover)?
> 
> A CA may use any computation technique to populate the
> SKI of certs that it issues, but it MUST chain its own
> SKI into the AKI of certs that it issues.  Otherwise
> what's the point of populating AKI at all?
> 
> The reason AKI/SKI chaining MUST NOT be enforced during
> path validation is because one CA could have one
> signing public key identified by N different SKIs
> in N different certs. (That's a bad thang, and cross-certificates should
> follow precedent rather than using a different SKI for the same public key.)
> But the CA MUST choose one of it's N SKIs to use as AKI, not make up some
> different N+1th value. If it picks one of the N, then AKI is helpful 1/Nth
> of the time.  If it picks something else, then AKI can never be helpful.
> 
> Dave
> 
> 
> Steve Hanna wrote:
> 
> 
>>Note also that AKI/SKI chaining SHOULD NOT be checked
>>during path validation. To be more explicit, it's
>>NOT true that the SKI of a CA certificate must match
>>the AKI of a certificate signed by that CA. Why?
>>Because the CA certificate may have been issued by
>>a CA that uses a different AKI/SKI computation technique
>>than the CA who's the subject of the CA certificate.
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Fri, 24 Oct 2003 16:21:48 -0400
Importance: Normal
Sender: [email-masked]

David:

Some of us are interpreting 3280 (specifically Section 4.2.1.2,Subject Key
Identifier) to state that all N SKI should be the same and match the AKI
used by the subject CA in the certificates it issues.  If not, the CAs that
do not populate the 
SKI, may not be RFC 3280 compliant.

Thus, your suggestion of the subject CA using one of the SKI is a more
liberal interpretation of 3280 and is covered by our interpretation of 3280.
At the risk of being redundant, if all CAs are 3280 compliant all N SKI in N
certificates issued to a CA for the same SPKI X == AKI in all certificates
signed by the CA, where the signature can be verified using X

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David P. Kemp
Sent: Friday, October 24, 2003 12:19 PM
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?

Isn't the raison d'etre of AKI/SKI to allow a verifier
to select the correct CA cert when multiple certs of the
same issuer with different public keys are available
(i.e. during rollover)?

A CA may use any computation technique to populate the
SKI of certs that it issues, but it MUST chain its own
SKI into the AKI of certs that it issues.  Otherwise
what's the point of populating AKI at all?

The reason AKI/SKI chaining MUST NOT be enforced during
path validation is because one CA could have one
signing public key identified by N different SKIs
in N different certs. (That's a bad thang, and cross-certificates should
follow precedent rather than using a different SKI for the same public key.)
But the CA MUST choose one of it's N SKIs to use as AKI, not make up some
different N+1th value. If it picks one of the N, then AKI is helpful 1/Nth
of the time.  If it picks something else, then AKI can never be helpful.

Dave

Steve Hanna wrote:

> Note also that AKI/SKI chaining SHOULD NOT be checked
> during path validation. To be more explicit, it's
> NOT true that the SKI of a CA certificate must match
> the AKI of a certificate signed by that CA. Why?
> Because the CA certificate may have been issued by
> a CA that uses a different AKI/SKI computation technique
> than the CA who's the subject of the CA certificate.

Date: Fri, 24 Oct 2003 19:17:36 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

Steve Hanna wrote:

>Some CA software (or maybe just CAs as
>operated) apparently doesn't allow the certificate
>subject to specify what SKI it wants. 
>
Really I'd be surprised  if this was indeed a software limitation.
So who here distribute a CA products that can not be configured to 
attribute the correct SKI to a sub-CA certificate ?
Of course we're talking here about sub-CA and not end-entity certificates.
I don't expect to see certificates for CA delivered from an automatic 
process that can not be tuned, but I could be wrong for some cases of 
cross-certificates.

It would be really good to know if the problem met in interoperability 
tests were due to :
- insufficient attention given to this subject by the CA operator.
- actual limitation of some rarer CA software
- actual limitation of a significant number of popular CA software

I have met at least one product that did not offer a way to copy it 
automatically.
But the key ceremony required to create such a certificate already 
included a one page long description of every single tidbit that would 
go inside the certificate, so adding the exact value of the SKI in case 
it could not be created with one the standard algorithms would have been 
no great deal.

Date: Fri, 24 Oct 2003 12:18:33 -0400
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

Isn't the raison d'etre of AKI/SKI to allow a verifier
to select the correct CA cert when multiple certs of the
same issuer with different public keys are available
(i.e. during rollover)?

A CA may use any computation technique to populate the
SKI of certs that it issues, but it MUST chain its own
SKI into the AKI of certs that it issues.  Otherwise
what's the point of populating AKI at all?

The reason AKI/SKI chaining MUST NOT be enforced during
path validation is because one CA could have one
signing public key identified by N different SKIs
in N different certs. (That's a bad thang, and
cross-certificates should follow precedent rather
than using a different SKI for the same public key.)
But the CA MUST choose one of it's N SKIs
to use as AKI, not make up some different N+1th value.
If it picks one of the N, then AKI is helpful 1/Nth
of the time.  If it picks something else, then AKI
can never be helpful.

Dave

Steve Hanna wrote:

> Note also that AKI/SKI chaining SHOULD NOT be checked
> during path validation. To be more explicit, it's
> NOT true that the SKI of a CA certificate must match
> the AKI of a certificate signed by that CA. Why?
> Because the CA certificate may have been issued by
> a CA that uses a different AKI/SKI computation technique
> than the CA who's the subject of the CA certificate.

Date: Fri, 24 Oct 2003 10:19:39 -0400
From: Steve Hanna <[email-masked]>
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms855FA98D4191FBC87A6A82DF
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

I'll try Peter Gutmann's technique of responding to
several messages at once to reduce the number of messages.

Stefan Santesson wrote:
> And may I also suggest limiting recommendations to
> key identifiers derived from the key hash, unless
> there is a strong need for other solutions not yet
> presented in this debate.

Yes, I think there is universal agreement that
"a monotonically increasing sequence of integers"
SHOULD NOT be used for AKI/SKI. I'd be glad to
see such a recommendation added to the successor
to RFC 3280.

L Williams wrote:
> I think what this thread established was that sane CAs
> should be able to respect existing key identifiers when
> they do cross-certification/bridging. This means that
> AKI/SKI chaining should work the majority of the time,
> not fail the majority of the time. Seems to me that the
> change would be to make this a "SHOULD" not a "SHOULD NOT".

Which SHOULD are you talking about? I suspect you mean
my comment "relying parties SHOULD NOT require AKI/SKI
matching." If so, why do you think that relying parties
SHOULD require AKI/SKI matching? There's no security
benefit to doing so and some significant downsides, as
noted below.

Sharon Boeyen wrote:
> Shouldn't a CA determine what its own key identifier is
> (and 3280 recommends ways to calulate it). Once they have
> their own key id, this value should go into the AKI extension
> of all certificates issued by that CA and should go into
> the SKI extension of all certificates issued to that CA.

I agree that's best. However, it doesn't always work
out that way. Some CA software (or maybe just CAs as
operated) apparently doesn't allow the certificate
subject to specify what SKI it wants. Also, consider
the case where a CA decides to change its AKI (as when
moving away from monotonically increasing integers).
It would be nice to gradually transition from the old
AKI to the new one (without requiring all certificates
to and from the CA to be reissued simultaneously).

I agree with Santosh's earlier comment. We should stick with
the current RFC 3280 statements that CAs MUST use an
SKI in each CA certificate they issue that matches the
AKI used by the subject of the certificate. And we
should add a statement (explicitly stating what was already
implicit) saying that relying parties SHOULD NOT require
this match. It's only a hint for path building.

While I'm at it, I'll respond to one more comment:

Michael Ströder wrote:
> Is there any good reason to set AKI/SKI at all?

Some path building software uses it as a hint to
choose between several certs that look suitable.
Personally, I don't see a big win. As Peter points
out, subject and issuer names are a more reliable
mechanism. They *must* match or the path isn't valid.

Unfortunately, I have heard that some path building
software uses AKI/SKI as a database key and only
finds a path if they match. I've also heard that
some path validation software requires a match.
Both of those are mistakes. What a bummer for the
users! And all the more reason why the successor to
RFC 3280 should be explicit in saying that relying
parties SHOULD NOT require an AKI/SKI match.

So I think AKI/SKI have *some* utility

Thanks,

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

--------------ms855FA98D4191FBC87A6A82DF--

Date: Fri, 24 Oct 2003 08:23:02 -0400
From: [email-masked]
To: [email-masked]
Subject: Agenda Requests
Sender: [email-masked]

Folks,

I am working out the agenda for the PKIX meeting at Minneapolis; my goal is to 
post the draft agenda on Monday.

Please let me know if you would like space on the agenda.  Preference as always 
goes to presentation of PKIX documents and related IETF work.  Time *may* allow 
for a few "liasion" presentations regarding non-IETF work.

Thanks,

Tim Polk

Date: Thu, 23 Oct 2003 10:58:26 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Last Call: 'Warranty Certificate Extension' to Informational RFC 
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

The message below was sent to the PKIX mail list, and it clearly indicates 
that the document was submitted to the IESG by the chairs.  And, it clearly 
asks for comments to be sent to the IESG.  My mail archive does not show 
any message from you to the IESG regarding this document.

Russ

>To: IETF-Announce: ;
>Cc: [email-masked]
>From: The IESG <[email-masked]>
>Subject: Last Call: 'Internet X.509 Public Key Infrastructure Warranty
>          Certificate Extension' to Informational RFC
>Reply-To: [email-masked]
>Date: Tue, 12 Aug 2003 14:44:07 -0400
>Sender: [email-masked]
>
>The IESG has received a request from the Public-Key Infrastructure (X.509)
>WG to consider 'Internet X.509 Public Key Infrastructure Warranty
>Certificate Extension' <draft-ietf-pkix-warranty-extn-03.txt> as an
>Informational RFC.
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by 2003-08-26.
> 
>
>File(s) can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-03.txt

Date: Thu, 23 Oct 2003 14:17:22 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Tim Polk <[email-masked]>, Stephen Kent <[email-masked]>, Russ Housley <[email-masked]>, Steve Bellovin <[email-masked]>
CC: Alice Sturgeon <[email-masked]>, [email-masked], pkix <[email-masked]>
Subject: Re: Last Call: 'Warranty Certificate Extension' to Informational RFC
Sender: [email-masked]

On August 26, I sent a reply to the last call sent by the IESG on 
draft-ietf-pkix-warranty-extn-03.txt. It is copied below. Since then, 
nothing happened officially.

I met with Alice Sturgeon yesterday in Paris and we had a talk together. She 
told me that she has also been surprised to see the IESG last call, since 
she was ready to post a new draft 04 to answer my comments. Since she saw 
the IESG last call, she abstained to post it.

Since then, she received comments from the IESG and she needs to post a new 
draft.

I would appreciate if the situation could be clarified either by the 
Security Area Directors or by the PKIX co-chairs.

Denis

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

>> The IESG has received a request from the Public-Key Infrastructure 
>> (X.509) WG to consider 'Internet X.509 Public Key Infrastructure 
>> Warranty Certificate Extension' <draft-ietf-pkix-warranty-extn-03.txt> 
>> as an Informational RFC.

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

> I am quite surprised to see that the IESG received a request from the 
> PKIX chairs while a discussion still takes place on the PKIX mailing 
> list on the document.
> 
> The last response from the lead editor (Alice Sturgeon) is dated August 
> 13. She recognizes that at least some "clarifications" are needed.
> 
> The e-mail is duplicated below and exhibits that there is good progress 
> but still no consensus on the document.
> 
> At least some changes to the June version (version 3) are expected 
> before the document can be published.
> 
> Regards,
> 
> Denis
> 
> Note: I am back from holidays, just today (i.e. August 26 th).
> 
> =============================================================================== 
> 
> 
> Hello Denis,
> 
> Please see my comments inserted below, as [AS2], to distinguish from the 
> first set of replies to your original comments.
> 
> Alice
> 
> Alice Sturgeon
> Chair, Canadian Advisory Committee - Information Technology Security
> ISO/IEC JTC 1/SC 27
> and
> System Policy Architect & Manager of Standards
> SPYRUS
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Tuesday, July 29, 2003 6:38 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
> 
> 
> 
> Alice,
> 
> Please see my responses below.
> 
> Comments on warranty-extn-03.txt (June 2003)
> 
> 1- On page 2. The text mentions: "A relying party that has a warranty 
> from a
> CA".
> 
> Does this mean that a relying party must have a contract with the CA to get
> advantage of the warranty ?
> [Alice] No.
> 
> Does this mean that a relying party will get a warranty without a contract
> signed with the CA ?
> [Alice] Yes.
> 
> Does this extension allow to make the difference between the case of a
> signed contract and the case of an unsigned contract where the guarantees
> could be different?
> 
> [Alice] No. If there are any differences in the T&C pertaining to a
> contractual arrangement, these differences will be outside of, beyond the
> scope, and not pertinent to, the warranty offered in the certificate.  It
> applies equally to all relying parties, whether or not a contract has been
> signed.
> 
> [Denis] Then say something like: "Whether or not relying parties have 
> signed
> agreements with CAs, the CA will provide Terms and Conditions for this
> warranty which relates to its liability."
> 
> [AS2] Alternatively, to make the same point, it could remain implicit.
> 
> 2 - The difference between the base warranty and the extended warranty is
> not crystal clear.
> 
> How can a relying party know whether it can have the benefits of the base
> warranty or of the extended warranty ?
> 
> If the extended warranty is present, then the relying party has the benefit
> of the extended warranty.  In short, if it is present, then the relying
> party knows that the relying party has the benefit of the extended warranty
> by its presence alone.  The syntax shows that the extended warranty MAY be
> present:
>   Warranty ::= CHOICE  {
>         none                 NULL,            -- No warranty provided
>         wData                WarrantyData  }  -- Explicit warranty
> 
>     WarrantyData ::= SEQUENCE  {
>         base                 WarrantyInfo,
>         extended             WarrantyInfo OPTIONAL,
>         tcURL                TermsAndConditionsURL OPTIONAL  }
> 
> If the tcURL is present, a human being might understand the terms and
> conditions (if he can understand the local language used), but a computer
> program will not be able to do so. This means that computers cannot
> understand the difference.
> 
> [Alice] The computer does not need to know what is in the T&C.  If the 
> tcURL
> is present, it is optionally for the benefit of the human reader. Perhaps
> you could suggest some text to clarify this in the I-D if you still 
> think it
> is needed.
> 
> [Denis] Then say something like: "Warranty extensions are only aimed for
> human interpretation and contain data that is inappropriate for computer
> based verification schemes, the warranty extension MUST NOT be an active
> component in automated certification path validation."
> 
> [AS2] But this is not necessarily true. It may be that the RP (i.e., the 
> human) has to go to a T&C document if the extended warranty is present, 
> if the RP wants to know what exactly is in the T&C, but there should be 
> the option of not going to the T&C.  If the extended warranty is not 
> present (as noted in the syntax, it is optional), then there is no 
> reason that the extension could not be processed by the computer. 
> Therefore, the warranty extension is NOT "only aimed for human 
> interpretation...".  This may be irrelevant to the point of automated 
> certificate path validation, because the extension is non-critical.
> 
> 3 - There is no security on the information placed at the tcURL parameter
> since no hash of the terms and conditions is being used. These conditions
> could change overtime and relying parties would not be able to demonstrate
> that they have changed.
> 
> [Alice]
> It seems to me that the time stamp on the certificate would suffice to 
> place
> the warranty in a point of time at which the specified terms and conditions
> applied; there is no need for the extension to demonstrate that as this is
> covered by the certificate itself.  This is no different from the
> paper-based world in that if an insurance policy changes its terms, it
> cannot do so retroactively to the detriment of clients who have paid for a
> specific coverage, unless it notified the clients and compensates them
> accordingly.
> 
> [Denis] The problem is that the CA could change the policy and the relying
> party will be unable to demonstrate that the policy has changed. A
> time-stamp token over the certificate would not help. A time-stamp token
> over the T&C would help, but the relying party does not necessarily have
> access to one TSU. The hash approach is much simpler.
> 
> [AS2] A hash function on the T&C?
> 
> 4 - Is the "Relying party Agreement" a document to signed by the parties or
> not ? This should be said.
> 
> [Alice]
> Use of the term "Relying Party Agreement" is no different from its normal
> usage, just as "Certificate Policy" is used in the same context without any
> change to the meaning from normal usage, as per RFC 2527 and its successor.
> In other words, defining the terms, either Relying Party Agreement or
> Certificate Policy is not necessary to the understanding of this extension.
> 
> [Denis] The term "Relying Party Agreement" is confusing. Use a wording like
> "Terms and Conditions for Relying parties" which does not imply that there
> is an agreement signed but that unilaterally the CA provides terms and
> conditions. Relying parties may like them or not. If they disagree with
> them, then this is still "Terms and Conditions for Relying parties".
> 
> [AS2] Maybe so, but the RP has the option of not using or relying on the 
> certificate. As I said before, this is normal terminology, and should 
> not be confusing; it is not being used with a different meaning.
> 
> 5 - The WarrantyValidityPeriod is insufficient. Usually there is a 
> period to
> claim for a compensation which must be made X months or Y days after the
> date of the event which created the damage. It is thus not possible to ask
> for a warranty during e.g. the whole validity period of the certificate.
> Another time period parameter is missing.
> 
> [Alice]
> This is exactly what the validity period is stating: that the warranty is
> valid for a specified time, which is either the validity period of the
> certificate, or another, specified time using the parameters as defined in
> the I-D.  It is presented and offered this way, so there is no need for
> another validity parameter.  If an offeror wanted to specify a time within
> which claims could be made, then a shorter time period than the validity of
> the certificate can be used.  This is unlike the paper-based world in the
> sense that insurance policies are normally of long duration, whereas this
> extension is associated with a certificate that normally has a validity of
> two-three years.
> 
> [Denis] The semantics of the warranty validity period is not defined ! 
> There
> is a need to define more precisely what "the warranty validity period" is.
> Here is a proposal along my original text. If it does not fit, please
> propose an alternative:
> 
> " The warranty validity period is a time period to claim for a compensation
> which must be made X months or Y days after the date of the event which
> created the damage. It is unrelated to the certificate validity period."
> 
> [AS2] What if the warranty validity period is indeed the same as the 
> certificate validity period? This was the scenario assumed to be most 
> likely, as it is stated in s.2.2, and therefore the option was created 
> to allow for a reduction in size of the extension by having NULL in 
> warranty validity period in the case where it was the same as the 
> certificate validity period.  When it is not the same as the certificate 
> validity period, then the parameters available for warranty validity 
> period can be used.
> 
> 6 - The wType offers only two types of warranty: aggregated and per
> transaction.
> 
> "Aggregated" means that that once the value of the fulfilled claims reaches
> the maximum warranty amount, then no further claim will be fulfilled.
> 
> "Per transaction" means that each claim is handled independently but no
> individual claim can exceed the maximum warranty amount.
> 
> Each type has its own problems:
> 
> "Aggregated" is like a race where late claimants will get no 
> compensation at
> all because they were not "fast enough". It is questionable whether such a
> race condition will be acceptable.
> It should be understood that aggregation applies to one warranty and one
> claimant.  This is analogous to the paper-based world.  When you are 
> covered
> by warranty for X product or service, e.g., health insurance, there is 
> often
> an upper limit (viz. the "value") up to which claims will be met for each
> claimant; i.e., one insured person.
> "Per transaction" means that the CA cannot compute the maximum amount of
> money that it may have to give away. Which insurance company will ever
> insure a risk for which an upper limit cannot be computed ?
> 
> [Alice]
> The T&C, as noted in section 1, as covered by insurance, will specify the
> maximum. The type of warranty selected depends on the nature of the
> transactions, the parties to the transactions (e.g., individuals, large
> institutions, etc.).
> 
> [Denis] What I am asking for is to allow a combination of both types, which
> is currently not possible. See below again.
> 
> None of these schemes is acceptable. Some combination should be allowed:
> 
>    - a maximum amount per transaction, and
>    - a maximum amount per certificate with a maximum time period
>      to claim for a compensation after the date of the event
>      (no race problem implied).
> 
> [AS2] You have a good point. We may need some clarification in s.2.2 to 
> explain exactly what the currency amount means.  This is clearly stated 
> (and obvious) with respect to aggregate, but not so with 
> per-transaction.  It should be indicated that there will be a maximum 
> total of per-transaction claims, which would be standard practice, and 
> necessary for the ongoing health of the CA.  The total warranty offered 
> for per-transaction claims could be expressed as a new parameter 
> indicating number of per-transaction claims before the maximum would br 
> reached, which would be simple to calculate since the per-transaction 
> maximum is stated; e.g., a sub-line after the per-transaction type code, 
> number of transactions as a maximum.
> 
> 7 - The content of the security consideration should be augmented to
> indicate the difference between what a computer program can do and a human
> being can do with this extension.
> 
> [Alice]
> I would have thought this to be blindingly obvious.  We would, however, be
> quite willing to consider some proposed words to address this, if you do
> think it is necessary.
> 
> [Denis] If my text proposal related to comment 2 is inserted, then this is
> no more needed.
> 
> [AS2] Still willing to consider a proposal, but as you can see from my 
> response to your comments on point 2, I don't think this is quite right.
> 
> 8 - The document is not mature enough and its added value is still
> questionable.
> 
> [Alice]
> We believe that it is mature.  Its value may be questionable to those 
> who do
> not want to use it, but given that it is (a) proposed as Informational and
> (b) always non-critical, surely its availability for use is innocuous for
> those that do not want to use it.  For those who do want to use it, and we
> have heard from quite a number who do, it will be useful and valuable.  As
> in section 1: "When a certificate contains a warranty certificate 
> extension,
> the extension MUST be non-critical, ..."
> 
> [Denis]
> As you can see, we have progressed, but several issues still need to be
> addressed.
> 
> [AS2] Yes, we have made progress.
> 
> Denis
> 
> 
>> File(s) can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-03.txt
>>
> 
> 

Date: Thu, 23 Oct 2003 16:38:36 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

I'll reply briefly to several messages at once here to keep the message count
down...

"Stefan Santesson" <[email-masked]> writes:

>If an application use AKI/SKI match to discover a path and finds an AKI/SKI
>match of unrelated keys. What happens? Ignoring what applications SHOULD do
>(which we all know) What is in fact the current behaviour of applications
>today:

I match first on DNs and only if that fails do I fall back to keyIDs (provided
the keyID is > 40 bits, i.e. not a non-unique small integer).  I'm not aware
of the match on DNs ever having failed.  It's one of these things that users
just know about (sort of like "Don't user Master Documents in MS Word" or
"Don't change the monitor frequency settings in XF86Config"), you can either
play it safe and know it'll work or live dangerously but have to expect things
to break.  If you expect things to break anyway then presumably you're
prepared to do the necessary manual tweaking to sort things out.  An easier
option for most people is just to make sure that you never put yourself in a
situation where things can break.

=?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]> writes:

>Or is it just YAPEB [1]?
>
>[1] yet another PKIX extension bloat

In my earlier message I originally had a tongue-in-cheek comment that the
purpose of the keyIDs was for the CA to communicate to a RP that it didn't
consider the certificate bloated enough, but I removed it before I sent the
message.

"Al Arsenault" <[email-masked]> writes:

>So, your assertion is that a bastardized hybrid of a widely-used but non-
>standard protocol (SCEP)

I was waiting for someone to bring that up :-).  I'd considered just putting
in a blank space in place of the term "SCEP" in my post in reference to the
PKIX NIH effect blanking it out.

>with an updated wrapping mechanism (CMS) will cause problems for some types
>of signature validation software, and this is a reason why one option
>permitted by PKIX is a fundamental flaw?

You asked for an example, that's a quick example (the reason SCEP uses PKCS #7
is because that's what Cisco had lying around when they created it.  I'm sure
any even vaguely recent SCEP implementation will be built with a CMS toolkit).
In any case it was just a top-of-my-head example (I'm not going to search
through every case of CMS use to see how many would be affected by this, it's
used in all sorts of weird and wonderful places), the point is that if the
spec allows this behaviour then it's broken.

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

>Do cross-certifying CA discards all extensions inside the request so that
>it's not possible to specify the SKID by including it as an extension inside
>the request ?

My code copies all extensions across (although the CA app is free to delete
any that it doesn't like).  Feedback from users was that if they didn't want
it in the request they wouldn't be specifying it, and conversely if they did
specify it then they didn't want the CA arbitrarily stripping it out.

All manner of people wrote:

>[ Six angels! / Four angels! / Eight angels! / No angels! / A dachshund! ]

The general response to this issue has been some variation of "Users will get
it right" (= push it onto the users) / "It's a policy issue" (= push it onto
the users) / "It's a local configuration issue" (= push it onto the users).
If the PKI experts can't even agree on how to interpret/handle this, how on
earth can non-technical users be expected to get it right?

I'll conclude with a wonderful quote from someone else (who probably doesn't
want his name mentioned :-).  It's in reference to the UK comedy "Father Ted":

  Ted says that whenever he gets asked a religious question he doesn't
  understand he always responds with "Ah, that must be an ecumenical matter"
  which univerally produces nods of admiration at the profound wisdom of the
  statement. It seems that that the PKIX list equivalent is "Ah that must be a
  policy matter".

Peter.

From: "L Williams" <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>, <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 19:08:15 -0700
Importance: Normal
Sender: [email-masked]

Man, I was loving this thread up until this point.

I think what this thread established was that sane CAs should be able to
respect existing key identifiers when they do cross-certification/bridging.
This means that AKI/SKI chaining should work the majority of the time, not
fail the majority of the time. Seems to me that the change would be to make
this a "SHOULD" not a "SHOULD NOT".

Yes, there are backwards compatibility issues, but this can be dealt with.

-Laudon
(Microsoft)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Steve Hanna
Sent: Wednesday, October 22, 2003 1:59 PM
To: Peter Hesse
Cc: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?

Maybe we are close to ending this discussion. Everyone
agrees that CAs MUST use an SKI in CA certificates that
matches the AKI used in certificates issued by the
subject of the certificate. Relying parties can use
this as a hint during path construction, but they should
not require AKI/SKI matching during path construction or
path validation.

But RFC 3280 does not say clearly and explicitly that
relying parties should not require AKI/SKI matching.
Several implementors have misunderstood this. I suggest
that the successor to RFC 3280 should be changed to
make an explicit recommendation that relying parties
SHOULD NOT require AKI/SKI matching.

Thanks,

Steve

Peter Hesse wrote:
> 
> Santosh,
> 
> Point taken.  3280 therefore requires that the keyIdentifier method (as
> opposed to the issuer DN/serial tuple) MUST be used.  In 4.2.1.1 (AKID)
> it only RECOMMENDS this; but the words you quote from 4.2.1.2 (SKID)
> make it a requirement, intentionally or not.  As you said, in the below
> case, at least one CA is not compliant with 3280.  Unfortunately, I've
> seen this happen in practice.  As you said earlier, it would be best if
> path building implementations could be flexible about this, but
> certificate producers should be compliant.
> 
> Two other things: Sharon is dead on, and the only thing I would say is
> that support for accepting SKIDs in certification requests seems to work
> well with a particular implementation, but require manual input or is
> not possible between different implementations.
> 
> And Jean-Marc was also quite correct, my example was wrong.  It's the
> Issuer's Issuer DN and serial, I just put the Issuer's DN in my example.
> Shame on me.
> 
> --Peter
> 
> +---------------------------------------------------------------+
> | Peter Hesse                    [email-masked]     |
> | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> | ICQ: 1942828                     www.geminisecurity.com       |
> +---------------------------------------------------------------+
> "Pay no attention to what the critics say; there has never been
> a statue set up in honor of a critic." --Jean Sibelius
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: Wednesday, October 22, 2003 2:01 PM
> To: [email-masked]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> Peter:
> 
> Section 4.2.1.2 (Subject Key Identifier) of 3280 states and I quote:
> "The value of the subject key identifier MUST be the value placed in the
> key identifier field of the Authority Key Identifier extension (section
> 4.2.1.1) of certificates issued by the subject of this certificate."
> Read in context, the above is stated for CA certificates.
> 
> Thus, in cross certified environment, 3280 compliant issuing CAs need to
> ensure that the SKI in 3280 compliant subject CA certificate is the
> value that the subject CA intends to use as AKI for certificates it
> issues.
> 
> If the AKI and SKI (even for cross certified environments) do not chain,
> one or more of the CAs is not compliant with 3280.
> 
> -----Original Message-----
> From: Peter Hesse [mailto:[email-masked]]
> Sent: Wednesday, October 22, 2003 12:59 PM
> To: 'Santosh Chokhani'; [email-masked]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> Santosh Chokhani wrote:
> > My e-mail needs to be read in the context of the producers. The CAs as
> 
> > producers need to ensure that the AKI and SKI chain. If the CAs do not
> 
> > do that, they are not compliant with 3280.
> > That means in order to comply with 3280 issuing CA needs to
> > honor the SKID requested by the subject CAs.
> 
> I think we're in violent agreement.  My main point was that although the
> producer needs to ensure that AKID and SKID chain, cross-PKI
> interoperability will cause cases in which the producer must choose
> between two (or more) equally valid AKIDs to place in a subject
> certificate.  Either of them will chain successfully and the producer
> will be compliant; but as a result there will be valid paths where the
> AKID and SKID will not chain, through no fault of the producer.
> 
> --Peter

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 19:19:03 -0400
Importance: Normal
Sender: [email-masked]

Sharon:

I agree.  What you listed is the simplest way to meet the requirement.

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2003 3:46 PM
To: 'Peter Hesse'; 'Santosh Chokhani'; [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?

Now I'm getting confused???

To simplify the discussion....

Shouldn't a CA determine what its own key identifier is (and 3280 recommends
ways to calulate it). One they have their own key id, this value should  
go into the AKI extension of all certificates issued by that CA and should
go 
into the SKI extension of all certificates issued to that CA. When acting 
as the issuer, the CA knows the value and simply populates it. When acting
as 
the subject, the CA should pass the value in the certificate request it
sends 
to the issuing CA and that value should be used by the issuing CA to
populate 
the SKI. If the value is not sent in the cert request, then the issuer CA
needs 
to use other means to determine the correct value for that SKI.

-----Original Message-----
From: Peter Hesse [mailto:[email-masked]]
Sent: Wednesday, October 22, 2003 12:59 PM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?

Santosh Chokhani wrote:
> My e-mail needs to be read in the context of the producers.
> The CAs as producers need to ensure that the AKI and SKI chain.
> If the CAs do not do that, they are not compliant with 3280.  
> That means in order to comply with 3280 issuing CA needs to 
> honor the SKID requested by the subject CAs.

I think we're in violent agreement.  My main point was that although the
producer needs to ensure that AKID and SKID chain, cross-PKI
interoperability will cause cases in which the producer must choose between
two (or more) equally valid AKIDs to place in a subject certificate.  Either
of them will chain successfully and the producer will be compliant; but as a
result there will be valid paths where the AKID and SKID will not chain,
through no fault of the producer.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

Content-class: urn:content-classes:message
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 23:27:57 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Steve Hanna" <[email-masked]>, "Peter Hesse" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Agree,

And may I also suggest limiting recommendations to key identifiers
derived from the key hash, unless there is a strong need for other
solutions not yet presented in this debate.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Steve Hanna
> Sent: den 22 oktober 2003 22:59
> To: Peter Hesse
> Cc: [email-masked]
> Subject: Re: AKI and SKI problem with RFC 3280?
> 
> Maybe we are close to ending this discussion. Everyone
> agrees that CAs MUST use an SKI in CA certificates that
> matches the AKI used in certificates issued by the
> subject of the certificate. Relying parties can use
> this as a hint during path construction, but they should
> not require AKI/SKI matching during path construction or
> path validation.
> 
> But RFC 3280 does not say clearly and explicitly that
> relying parties should not require AKI/SKI matching.
> Several implementors have misunderstood this. I suggest
> that the successor to RFC 3280 should be changed to
> make an explicit recommendation that relying parties
> SHOULD NOT require AKI/SKI matching.
> 
> Thanks,
> 
> Steve
> 
> Peter Hesse wrote:
> >
> > Santosh,
> >
> > Point taken.  3280 therefore requires that the keyIdentifier method
(as
> > opposed to the issuer DN/serial tuple) MUST be used.  In 4.2.1.1
(AKID)
> > it only RECOMMENDS this; but the words you quote from 4.2.1.2 (SKID)
> > make it a requirement, intentionally or not.  As you said, in the
below
> > case, at least one CA is not compliant with 3280.  Unfortunately,
I've
> > seen this happen in practice.  As you said earlier, it would be best
if
> > path building implementations could be flexible about this, but
> > certificate producers should be compliant.
> >
> > Two other things: Sharon is dead on, and the only thing I would say
is
> > that support for accepting SKIDs in certification requests seems to
work
> > well with a particular implementation, but require manual input or
is
> > not possible between different implementations.
> >
> > And Jean-Marc was also quite correct, my example was wrong.  It's
the
> > Issuer's Issuer DN and serial, I just put the Issuer's DN in my
example.
> > Shame on me.
> >
> > --Peter
> >
> > +---------------------------------------------------------------+
> > | Peter Hesse                    [email-masked]     |
> > | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> > | ICQ: 1942828                     www.geminisecurity.com       |
> > +---------------------------------------------------------------+
> > "Pay no attention to what the critics say; there has never been
> > a statue set up in honor of a critic." --Jean Sibelius
> >
> > -----Original Message-----
> > From: [email-masked]
[mailto:[email-masked]]
> > On Behalf Of Santosh Chokhani
> > Sent: Wednesday, October 22, 2003 2:01 PM
> > To: [email-masked]
> > Subject: RE: AKI and SKI problem with RFC 3280?
> >
> > Peter:
> >
> > Section 4.2.1.2 (Subject Key Identifier) of 3280 states and I quote:
> > "The value of the subject key identifier MUST be the value placed in
the
> > key identifier field of the Authority Key Identifier extension
(section
> > 4.2.1.1) of certificates issued by the subject of this certificate."
> > Read in context, the above is stated for CA certificates.
> >
> > Thus, in cross certified environment, 3280 compliant issuing CAs
need to
> > ensure that the SKI in 3280 compliant subject CA certificate is the
> > value that the subject CA intends to use as AKI for certificates it
> > issues.
> >
> > If the AKI and SKI (even for cross certified environments) do not
chain,
> > one or more of the CAs is not compliant with 3280.
> >
> > -----Original Message-----
> > From: Peter Hesse [mailto:[email-masked]]
> > Sent: Wednesday, October 22, 2003 12:59 PM
> > To: 'Santosh Chokhani'; [email-masked]
> > Subject: RE: AKI and SKI problem with RFC 3280?
> >
> > Santosh Chokhani wrote:
> > > My e-mail needs to be read in the context of the producers. The
CAs as
> >
> > > producers need to ensure that the AKI and SKI chain. If the CAs do
not
> >
> > > do that, they are not compliant with 3280.
> > > That means in order to comply with 3280 issuing CA needs to
> > > honor the SKID requested by the subject CAs.
> >
> > I think we're in violent agreement.  My main point was that although
the
> > producer needs to ensure that AKID and SKID chain, cross-PKI
> > interoperability will cause cases in which the producer must choose
> > between two (or more) equally valid AKIDs to place in a subject
> > certificate.  Either of them will chain successfully and the
producer
> > will be compliant; but as a result there will be valid paths where
the
> > AKID and SKID will not chain, through no fault of the producer.
> >
> > --Peter

Date: Wed, 22 Oct 2003 16:58:57 -0400
From: Steve Hanna <[email-masked]>
To: Peter Hesse <[email-masked]>
CC: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms1A4950776C601A796E2B43DF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Maybe we are close to ending this discussion. Everyone
agrees that CAs MUST use an SKI in CA certificates that
matches the AKI used in certificates issued by the
subject of the certificate. Relying parties can use
this as a hint during path construction, but they should
not require AKI/SKI matching during path construction or
path validation.

But RFC 3280 does not say clearly and explicitly that
relying parties should not require AKI/SKI matching.
Several implementors have misunderstood this. I suggest
that the successor to RFC 3280 should be changed to
make an explicit recommendation that relying parties
SHOULD NOT require AKI/SKI matching.

Thanks,

Steve

Peter Hesse wrote:
> 
> Santosh,
> 
> Point taken.  3280 therefore requires that the keyIdentifier method (as
> opposed to the issuer DN/serial tuple) MUST be used.  In 4.2.1.1 (AKID)
> it only RECOMMENDS this; but the words you quote from 4.2.1.2 (SKID)
> make it a requirement, intentionally or not.  As you said, in the below
> case, at least one CA is not compliant with 3280.  Unfortunately, I've
> seen this happen in practice.  As you said earlier, it would be best if
> path building implementations could be flexible about this, but
> certificate producers should be compliant.
> 
> Two other things: Sharon is dead on, and the only thing I would say is
> that support for accepting SKIDs in certification requests seems to work
> well with a particular implementation, but require manual input or is
> not possible between different implementations.
> 
> And Jean-Marc was also quite correct, my example was wrong.  It's the
> Issuer's Issuer DN and serial, I just put the Issuer's DN in my example.
> Shame on me.
> 
> --Peter
> 
> +---------------------------------------------------------------+
> | Peter Hesse                    [email-masked]     |
> | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> | ICQ: 1942828                     www.geminisecurity.com       |
> +---------------------------------------------------------------+
> "Pay no attention to what the critics say; there has never been
> a statue set up in honor of a critic." --Jean Sibelius
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: Wednesday, October 22, 2003 2:01 PM
> To: [email-masked]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> Peter:
> 
> Section 4.2.1.2 (Subject Key Identifier) of 3280 states and I quote:
> "The value of the subject key identifier MUST be the value placed in the
> key identifier field of the Authority Key Identifier extension (section
> 4.2.1.1) of certificates issued by the subject of this certificate."
> Read in context, the above is stated for CA certificates.
> 
> Thus, in cross certified environment, 3280 compliant issuing CAs need to
> ensure that the SKI in 3280 compliant subject CA certificate is the
> value that the subject CA intends to use as AKI for certificates it
> issues.
> 
> If the AKI and SKI (even for cross certified environments) do not chain,
> one or more of the CAs is not compliant with 3280.
> 
> -----Original Message-----
> From: Peter Hesse [mailto:[email-masked]]
> Sent: Wednesday, October 22, 2003 12:59 PM
> To: 'Santosh Chokhani'; [email-masked]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> Santosh Chokhani wrote:
> > My e-mail needs to be read in the context of the producers. The CAs as
> 
> > producers need to ensure that the AKI and SKI chain. If the CAs do not
> 
> > do that, they are not compliant with 3280.
> > That means in order to comply with 3280 issuing CA needs to
> > honor the SKID requested by the subject CAs.
> 
> I think we're in violent agreement.  My main point was that although the
> producer needs to ensure that AKID and SKID chain, cross-PKI
> interoperability will cause cases in which the producer must choose
> between two (or more) equally valid AKIDs to place in a subject
> certificate.  Either of them will chain successfully and the producer
> will be compliant; but as a result there will be valid paths where the
> AKID and SKID will not chain, through no fault of the producer.
> 
> --Peter
--------------ms1A4950776C601A796E2B43DF
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms1A4950776C601A796E2B43DF--

From: "Florian Oelmaier" <[email-masked]>
To: "'Tom Gindin'" <[email-masked]>, "'Michael Myers'" <[email-masked]>
Cc: "'David Engberg'" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Wed, 22 Oct 2003 22:30:26 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> [...] The options were original (with unclear 
> semantics in this respect), nonce required in response, and 
> nonce optional in response.
> For a server to actually prevent misunderstandings of 
> whether or not he supports nonces by using a unilateral
> server-side extension, you'd need a server-side 
> extension called "nonceSupported" with boolean syntax, 
> which would have to be placed in EVERY response whether 
> nonces are present in the request or not.

Client side extension:
Good idea. I certainly support such an extension. One thing we should
keep in mind: currently ALL extensions in OCSP are OPTIONAL. We have to
make sure that the RfC does not contradict itself.

I fully support your server-side extension. Simple and good. I like it.

Both good ideas - lets go with them :)

-- 
Florian Oelmaier
SyTrust

From: "Peter Hesse" <[email-masked]>
To: <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 16:12:40 -0400
Organization: Gemini Security Solutions, Inc.
Importance: Normal
Sender: [email-masked]

Santosh,

Point taken.  3280 therefore requires that the keyIdentifier method (as
opposed to the issuer DN/serial tuple) MUST be used.  In 4.2.1.1 (AKID)
it only RECOMMENDS this; but the words you quote from 4.2.1.2 (SKID)
make it a requirement, intentionally or not.  As you said, in the below
case, at least one CA is not compliant with 3280.  Unfortunately, I've
seen this happen in practice.  As you said earlier, it would be best if
path building implementations could be flexible about this, but
certificate producers should be compliant.

Two other things: Sharon is dead on, and the only thing I would say is
that support for accepting SKIDs in certification requests seems to work
well with a particular implementation, but require manual input or is
not possible between different implementations.

And Jean-Marc was also quite correct, my example was wrong.  It's the
Issuer's Issuer DN and serial, I just put the Issuer's DN in my example.
Shame on me.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, October 22, 2003 2:01 PM
To: [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?

Peter:

Section 4.2.1.2 (Subject Key Identifier) of 3280 states and I quote:
"The value of the subject key identifier MUST be the value placed in the
key identifier field of the Authority Key Identifier extension (section
4.2.1.1) of certificates issued by the subject of this certificate."
Read in context, the above is stated for CA certificates.

Thus, in cross certified environment, 3280 compliant issuing CAs need to
ensure that the SKI in 3280 compliant subject CA certificate is the
value that the subject CA intends to use as AKI for certificates it
issues.

If the AKI and SKI (even for cross certified environments) do not chain,
one or more of the CAs is not compliant with 3280.

-----Original Message-----
From: Peter Hesse [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2003 12:59 PM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?

Santosh Chokhani wrote:
> My e-mail needs to be read in the context of the producers. The CAs as

> producers need to ensure that the AKI and SKI chain. If the CAs do not

> do that, they are not compliant with 3280.
> That means in order to comply with 3280 issuing CA needs to 
> honor the SKID requested by the subject CAs.

I think we're in violent agreement.  My main point was that although the
producer needs to ensure that AKID and SKID chain, cross-PKI
interoperability will cause cases in which the producer must choose
between two (or more) equally valid AKIDs to place in a subject
certificate.  Either of them will chain successfully and the producer
will be compliant; but as a result there will be valid paths where the
AKID and SKID will not chain, through no fault of the producer.

--Peter

From: Sharon Boeyen <[email-masked]>
To: "'Peter Hesse'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 15:45:46 -0400
Sender: [email-masked]

Now I'm getting confused???

To simplify the discussion....

Shouldn't a CA determine what its own key identifier is (and 3280 recommends
ways to calulate it). One they have their own key id, this value should  
go into the AKI extension of all certificates issued by that CA and should
go 
into the SKI extension of all certificates issued to that CA. When acting 
as the issuer, the CA knows the value and simply populates it. When acting
as 
the subject, the CA should pass the value in the certificate request it
sends 
to the issuing CA and that value should be used by the issuing CA to
populate 
the SKI. If the value is not sent in the cert request, then the issuer CA
needs 
to use other means to determine the correct value for that SKI.

-----Original Message-----
From: Peter Hesse [mailto:[email-masked]]
Sent: Wednesday, October 22, 2003 12:59 PM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?

Santosh Chokhani wrote:
> My e-mail needs to be read in the context of the producers.  
> The CAs as producers need to ensure that the AKI and SKI chain.
> If the CAs do not do that, they are not compliant with 3280.  
> That means in order to comply with 3280 issuing CA needs to 
> honor the SKID requested by the subject CAs.

I think we're in violent agreement.  My main point was that although the
producer needs to ensure that AKID and SKID chain, cross-PKI
interoperability will cause cases in which the producer must choose
between two (or more) equally valid AKIDs to place in a subject
certificate.  Either of them will chain successfully and the producer
will be compliant; but as a result there will be valid paths where the
AKID and SKID will not chain, through no fault of the producer.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 14:01:29 -0400
Importance: Normal
Sender: [email-masked]

Peter:

Section 4.2.1.2 (Subject Key Identifier) of 3280 states and I quote: "The
value of the subject key identifier MUST be the value placed in the key
identifier field of the Authority Key Identifier extension (section 4.2.1.1)
of certificates issued by the subject of this certificate."  Read in
context, the above is stated for CA certificates.

Thus, in cross certified environment, 3280 compliant issuing CAs need to
ensure that the SKI in 3280 compliant subject CA certificate is the value
that the subject CA intends to use as AKI for certificates it issues.

If the AKI and SKI (even for cross certified environments) do not chain, one
or more of the CAs is not compliant with 3280.

-----Original Message-----
From: Peter Hesse [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2003 12:59 PM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?

Santosh Chokhani wrote:
> My e-mail needs to be read in the context of the producers.
> The CAs as producers need to ensure that the AKI and SKI chain.
> If the CAs do not do that, they are not compliant with 3280.  
> That means in order to comply with 3280 issuing CA needs to 
> honor the SKID requested by the subject CAs.

I think we're in violent agreement.  My main point was that although the
producer needs to ensure that AKID and SKID chain, cross-PKI
interoperability will cause cases in which the producer must choose between
two (or more) equally valid AKIDs to place in a subject certificate.  Either
of them will chain successfully and the producer will be compliant; but as a
result there will be valid paths where the AKID and SKID will not chain,
through no fault of the producer.

--Peter

Date: Wed, 22 Oct 2003 19:11:34 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

Peter Hesse wrote:

>+------------------+                +--------------------+
>|  Allied Pilots   |                |     Boeing Root    |
>| Association Root |                |                    |
>|                  |                | SKID: Q            |
>| SKID: A          |                |                    |
>+------------------+                +--------------------+
>         \                                   /
>          \                                 /
>           V                               V
>    =================================================
>    | +-------------------+   +-------------------+ |
>    | | American Airlines |   | American Airlines | |
>    | |                   |   |                   | |
>    | | SN: 12345         |   | SN: 87654         | |
>    | | SKID: Z           |   | SKID: Z           | |
>    | | AKID: A           |   | AKID: Q           | |
>    | +-------------------+   +-------------------+ |
>    =================================================
>                            |
>                            |
>                            V
>                  +-------------------+
>                  |     Joe Pilot     |
>                  |                   |
>                  | SKID: W           |
>                  | AKID: "American   |
>                  |        Airlines,  |
>                  |        12345"     |
>                  +-------------------+
>  
>
This AKID is wrong. It should be "Allied Pilots Association Root, 12345".
This type of AKID is a issuer name/serial pair, this means pointing 
amongst the certificate emitted by ca IssuerName to the one that has the 
serial SN.
American Airlines certificate is the certificate SN:12345 amongst those 
issued by "Allied Pilots Association Root"

You certainly know about this, but this particular misinterpretation of 
AKID tends to be a recurrent problem, so I feel better not to leave it 
uncorrected.

Date: Wed, 22 Oct 2003 19:09:33 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

Peter Hesse wrote:

>Currently, there is no commonly accepted way to for a
>cross-certifying CA to accept the desired SKID in a request for
>cross-certification.
>
Why ?
Do cross-certifying CA discards all extensions inside the request so 
that it's not possible to specify the SKID by including it as an 
extension inside the request ?
But even when they do, then you need to specify all extensions to 
include by hand, so you could insert the correct SKID transported out of 
band, with the other info needed for that CA, wouldn't you ?

It would be interesting if I'm proven wrong, but it's seems to me 
cross-certifying doesn't happen everyday, and always involves some 
manual operations, so is there really a good reason why you can not do 
this customisation of the parameters ?

I just found a document from the pkiforum that endorses this method : 
http://www.pkiforum.org/pdfs/AKID_SKID1-af3.pdf
It also reports that both U.S. Federal Bridge CA and CESG 
interoperability initiatives reported mismatches preventing proper 
certification path construction.

From: "Peter Hesse" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 12:59:24 -0400
Organization: Gemini Security Solutions, Inc.
Importance: Normal
Sender: [email-masked]

Santosh Chokhani wrote:
> My e-mail needs to be read in the context of the producers.  
> The CAs as producers need to ensure that the AKI and SKI chain.
> If the CAs do not do that, they are not compliant with 3280.  
> That means in order to comply with 3280 issuing CA needs to 
> honor the SKID requested by the subject CAs.

I think we're in violent agreement.  My main point was that although the
producer needs to ensure that AKID and SKID chain, cross-PKI
interoperability will cause cases in which the producer must choose
between two (or more) equally valid AKIDs to place in a subject
certificate.  Either of them will chain successfully and the producer
will be compliant; but as a result there will be valid paths where the
AKID and SKID will not chain, through no fault of the producer.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

From: "Aisenberg, Michael" <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: The value of qualified certificates
Date: Wed, 22 Oct 2003 12:59:53 -0400
Sender: [email-masked]

As with any other corporate finance discussion, "valuation" is very
subjective and context- and purpose-driven. Having said that, one credible
indicator of valuation is the limit of any indemnification provided by the
certificate issuer.

 -----Original Message-----
From: 	Anders Rundgren
Sent:	Wed Oct 22 08:46:20 2003
To:	[email-masked]
Subject:	The value of qualified certificates

I'm wondering what the value of qualified certificates is,
when e-governments in country after country, buy certificates
from commercial CAs where each CA (or CA network) requires
a business contract with each RP.  As these contracts regulate
liabilities etc. it seems that the legal implications of qualified
certificates become limited or are eliminated.  What's left seems
to only be a certificate profile. I.e. a "format".  Among many such.

Just my 2 (EU) cents

Anders R

From: "Michael Myers" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: "David Engberg" <[email-masked]>, <[email-masked]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Wed, 22 Oct 2003 09:49:04 -0700
Importance: Normal
Sender: [email-masked]

Tom,

Your proposal certainly provides an opportunity for compromise.
But I think we first need to see what emerges from Minneapolis.

Mike

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: Wednesday, October 22, 2003 9:19 AM
> To: Michael Myers
> Cc: David Engberg; [email-masked]
> Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
>
>
>         Michael:
>
>         Does your skepticism about the usefulness of
> unilateral
> server-side extensions mean that we should permit a
> variant of nonce in
> which the client specifies how strongly he needs a
> nonce?  Since the
> current syntax of nonce is not officially published,
> I posted a possible
> extension several weeks ago.  The options were
> original (with unclear
> semantics in this respect), nonce required in
> response, and nonce optional
> in response.
>         For a server to actually prevent
> misunderstandings of whether or
> not he supports nonces by using a unilateral
> server-side extension, you'd
> need a server-side extension called "nonceSupported"
> with boolean syntax,
> which would have to be placed in EVERY response
> whether nonces are present
> in the request or not.  The "nonceUnsupported"
> extension strikes me as
> less useful than that.
>
>                 Tom Gindin
>

To: "Michael Myers" <[email-masked]>
Cc: "David Engberg" <[email-masked]>, [email-masked]
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
From: Tom Gindin <[email-masked]>
Date: Wed, 22 Oct 2003 12:19:20 -0400
Sender: [email-masked]

        Michael:

        Does your skepticism about the usefulness of unilateral 
server-side extensions mean that we should permit a variant of nonce in 
which the client specifies how strongly he needs a nonce?  Since the 
current syntax of nonce is not officially published, I posted a possible 
extension several weeks ago.  The options were original (with unclear 
semantics in this respect), nonce required in response, and nonce optional 
in response.
        For a server to actually prevent misunderstandings of whether or 
not he supports nonces by using a unilateral server-side extension, you'd 
need a server-side extension called "nonceSupported" with boolean syntax, 
which would have to be placed in EVERY response whether nonces are present 
in the request or not.  The "nonceUnsupported" extension strikes me as 
less useful than that.

                Tom Gindin

"Michael Myers" <[email-masked]>
Sent by: [email-masked]
10/18/2003 09:14 PM

        To:     "David Engberg" <[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: DISCUSSION: Nonce-specific error code for OCSP

Dave,

A few thoughts embedded below.

Mike

> -----Original Message-----
> From: David Engberg
>
> . . .
>
> An existing client can't tell the difference between a
> server that doesn't support nonces and a replay
> attack by an attacker who made a nonceless request.
> An explicit "nonceUnsupported" extension in the signed
> body of the response allows a client to securely tell the
> difference between these cases.

The requirement is to bind a request to its associated response
and thus enable relying parties to mitigate replay risks.  I
remain curious to an understanding of how unilateral server-side
response extensions achieve this effect.

> OCSP and other PKIX standards currently allow some
> policy decisions to be made by the infrastructure
> authorities (CAs, responders) and others by the
> relying parties.  For example, the pkix-nocheck
> extension allows the infrastructure to tell clients
> that they should accept a delegated responder cert
> without performing validation.  This extension was
> approved, even though someone could have made an
> argument that "only clients should be allowed to
> set responder validation policies."

In the instance of explicit delegation from a certification
authority, there then exists a business entity which places
itself in a position of risk against damage claims.  Are you
suggesting that an OCSP responder's unilateral inclusion of a
technical artifact is an assertion of willingness to absorb such
risks?

Bear in mind that the relying party problem is notoriously
difficult.  It only appears in the heterogeneous context we are
now debating; else contracts suffice.  If you are unfamiliar
with the issue, you may wish to consult with our legal peers in
the American Bar Association's Information Security Committee.

> Something like "nonceUnsupported" would fall in the
> same category ... the infrastructure is telling
> interested clients about the security characteristics
> of that PK infrastructure and suggesting a security
> policy based on that information.

Infrastructure should serve the needs of its participants rather
than the other way around.

Mike
(602) 739-7744

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 11:02:04 -0400
Importance: Normal
Sender: [email-masked]

Peter:

My e-mail needs to be read in the context of the producers.  The CAs as
producers need to ensure that the AKI and SKI chain.  If the CAs do not do
that, they are not compliant with 3280.  That means in order to comply with
3280 issuing CA needs to honor the SKID requested by the subject CAs.

The consumers, i.e., the relying parties should not enforce the AKI and SKI
chaining.  They can use the match as the prioritization during path
construction.

Forcing CAs to enforce the AKI and SKI match and not requiring the relying
parties to enforce it (but simply use as a prioritization) offers us the
best of both worlds in terms of enhancing interoperability.

As for algorithm for constructing the values, 3280 should and does provides
these as recommendations as opposed to SHALL or MUST.

-----Original Message-----
From: Peter Hesse [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2003 9:39 AM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?

Santosh,

> Based on a review of Sections 4.2.1.2 and 4.2.1.1 of
> 3280, I draw the following conclusion: A 3280 compliant
> CA MUST ensure that AKI and SKI chain properly.  This
> is sufficient for path construction.  Thus, I do not 
> see a particular need to change 3280 in this area.

I read this differently.  I agree that for a given CA, that CA must make
sure that for certificates it issues, the AKID and SKID must match. However,
when you add the "IssuerDN/Serial" tuple version of AKID, that can no longer
be true.  When you start interoperating across domains, there are times at
which AKID and SKID will not match, but yet it should lead to a valid path.
Consider the following example:

+------------------+                +--------------------+
|  Allied Pilots   |                |     Boeing Root    |
| Association Root |                |                    |
|                  |                | SKID: Q            |
| SKID: A          |                |                    |
+------------------+                +--------------------+
         \                                   /
          \                                 /
           V                               V
    =================================================
    | +-------------------+   +-------------------+ |
    | | American Airlines |   | American Airlines | |
    | |                   |   |                   | |
    | | SN: 12345         |   | SN: 87654         | |
    | | SKID: Z           |   | SKID: Z           | |
    | | AKID: A           |   | AKID: Q           | |
    | +-------------------+   +-------------------+ |
    =================================================
                            |
                            |
                            V
                  +-------------------+
                  |     Joe Pilot     |
                  |                   |
                  | SKID: W           |
                  | AKID: "American   |
                  |        Airlines,  |
                  |        12345"     |
                  +-------------------+

In our example, we have the "American Airlines" entity which has two
certificates, one issued by the Allied Pilots Association (AA's union) and
the other by Boeing (one of their manufacturers).  These two certificates
have the same public key and subject public key identifier, but different
serial numbers.  "American Airlines" issues a certificate to "Joe Pilot".
Although Joe Pilot's AKID points to the AA Root certificate issued by the
Allied Pilots Association, there is no reason why a path to the Boeing Root
should not be found equally acceptable.

The other thing at play was what Steve Hanna mentioned in an earlier
message.  Currently, there is no commonly accepted way to for a
cross-certifying CA to accept the desired SKID in a request for
cross-certification.  Therefore, many CAs  calculate their own SKID.  In
fact, look at this part of section 4.2.1.2 of RFC3280:

   For CA certificates, subject key identifiers SHOULD be 
   derived from the public key or a method that generates 
   unique values.

Here, 3280 is saying you should derive the SKID from the public key, it says
nothing about making use of any existing  key identifier that the CA is
putting as the AKID in certificates it issues.  But wait!  If you read down
a little further, you get: 

   Where a key identifier has not been previously 
   established, this specification RECOMMENDS use of one 
   of these methods for generating keyIdentifiers.  Where
   a key identifier has been previously established, the 
   CA SHOULD use the previously established identifier.

I see shoulds and recommends here, and not MUSTs.  Prior experience has
shown me that two CAs configured in different ways (or running different
software) may both derive the SKID from the public key in two different
fashions, and you can end up with the following:

+------------------+                +--------------------+
|  Allied Pilots   |                |     Boeing Root    |
| Association Root |                |                    |
|                  |                | SKID: Q            |
| SKID: A          |                |                    |
+------------------+                +--------------------+
         \                                   /
          \                                 /
           V                               V
    =================================================
    | +-------------------+   +-------------------+ |
    | | American Airlines |   | American Airlines | |
    | |                   |   |                   | |
    | | SN: 12345         |   | SN: 87654         | |
    | | SKID: Z           |   | SKID: F           | |
    | | AKID: A           |   | AKID: Q           | |
    | +-------------------+   +-------------------+ |
    =================================================
                            |
                            |
                            V
                  +-------------------+
                  |     Joe Pilot     |
                  |                   |
                  | SKID: W           |
                  | AKID: Z           |
                  +-------------------+

Although the public key has remained the same, American Airlines now has two
certificates with two different SKIDs but the same public key. Again, there
is no reason why a path from Joe Pilot to the Boeing Root should not be
valid.

From: "Peter Hesse" <[email-masked]>
To: "=?iso-8859-1?Q?'Michael_Str=F6der'?=" <[email-masked]>, <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 09:45:22 -0400
Organization: Gemini Security Solutions, Inc.
Importance: Normal
Sender: [email-masked]

Michael Ströder wrote:
> Steve Hanna wrote:
> > A decent MUA would understand that there may be more
> > than one cert with the same SKI. AKI/SKI is just a
> > hint.
>  > [..]
> > Note also that AKI/SKI chaining SHOULD NOT be checked
> > during path validation. To be more explicit, it's
> > NOT true that the SKI of a CA certificate must match
> > the AKI of a certificate signed by that CA.
> 
> Reading this discussion I ask myself:
> Is there any good reason to set AKI/SKI at all?
> Is it worth for anything?
> Or is it just YAPEB [1]?

Michael,

When a path-building implementation is building a path, and it comes
upon one subject with multiple certificates and is trying to determine
which one to use, AKID and SKID are useful, because if they match
properly, there is a high degree of confidence that the certificate(s)
with matching AKID/SKIDs is/are the correct certificate(s) to choose.

However, just because they do not match does not mean that there is no
"there" there.  The degree of confidence that it will lead to a valid
path is lessened somewhat, but there is still a chance that the path in
that direction will be valid.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

From: "Peter Hesse" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 09:38:44 -0400
Organization: Gemini Security Solutions, Inc.
Importance: Normal
Sender: [email-masked]

Santosh,

> Based on a review of Sections 4.2.1.2 and 4.2.1.1 of 
> 3280, I draw the following conclusion: A 3280 compliant
> CA MUST ensure that AKI and SKI chain properly.  This 
> is sufficient for path construction.  Thus, I do not 
> see a particular need to change 3280 in this area.

I read this differently.  I agree that for a given CA, that CA must make
sure that for certificates it issues, the AKID and SKID must match.
However, when you add the "IssuerDN/Serial" tuple version of AKID, that
can no longer be true.  When you start interoperating across domains,
there are times at which AKID and SKID will not match, but yet it should
lead to a valid path.  Consider the following example:

+------------------+                +--------------------+
|  Allied Pilots   |                |     Boeing Root    |
| Association Root |                |                    |
|                  |                | SKID: Q            |
| SKID: A          |                |                    |
+------------------+                +--------------------+
         \                                   /
          \                                 /
           V                               V
    =================================================
    | +-------------------+   +-------------------+ |
    | | American Airlines |   | American Airlines | |
    | |                   |   |                   | |
    | | SN: 12345         |   | SN: 87654         | |
    | | SKID: Z           |   | SKID: Z           | |
    | | AKID: A           |   | AKID: Q           | |
    | +-------------------+   +-------------------+ |
    =================================================
                            |
                            |
                            V
                  +-------------------+
                  |     Joe Pilot     |
                  |                   |
                  | SKID: W           |
                  | AKID: "American   |
                  |        Airlines,  |
                  |        12345"     |
                  +-------------------+

In our example, we have the "American Airlines" entity which has two
certificates, one issued by the Allied Pilots Association (AA's union)
and the other by Boeing (one of their manufacturers).  These two
certificates have the same public key and subject public key identifier,
but different serial numbers.  "American Airlines" issues a certificate
to "Joe Pilot".  Although Joe Pilot's AKID points to the AA Root
certificate issued by the Allied Pilots Association, there is no reason
why a path to the Boeing Root should not be found equally acceptable.

The other thing at play was what Steve Hanna mentioned in an earlier
message.  Currently, there is no commonly accepted way to for a
cross-certifying CA to accept the desired SKID in a request for
cross-certification.  Therefore, many CAs  calculate their own SKID.  In
fact, look at this part of section 4.2.1.2 of RFC3280:

   For CA certificates, subject key identifiers SHOULD be 
   derived from the public key or a method that generates 
   unique values.

Here, 3280 is saying you should derive the SKID from the public key, it
says nothing about making use of any existing  key identifier that the
CA is putting as the AKID in certificates it issues.  But wait!  If you
read down a little further, you get: 

   Where a key identifier has not been previously 
   established, this specification RECOMMENDS use of one 
   of these methods for generating keyIdentifiers.  Where
   a key identifier has been previously established, the 
   CA SHOULD use the previously established identifier.

I see shoulds and recommends here, and not MUSTs.  Prior experience has
shown me that two CAs configured in different ways (or running different
software) may both derive the SKID from the public key in two different
fashions, and you can end up with the following:

+------------------+                +--------------------+
|  Allied Pilots   |                |     Boeing Root    |
| Association Root |                |                    |
|                  |                | SKID: Q            |
| SKID: A          |                |                    |
+------------------+                +--------------------+
         \                                   /
          \                                 /
           V                               V
    =================================================
    | +-------------------+   +-------------------+ |
    | | American Airlines |   | American Airlines | |
    | |                   |   |                   | |
    | | SN: 12345         |   | SN: 87654         | |
    | | SKID: Z           |   | SKID: F           | |
    | | AKID: A           |   | AKID: Q           | |
    | +-------------------+   +-------------------+ |
    =================================================
                            |
                            |
                            V
                  +-------------------+
                  |     Joe Pilot     |
                  |                   |
                  | SKID: W           |
                  | AKID: Z           |
                  +-------------------+

Although the public key has remained the same, American Airlines now has
two certificates with two different SKIDs but the same public key.
Again, there is no reason why a path from Joe Pilot to the Boeing Root
should not be valid.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

Date: Wed, 22 Oct 2003 09:21:25 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 20:26 +1300 10/22/03, Peter Gutmann wrote:
>"Al Arsenault" <[email-masked]> writes:
>
>>Okay, it's only a SHOULD, not a MUST, but the scenario you reference below
>>only comes in to play if I signed the CMS message using my CA cert, not my
>>end-entity cert.
>>
>>Got an example where this is relevant if the sKID's of two different CA certs
>>are the same? 
>
>My CMS example from earlier used with SCEP.
>
>In any case something like this should never be allowed to happen as a matter
>of basic protocol design.  Creating a "unique" key ID and then specifically
>telling people they can use non-unique IDs is just asking for trouble.
>
>Peter.

Peter,

SCEP is not an IETF standard, and it sounds as if it's use of these 
extensions is not consistent with the guidance provided in 2459, and 
now in 3280. Whose fault is that?

Steve

Content-class: urn:content-classes:message
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 11:09:02 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I agree with Peter,

I think this is asking for trouble. That is my whole point.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Peter Gutmann
> Sent: den 22 oktober 2003 09:26
> To: [email-masked]; [email-masked]; [email-masked];
Stefan
> Santesson
> Cc: [email-masked]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> 
> "Al Arsenault" <[email-masked]> writes:
> 
> >Okay, it's only a SHOULD, not a MUST, but the scenario you reference
> below
> >only comes in to play if I signed the CMS message using my CA cert,
not
> my
> >end-entity cert.
> >
> >Got an example where this is relevant if the sKID's of two different
CA
> certs
> >are the same?
> 
> My CMS example from earlier used with SCEP.
> 
> In any case something like this should never be allowed to happen as a
> matter
> of basic protocol design.  Creating a "unique" key ID and then
> specifically
> telling people they can use non-unique IDs is just asking for trouble.
> 
> Peter.

Date: Wed, 22 Oct 2003 08:53:38 -0400
To: Michael =?iso-8859-1?Q?Str=F6der?=  <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: AKI and SKI problem with RFC 3280?
Cc: [email-masked]
Sender: [email-masked]

At 10:15 +0200 10/22/03, Michael Ströder wrote:
>Steve Hanna wrote:
>>A decent MUA would understand that there may be more
>>than one cert with the same SKI. AKI/SKI is just a
>>hint.
>  > [..]
>>Note also that AKI/SKI chaining SHOULD NOT be checked
>>during path validation. To be more explicit, it's
>>NOT true that the SKI of a CA certificate must match
>>the AKI of a certificate signed by that CA.
>
>Reading this discussion I ask myself:
>Is there any good reason to set AKI/SKI at all?
>Is it worth for anything?
>Or is it just YAPEB [1]?
>
>Ciao, Michael.
>
>[1] yet another PKIX extension bloat

Michael,

If you read 3280 and 2459, you'll note that the 
primary use of these extensions is to allow one 
to perform more efficient path discovery, by 
helping select the right cert when more than one 
(CA) cert matches based on Subject/Issuer 
relationship.  Most of the complaints I hear are 
a result form trying to misuse the AKI/SKI as a 
search key. It's inappropriate to complain about 
how poorly your screwdriver works as a cold 
chisel.

Steve

From: "Stefan Kelm" <[email-masked]>
Organization: Secorvo Security Consulting GmbH
To: "Anders Rundgren" <[email-masked]>, <[email-masked]>
Date: Wed, 22 Oct 2003 14:30:16 +0200
Subject: Re: The value of qualified certificates
Reply-to: [email-masked]
Content-description: Mail message body
Sender: [email-masked]

Anders,

> I'm wondering what the value of qualified certificates is,
> when e-governments in country after country, buy certificates
> from commercial CAs where each CA (or CA network) requires
> a business contract with each RP.  As these contracts regulate
> liabilities etc. it seems that the legal implications of qualified
> certificates become limited or are eliminated.  What's left seems
> to only be a certificate profile. I.e. a "format".  Among many such.

Good point.

In this regard you might want to have a look at a report titled "The 
Legal and Market Aspects of Electronic Signatures" which has been 
published by the European Commission only yesterday: 

http://europa.eu.int/information_society/eeurope/2005/index_en.htm  

Cheers,

	Stefan.
--------------------------------------------------------
http://www.Anti-Spam-Symposium.de  18.-19. November 2003
--------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de/
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

From: "Al Arsenault" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Wed, 22 Oct 2003 08:08:29 -0400
Importance: Normal
Sender: [email-masked]

Okay, now I'm *truly* confused.

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]]
Sent: Wednesday, October 22, 2003 3:26 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?

"Al Arsenault" <[email-masked]> writes:

>Okay, it's only a SHOULD, not a MUST, but the scenario you reference below
>only comes in to play if I signed the CMS message using my CA cert, not my
>end-entity cert.
>
>Got an example where this is relevant if the sKID's of two different CA
certs
>are the same?

My CMS example from earlier used with SCEP.

awa:> Um, the current spec for SCEP appears to be
http://www.ietf.org/internet-drafts/draft-nourse-scep-08.txt

awa:> From that, it appears that:

awa:>    (a) SCEP doesn't use CMS, it uses PKCS #7
awa:>    (b) SCEP doesn't support the use of sKID or aKID as an identifier
in the signerInfo, it's restricted to
	     issuerAndSerialNumber (which, oh-by-the-way, is not guaranteed to be
unique in the real world, since I can set up
		a CA of my own reusing an issuer name that's already out there :-)
awa:>    (c) this is only relevant when the certificate requester is
creating a self-signed "CA" cert for the purpose of establishing the
connection with the CA, anyway.

awa:> So, your assertion is that a bastardized hybrid of a widely-used but
non-standard protocol (SCEP) with an updated wrapping mechanism (CMS) will
cause problems for some types of signature validation software, and this is
a reason why one option permitted by PKIX is a fundamental flaw?

In any case something like this should never be allowed to happen as a
matter
of basic protocol design.  Creating a "unique" key ID and then specifically
telling people they can use non-unique IDs is just asking for trouble.

awa:> I don't have any great love for the "monotonically increasing integer
sequence" mechanism myself, particularly since we've had a number of
discussions about what "monotonically increasing" means (different sources
have different definitions; some definitions allow the repitition of numbers
as pointed out by Peter Sylvester).  All PKIs in which I've ever been
involved have either used the "low-order 60 bits of a SHA-1 hash" or the
"full SHA-1 hash". The bottom line, though, is that I think anybody who
builds cert validation software for a large, complex system with multiple
CA's, multiple extensions, etc., and who believes that "if the sKID matches,
I am guaranteed to have found the right certificate" is being somewhat
simple in his software design.

		Al Arsenault

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: The value of qualified certificates
Date: Wed, 22 Oct 2003 12:26:50 +0200
Sender: [email-masked]

I'm wondering what the value of qualified certificates is,
when e-governments in country after country, buy certificates
from commercial CAs where each CA (or CA network) requires
a business contract with each RP.  As these contracts regulate
liabilities etc. it seems that the legal implications of qualified
certificates become limited or are eliminated.  What's left seems
to only be a certificate profile. I.e. a "format".  Among many such.

Just my 2 (EU) cents

Anders R

Date: Wed, 22 Oct 2003 10:15:52 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

Steve Hanna wrote:
> A decent MUA would understand that there may be more
> than one cert with the same SKI. AKI/SKI is just a
> hint.
 > [..]
> Note also that AKI/SKI chaining SHOULD NOT be checked
> during path validation. To be more explicit, it's
> NOT true that the SKI of a CA certificate must match
> the AKI of a certificate signed by that CA.

Reading this discussion I ask myself:
Is there any good reason to set AKI/SKI at all?
Is it worth for anything?
Or is it just YAPEB [1]?

Ciao, Michael.

[1] yet another PKIX extension bloat

Date: Wed, 22 Oct 2003 20:26:17 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?
Cc: [email-masked]
Sender: [email-masked]

"Al Arsenault" <[email-masked]> writes:

>Okay, it's only a SHOULD, not a MUST, but the scenario you reference below
>only comes in to play if I signed the CMS message using my CA cert, not my
>end-entity cert.
>
>Got an example where this is relevant if the sKID's of two different CA certs
>are the same?  

My CMS example from earlier used with SCEP.

In any case something like this should never be allowed to happen as a matter
of basic protocol design.  Creating a "unique" key ID and then specifically
telling people they can use non-unique IDs is just asking for trouble.

Peter.

Date: Wed, 22 Oct 2003 20:23:31 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?
Cc: [email-masked]
Sender: [email-masked]

"Peter Hesse" <[email-masked]> writes:

>Path building implementations should never rely on them being correct.

What's the point of having them at all then?  If you can't rely on them then
you need to have something you can rely on, and if you've got that anyway then
the unreliable alternative is superfluous.

Peter.

Date: Tue, 21 Oct 2003 17:38:58 -0400
From: Yassir Elley <[email-masked]>
Reply-To: [email-masked]
Organization: Sun Microsystems Inc. - BDC
To: [email-masked], [email-masked]
Subject: [Fwd: 3rd Annual PKI R&D Workshop - Call for Papers]
Sender: [email-masked]

FYI

-------- Original Message --------
Subject: 3rd Annual PKI R&D Workshop - Call for Papers
From: Neal McBurnett <[email-masked]>

        3rd Annual PKI R&D Workshop - Call for Papers
           http://middleware.internet2.edu/pki04/

Jointly sponsored by NIH, NIST, and Internet2, in cooperation with
USENIX and OASIS.

This workshop considers the full range of public key technology used
for security decisions. PKI supports a variety of functionalities
including authentication, authorization, identity (syndication,
federation and aggregation) and trust.

We solicit papers, scenarios, war stories, panel proposals, and
participation from researchers, systems architects, vendor engineers
and above all users.

Location:                 NIST, Gaithersburg MD, USA.
Papers and Proposals due: January 30, 2004
Authors Notified:         March 1, 2004
Final Materials Due:      March 22, 2004
Workshop Dates:           April 12-14, 2004

This workshop has three goals:

  * Explore the current state of public key technology in different
    domains including web services, grid technologies, authentication
    systems et. al. in academia & research, government and industry.
  * Share & discuss lessons learned and scenarios from vendors and
    practitioners on current deployments
  * Provide a forum for leading security researchers to explore the
    issues relevant to the PKI space in areas of security management,
    identity, trust, policy, authentication and authorization.

The results will be promulgated in several ways, including:
  * a published proceedings with refereed papers and summaries of
    workshop discussions
  * the workshop web site: http://middleware.internet2.edu/pki04/
  * experimental initiatives within higher education

Outstanding papers will be invited for possible publication in ACM
TISSEC.

Presentation formats will include:
  * Refereed papers
  * Panel discussions
  * Invited talks
  * Work-in-progress updates

Submitted works for panels, papers and reports should address one or
more critical areas of inquiry. Topics include (but not are not
limited to):
  * PKI systems in various domains like grid, web services,
    government, industry and academia.
  * PKI and Federated trust
  * Related standards: x509, SDSI/SPKI, PGP, XKMS, SAML, Shibboleth,
    Liberty Alliance, etc.
  * Cryptographic methods in support of security decisions
  * The characterization and encoding of security decision data
  * Security protocols and choreographies - new ideas, analysis of
    existing systems et al
  * Alternative methods for supporting security decisions
  * Intersection of Policy based systems and PKI
  * Privacy protection and implications of different approaches
  * Scalability of security systems - are there limits to growth?
  * Security of the various components of a system: private keys, root
    authorities, certificate storage, communications channels, code,
    directories, etc.
  * Mobility solutions
  * Approaches to attributes and delegation
  * Improved designs for security-related user interfaces
  * Human factors issues with naming, multiple private keys, selective
    disclosure
  * Discussion of how the "public key infrastructure" may differ from
    the "PKI" traditionally defined
  * Reports of real-world experience with the use and deployment of
    PKI, especially where future research directions for PKI are
    indicated
  * What is missing? The gaps in PKI research and standards from a
    systems engineering point-of-view

Submissions and Additional Information

Papers should be submitted electronically, in PDF, formatted for
standard US letter-size paper (8.5 x 11 inches). The final version of
refereed papers should ideally be between 8 and 15 pages, and in no
case more than 20 pages. They should have no header or footer text
(e.g., no page numbers).

Proposals for panels should be no longer than five pages in length and
should include possible panelists and an indication of which of those
panelists have confirmed participation.

Please submit the following information by email to
[email-masked]:
  * The full contact details (name, affiliation, email, phone, postal
    address) of one author who will act as the primary contact for
    this paper.
  * The full list of authors: you must supply the first name, the last
    name and the affiliation of each author.
  * The finished paper in PDF format as an attachment.

All submissions will be acknowledged.

The deadline for submission is January 30, 2004. Requests for short
extensions will be granted on a case-by-case basis, and must be
requested by January 30th via email to the same address.

When appropriate, authors should arrange for a release for publication
from their employer prior to submission. Papers accompanied by
non-disclosure agreement forms are not acceptable and will be returned
to the author(s) unread.

Submissions of papers must not substantially duplicate work that any
of the authors have published elsewhere or have submitted in parallel
to any other conferences or journals.

The registration fee will be waived for presenters. A limited number
of stipends are available to those unable to obtain funding to attend
the workshop. Further information will be available on the
registration page in January.

Program Committee

   Peter Alterman       NIH
   Matt Blaze           AT&T Labs Research
   Bill Burr            NIST
   Yassir Elley         Sun Microsystems
   Carl Ellison         Microsoft
   Stephen Farrell      Trinity College Dublin, 
   Richard Guida        Johnson & Johnson
   Peter Honeyman       University of Michigan
   Russ Housley         Vigil Security LLC
   Ken Klingenstein     University of Colorado
   Olga Kornievskaia    University of Michigan
   Neal McBurnett       Internet2
   Clifford Neuman      USC
   Eric Norman          University of Wisconsin
   Tim Polk             NIST
   Ravi Sandhu          George Mason University; NSD Security
   Krishna Sankar       Cisco Systems
   Jeff Schiller        MIT
   Frank Siebenlist     Argonne National Laboratory
   Sean Smith           Dartmouth College
   Michael Wiener       Cryptographic Clarity

General Chair: 
   Ken Klingenstein, University of Colorado.

Program Chair:
   Krishna Sankar, Cisco Systems.

Steering Committee Chair:
   Neal McBurnett, Internet2.

Local Arrangements Chair:
   Nelson Hastings, NIST.

---------------------------------------------------mw-pkiprgmcommittee-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

---------------------------------------------------mw-pkiprgmcommittee--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Tue, 21 Oct 2003 17:17:17 -0400
Importance: Normal
Sender: [email-masked]

Based on a review of Sections 4.2.1.2 and 4.2.1.1 of 3280, I draw the
following conclusion: A 3280 compliant CA MUST ensure that AKI and SKI chain
properly.  This is sufficient for path construction.  Thus, I do not see a
particular need to change 3280 in this area.

The various methods for calculating these values and their probability of
collision need not be described in 3280.  As others have pointed out, AKI
and SKI need not be unique or different globally.  For efficient path
development, it is sufficient that AKI and SKI be different, with high
degree of probability, for different keys of the same entity.  The algorithm
chosen can be left up to the CA.  The proper chaining of AKI and SKI (not
for path validation, but for path construction) is important.  By proper
chaining, I mean that the SKI in certificate(s) issued to a CA for a
specific public key should (I read 3280 to say MUST, and I like that over
SHOULD) match the AKI in those certificates that the CA issues which are
verified using the said specific public key.

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: "Matt Cooper" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt
Date: Tue, 21 Oct 2003 15:03:13 -0400
Importance: Normal
Sender: [email-masked]

Hi Alice,

Thanks for the thorough reading! You made a lot of good suggestions that
will help clarify the I-D. Please see my comments below.

Best Regards,
Matt

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alice Sturgeon
 
> Terminology, on "certification path building" and its aka's:  
> How can "building" be the same as "discovery", which would be 
> more like the validation process?  Also, using the verb 
> "obtain" does not make it clear whether it is the building 
> (construction, development) or the discovery (finding, 
> validating) that is being described, although, given the 
> subject of the I-D, we only assume it is the former 
> (building).

We had a few rounds of discussion on the term to use here and settled on
building. You are correct, the focus is on constructing a likely to validate
path, not validating it. I think the connotations of each aka also vary
according to whom you ask. =) I also agree that "obtain" should be replaced
with a better verb. How about "assemble"? I think that is more in line with
what we meant.

> Terminology, on "subscriber" - You might consider stating 
> something like: "also referred to as 'user' or, in a 
> certification hierarchy, 'End Entity'". Many use "subscriber" 
> and "user" synonymously and so it might be helpful to clarify 
> that (or your thinking on the two terms), and you use End 
> Entity, and so your view on its relationship to "subscriber" 
> as certificate subject would be helpful.  Stating these 
> equivalents here would also avoid having to do so in the 
> later text (e.g., in 1.4, "end entities' (subscribers')" in 
> 1st para.).

This is tricky to dance around and I obviously didn't do too great a job!
The "End Entity" of the path is not necessarily a subscriber/user. For
example, you may be building a path for a CRL signer. Hence, I tried to
steer clear of the subscriber/user terms unless an example was specifically
citing that type of cert. I think it ended up a little messy. I will review
for this usage and see what I can do to make it more consistent.

> Terminology: In view of your last two terms, you might 
> consider trying to define "trust" - rather critical to the 
> whole I-D concept.  While you use the term extensively in the 
> Introduction, it does seem to be assumed that the concept is 
> understood - and it is in a general sense, but it might be 
> prudent to define explicitly for this context.  For example, 
> are there well defined security attributes that make up 
> "trust" - confidentiality, integrity, accountability, 
> authenticity, or (gulp) non-repudiation?

I agree, but I'm a little concerned about trying to boil down what is a
fairly broad concept as it is applied to PKI in a definition. Perhaps a to
the point definition with 3280 as suggested reading?  It may make sense for
us to explicitly point out in the introduction that that the I-D assumes the
reader understands the contents of 3280 and related documents. I'll give
this some more thought.

> With respect to 1.4.3 and the text on figure 4, and the two 
> principal concerns about vulnerability:  If the cert path 
> building software is written correctly, then transitive trust 
> should be impossible.  

It's not so much a vulnerability as a result of many cooks in the kitchen.
If I cross certify with you today, and tomorrow you cross certify with ACME
PKI, I may now trust ACME PKI without intending to. Of course, there are
ways to design the certificates to prevent this. Problem is in my mind, as
the number of variables (cross certified infrastructures) grows, it becomes
increasingly difficult to keep track of the possibilities. IMO, limiting the
number of combinations is one of the very nice properties of having a single
bridge rather than "meshing" the infrastructures.

> Secondly, I would think that cert 
> policy mapping should prohibit the cross-certification of 
> PKIs with different assurance levels.

Agree, it _should_. =) Again, the worry is similar what I described just
above. If I give you a cert with high assurance, and you certify a lower
assurance PKI and map the policy to it, then I have a problem without
realizing it. Or perhaps, you correctly give ACME PKI the high assurance
cert, and they in turn cross certify with a lower assurance PKI and keep the
policy intact. Again, you can control all these things to varying degrees
with name constraints, path length cons, etc., but I think we have to take
the human factor of PKI design into consideration and be somewhat realistic
with our expectations.

> 1.4.4 says:
> However, when connecting PKIs in this way, the number and 
> variety of PKIs involved results in a non-hierarchical 
> environment, such as the one as depicted in Figure 5. I don't 
> think this is quite true, or perhaps just a simplification: 
> The overall environment or framework (or super-structure) is 
> non-hierarchical, but within that framework there is indeed a 
> hierarchical environment.  This is an important point, 
> because it shows how the bridge, as non-hierarchical 
> framework, can simplify the one or many hierarchical 
> structure(s) within it for the purpose of cross-certification.

I'm not sure I'm understanding what you are saying. Are you saying we should
at this point stress that although the overall graph is non-hierarchical,
that the trust framework is still hierarchical?

> 1.5 - First reason given for supporting the bridge structure 
> is gratuitous - Use it because it is used...  I think this 
> point (1) detracts from point (2), which is a much more 
> important reason.

I agree and see no problem removing that and focusing on (2).

> RFC 3280 6.2 states:  While each certification path begins 
> with a specific trust anchor, ... So why is path building 
> beginning with the trusted root called "reverse"?  I assume 
> this is because for cert path validation, one logically 
> starts with the EE cert. So - different purposes, different 
> terminology?

I think this is throw back to prior terminology for cross certificates. The
reverse cross certificates are those issued from a CA, the forward are those
issued to the CA. If building from the EE, you use the forward, when
building from the TR, you use the reverse, hence the naming of the
respective building directions. I think, though I may start a religious
debate here, "forward" was chosen as a natural result of that being the
intended/designed direction for path building. (It certainly isn't forward
with respect to issuance!)

> 2.4.1, last sentence of 1st indented paragraph says:
> "In other words, consumption of such paths by relying parties 
> could potentially yield trust in unintended ways." Assuming 
> (perhaps incorrectly) that "trust in unintended ways" means 
> "unintended trust", then the path actually creates a 
> vulnerability, does it not?

Yes, and I agree with you, but I did intentionally soft pedal that.
Basically, if everyone did everything just right, there should, in theory,
not be any unintended trust. The problem is to my mind that allowing these
unnecessarily convoluted paths increases the number of variables
exponentially; making it next to impossible for a PKI designer to consider
every possible outcome, and therefore, every possible trust path. More to
the point, I don't think the convoluted path in and of itself is a
vulnerability, but I think it creates the potential for masking a
vulnerability/unintended trust.

> Second point also could be 
> identified as a vulnerability, in that the path 
> unintentionally lowers the assurance level.

Agree to an extent as well; but this has been a topic of much debate in the
past with no clear winner. Hence the "may be considered lost" verbiage as
opposed to "is lost." I'm in the latter school of thought and I personally
would like to see this become part of path validation rather than a
recommended approach to path building. Perhaps it is time for the list to
re-visit this topic...

> 2.4 states:
> "The BCA also has issued four certificates, one to each of 
> the trust roots." But then 2.4.2 states: "It is not possible 
> to build forward direction paths into the infrastructures 
> behind CAs W, Y, and Z, because W, Y, and Z have not been 
> issued certificates by any other CAs." I'm missing something 
> on this point.

I agree this isn't clear enough and I think we should try to clarify this
point because it is an important one to my mind. The idea is, for example,
suppose I'm building a (forward) path from E to TR-X. It isn't possible for
my forward path builder to go astray and wander into the infrastructure
behind TR-W because TR-W was not issued certificates by either F or G. (The
builder would be forced to "go back" at W)  However, the same example
flipped around building (in reverse) from TR-X to E, the path builder could
wander into the infrastructure behind TR-W using the certificates issued
from TR-W to F and/or G. The reverse builder than may not recurse back until
all paths behind TR-W are exhausted.

> >From the References: [RFC 1738]  Berners-Lee, T., L. Masinter and M.
> McCahill, "Uniform Resource Locators (URL)", RFC 1738, 
> December 1994. You may wish to reference, instead or in 
> addition, RFC 2396 URI Berners-Lee, T., Fielding, R., Irving, 
> U.C., and L. Masinter. "Uniform Resource Identifiers (URI): 
> Generic Syntax", August 1998.  RFC 2396 updates and merges 
> RFC 1738 (as well as "Relative Uniform Resource Locators" 
> [RFC1808]), although 2396 excludes the portions of RFC 1738 
> that define the specific syntax of individual URL schemes.  
> (And you use "URI" much more frequently than "URL".) Are the 
> references intended to be Normative or Informative?  I 
> believe it is necessary now to distinguish references now on 
> this basis.

You are correct; we need to update this section.

> 8. Security Considerations - In the 2nd and 3rd sentences, 
> you state the need to protect the trusted root cert, as well 
> as the trusted root keys.  It is necessary that the root cert 
> be available for the path. It is root keys that need to be 
> "kept safe" and of course only the public key should be 
> obtainable.  Suggest deleting trusted root cert from this discussion.

I agree the key is all that matters, but wrote it this way so as to not
diminish the importance of protecting the cert if that is the source of the
key. Perhaps a re-wording would be better:

The only exception to this is the appropriate protection of the trusted root
key(s) (or trusted root certificates if they are the source of the trusted
keys) used for validating paths.

?

> Editorial notes:

Thank you for these as well; we will address these items in the next
revision.

Thanks again for your efforts!

Date: Tue, 21 Oct 2003 19:00:26 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: PKIX agenda
Sender: [email-masked]

I would like to know when an agenda for the
Minneapolis meeting will be available. 

I am not part of those who are able to go
without justification.  

Date: Tue, 21 Oct 2003 18:27:48 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

A little bit of nit-picking the text in 3820:

>4.2.1.2
>     One common method for generating unique values is a monotonically
>     increasing sequence of integers.
  1, 1, 2, 2, 3, 3 is a monotonically increasing sequence of integers
according to some common definitions for sequences or functions.

As far as I remember my math classes from 30 years ago,
non-ambiguous terms are 'strictly increasing" or
"monotone and strictly increasing" or "monotonically
strictly increasing" ...

Peter

Date: Tue, 21 Oct 2003 17:52:44 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

Steve Hanna wrote:

>Note also that AKI/SKI chaining SHOULD NOT be checked
>during path validation. To be more explicit, it's
>NOT true that the SKI of a CA certificate must match
>the AKI of a certificate signed by that CA. Why?
>Because the CA certificate may have been issued by
>a CA that uses a different AKI/SKI computation technique
>than the CA who's the subject of the CA certificate.
>  
>
I really think it would be a better practice to always have a method of 
reusing existing SKI when emitting a cross-certificate.

It might be difficult with some currently used mecanisms for that, but 
cross-certificates for CA are not likemy to be an automatic process like 
the emission of a end-user certificate.

From: "Deacon, Alex" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, [email-masked]
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Tue, 21 Oct 2003 08:43:06 -0700
Sender: [email-masked]

NO

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Wednesday, October 15, 2003 2:03 PM
> To: [email-masked]
> Subject: POLL: Nonce-specific error code for OCSP
> 
> 
> 
> All,
> 
> I recently received permission from the chairs to poll the WG
> against the following question.
> 
> Should we standardize an OCSP *V1* error code that enables a
> responder to indicate its inability to respond to nonced
> requests?
> 
> Please respond with either YES or NO.
> 
> Mike
> 
> 

Reply-To: <[email-masked]>
From: "Alice Sturgeon" <[email-masked]>
To: "Peter Hesse" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt
Date: Tue, 21 Oct 2003 11:41:47 -0400
Importance: Normal
Sender: [email-masked]

Hi all,
This is an important effort and it is going to be very helpful once
finalized.
A few comments (with the humble caveat that those of you who wrote this I-D,
and with whom you consulted, are considerably more knowledgeable on this
subject than I am!):

Terminology, on "certification path building" and its aka's:  How can
"building" be the same as "discovery", which would be more like the
validation process?  Also, using the verb "obtain" does not make it clear
whether it is the building (construction, development) or the discovery
(finding, validating) that is being described, although, given the subject
of the I-D, we only assume it is the former (building).  As the authors
state in Purpose, other documents, notably RFC 3280, go into cert path
validation, and so this I-D does not go there.

Terminology, on "subscriber" - You might consider stating something like:
"also referred to as 'user' or, in a certification hierarchy, 'End Entity'".
Many use "subscriber" and "user" synonymously and so it might be helpful to
clarify that (or your thinking on the two terms), and you use End Entity,
and so your view on its relationship to "subscriber" as certificate subject
would be helpful.  Stating these equivalents here would also avoid having to
do so in the later text (e.g., in 1.4, "end entities' (subscribers')" in 1st
para.).

Terminology: In view of your last two terms, you might consider trying to
define "trust" - rather critical to the whole I-D concept.  While you use
the term extensively in the Introduction, it does seem to be assumed that
the concept is understood - and it is in a general sense, but it might be
prudent to define explicitly for this context.  For example, are there well
defined security attributes that make up "trust" - confidentiality,
integrity, accountability, authenticity, or (gulp) non-repudiation?

With respect to 1.4.3 and the text on figure 4, and the two principal
concerns about vulnerability:  If the cert path building software is written
correctly, then transitive trust should be impossible.  Secondly, I would
think that cert policy mapping should prohibit the cross-certification of
PKIs with different assurance levels.

1.4.4 says:
However, when connecting PKIs in this way, the number and variety of PKIs
involved results in a non-hierarchical environment, such as the one as
depicted in Figure 5.
I don't think this is quite true, or perhaps just a simplification: The
overall environment or framework (or super-structure) is non-hierarchical,
but within that framework there is indeed a hierarchical environment.  This
is an important point, because it shows how the bridge, as non-hierarchical
framework, can simplify the one or many hierarchical structure(s) within it
for the purpose of cross-certification.

1.5 - First reason given for supporting the bridge structure is gratuitous -
Use it because it is used...  I think this point (1) detracts from point
(2), which is a much more important reason.

RFC 3280 6.2 states:  While each certification path begins with a specific
trust anchor, ...
So why is path building beginning with the trusted root called "reverse"?  I
assume this is because for cert path validation, one logically starts with
the EE cert.
So - different purposes, different terminology?

2.4.1, last sentence of 1st indented paragraph says:
"In other words, consumption of such paths by relying parties could
potentially yield trust in unintended ways."
Assuming (perhaps incorrectly) that "trust in unintended ways" means
"unintended trust", then the path actually creates a vulnerability, does it
not?
Second point also could be identified as a vulnerability, in that the path
unintentionally lowers the assurance level.

2.4 states:
"The BCA also has issued four certificates, one to each of the trust roots."
But then 2.4.2 states:
"It is not possible to build forward direction paths into the
infrastructures behind CAs W, Y, and Z, because W, Y, and Z have not been
issued certificates by any other CAs."
I'm missing something on this point.

>From the References: [RFC 1738]  Berners-Lee, T., L. Masinter and M.
McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
You may wish to reference, instead or in addition, RFC 2396 URI
Berners-Lee, T., Fielding, R., Irving, U.C., and L. Masinter. "Uniform
Resource Identifiers (URI): Generic Syntax", August 1998.  RFC 2396 updates
and merges RFC 1738 (as well as "Relative Uniform Resource Locators"
[RFC1808]), although 2396 excludes the portions of RFC 1738 that define the
specific syntax of individual URL schemes.  (And you use "URI" much more
frequently than "URL".)
Are the references intended to be Normative or Informative?  I believe it is
necessary now to distinguish references now on this basis.

8. Security Considerations - In the 2nd and 3rd sentences, you state the
need to protect the trusted root cert, as well as the trusted root keys.  It
is necessary that the root cert be available for the path. It is root keys
that need to be "kept safe" and of course only the public key should be
obtainable.  Suggest deleting trusted root cert from this discussion.

Editorial notes:

Section 1, 1st para., last sentence: There should be an "s" on
"certificate".
1.4, 1st sentence, the phrase "often times" does not translate well nor may
not be as clear as, simply, "often".

1.4.4, 4th sentence (beginning with "Since each PKI...") is not a sentence:
There is one subordinate clause (beginning with "Since"), with two parts to
it (joined by "and") but no principal clause.  The sense of it is that the
next sentence should be the principal clause, but since that would make a
horribly long sentence, I would suggest simply removing the "Since" and
making that a stand-alone (and proper) sentence.

2, last sentence reads (not well):
Rather, guidance is provided on the technical issues that surround the path
building process, and the capabilities path building implementations require
in order to build certification paths successfully, irrespective of PKI
structures.
To make this easier to read (I had trouble), insert "on" before "...the
capabilities path...", and add the letter "d" to "require"
("...implementations required in order to build...")

The A's, B's, and C's in figure 6 are a little confusing.  It can be
understood but it might be easier to do so if you used a combination of
numbers and letters.

All for now.

Alice Sturgeon
Chair, Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC 1/SC 27
and
System Policy Architect & Manager Standards
SPYRUS

Office:  613-232-2350
Mobile: 613-291-0331

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Peter Hesse
Sent: Friday, October 03, 2003 9:18 AM
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt

All,

To save everyone the trouble of trying to read through our entire
internet draft a second time, the following lists outline the main
changes made in the document since version 00.

Overall changes:
- made certain terminology more consistent ("certification
   path" throughout the document instead of "certificate path",
   "cert path", etc.)
- softened the tone; made it clear that the document provides
   informational recommendations and does not prescribe a
   particular method for certification path building
- removed statements on the document providing guidance based
   on "best practices" but instead explicitly defined the
   motivation and purpose behind the document, as well as the
   criteria that led to the guidance provided.
- removed some non-ascii characters that had snuck in

Specific changes:
- Thoroughly updated section 1.1 (Motivation) and 1.2 (Purpose)
- updated terminology section to include a few additional terms
- updated mesh PKI figure to better differentiate it from other
   structures
- included a section (2.2) that clearly identifies the authors'
   criteria for a path building implementation
- broke up section 2.4 (How to Build a Certification Path) with
   some subsections
- added section 3.3 (Representing the Decision Tree
   Programmatically)
- updated section 3.5 to include additional information about
   the sorting methods that follow.  Sorting methods are no
   longer called "rules".
- added section 5.4 (Distinguished Name Encoding)
- added section 6.3 (Subject Information Access)

Cheers,

--Peter Hesse

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been
a statue set up in honor of a critic." --Jean Sibelius

Date: Tue, 21 Oct 2003 10:46:51 -0400
From: Steve Hanna <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Peter Hesse <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

Stefan Santesson wrote:
> What is in fact the current behaviour of applications today:
> 
> Do they:
> 1) Not even try to validate the path since issuer/subject don't match
> 2) Fail validation and display error
> 3) Fail validation, then goes back and search for another path

In Sun's JDK 1.4.x, we ignore AKI/SKI so an AKI/SKI match
on unrelated certs is not a problem for us. I guess that
falls into category 3).

> In case there would be a followup to RFC 3280 my feeling is that
> increasing integers should be deprecated.

It's fine to deprecate this option (probably a
good idea), but we should also warn that AKI/SKI
may not match and that's fine. Nothing in RFC 3280
says this currently and that seems to be confusing
for implementors.

Thanks,

Steve Hanna

Date: Tue, 21 Oct 2003 10:21:31 -0400
From: Steve Hanna <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms276F0AA07F1B7F9D4A5D81DB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A decent MUA would understand that there may be more
than one cert with the same SKI. AKI/SKI is just a
hint. As such, it's nice (maybe leading to better
performance) if there's one and only one cert with
a particular SKI. But it's not required.

In fact, if you use one of the key hash methods for
calculating the AKI/SKI and there are several certificates
with the same subject public key (as with multiple
cross-certificates for a single CA), these certificates
will probably all have the same SKI.

Note also that AKI/SKI chaining SHOULD NOT be checked
during path validation. To be more explicit, it's
NOT true that the SKI of a CA certificate must match
the AKI of a certificate signed by that CA. Why?
Because the CA certificate may have been issued by
a CA that uses a different AKI/SKI computation technique
than the CA who's the subject of the CA certificate.

Thanks,

Steve

Peter Gutmann wrote:
> 
> "Al Arsenault" <[email-masked]> writes:
> 
> >Why does an AKI/SKI have to be globally unique?
> >
> >It strikes me that the AKI/SKI extensions are simply "search aids".  That is,
> >they merely help the application (RP) determine which of a set of possible
> >certificates to use is the correct one. While it would be kind of cool if an
> >SKI/AKI would be globally unique (it would make searching a repository a
> >little easier/quicker IN SOME CASES), it doesn't strike me as a huge deal.
> 
>   You send me a CMS signed message (say) with the key identified by sKID = 0.
>   My MUA finds a cert with sKID = 0 and tries to verify the signature.  The
>   verification fails, and I get a warning saying that the forces of darkness
>   are tampering with my communications, I could be under attack, and the world
>   is about to end.
> 
>   You send me a CMS signed message (say) with the key identified by sKID =
>   aildhfsdfsjklhgdfjghkf.  My MUA can't find a cert with that sKID and
>   displays an informational message saying that it couldn't find a signing
>   key, and perhaps I should contact the sender for more information.
> 
> There's a big difference in terms of usability.
> 
> Peter.
--------------ms276F0AA07F1B7F9D4A5D81DB
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms276F0AA07F1B7F9D4A5D81DB--

From: "Al Arsenault" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Tue, 21 Oct 2003 10:18:04 -0400
Importance: Normal
Sender: [email-masked]

Well, bear in mind that RFC3280 allows the "monotonically increasing..." bit
only for CA certificates.  Section 4.2.1.2 explicitly says:

	" For end entity certificates, subject key identifiers SHOULD be
   derived from the public key.  Two common methods for generating key
   identifiers from the public key are identified above."

Okay, it's only a SHOULD, not a MUST, but the scenario you reference below
only comes in to play if I signed the CMS message using my CA cert, not my
end-entity cert.

Got an example where this is relevant if the sKID's of two different CA
certs are the same?  Granted, if I use the CA cert directly in an
application, problems like your example can occur, but such uses shouldn't
be happening (IMNSHO).

		Al Arsenault

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]]
Sent: Tuesday, October 21, 2003 9:10 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?

"Al Arsenault" <[email-masked]> writes:

>Why does an AKI/SKI have to be globally unique?
>
>It strikes me that the AKI/SKI extensions are simply "search aids".  That
is,
>they merely help the application (RP) determine which of a set of possible
>certificates to use is the correct one. While it would be kind of cool if
an
>SKI/AKI would be globally unique (it would make searching a repository a
>little easier/quicker IN SOME CASES), it doesn't strike me as a huge deal.

  You send me a CMS signed message (say) with the key identified by sKID =
0.
  My MUA finds a cert with sKID = 0 and tries to verify the signature.  The
  verification fails, and I get a warning saying that the forces of darkness
  are tampering with my communications, I could be under attack, and the
world
  is about to end.

  You send me a CMS signed message (say) with the key identified by sKID =
  aildhfsdfsjklhgdfjghkf.  My MUA can't find a cert with that sKID and
  displays an informational message saying that it couldn't find a signing
  key, and perhaps I should contact the sender for more information.

There's a big difference in terms of usability.

Peter.

Content-class: urn:content-classes:message
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Tue, 21 Oct 2003 15:09:25 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Peter Hesse" <[email-masked]>, "Peter Gutmann" <[email-masked]>, <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I'm particularly interested in the reality check.

If an application use AKI/SKI match to discover a path and finds an
AKI/SKI match of unrelated keys. What happens?

Ignoring what applications SHOULD do (which we all know)
What is in fact the current behaviour of applications today:

Do they:
1) Not even try to validate the path since issuer/subject don't match
2) Fail validation and display error
3) Fail validation, then goes back and search for another path

The danger with the outline of RFC 3280 is that two different methods
with different characteristics is proposed, while almost everybodey use
the first (key hash based). Implementers may thus be tempted to make
development shortcuts, based on a fair assumption that AKI/SKI match
indicates use of the same key, not causing any security risks, but
leading to unneccesary errors in casae that assumption is false.

In case there would be a followup to RFC 3280 my feeling is that
increasing integers should be deprecated. 

In the ETSI cert profile under development we are currently proposing to
deprecate this option.

/Stefan

> -----Original Message-----
> From: Peter Hesse [mailto:[email-masked]]
> Sent: den 21 oktober 2003 15:45
> To: 'Peter Gutmann'; [email-masked]; Stefan Santesson
> Cc: [email-masked]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> "Peter Gutmann" <[email-masked]> writes:
> 
> > My code has included a check to ignore the sKID if it's less than
> > 40 bits for some time now, because anything less than that is a
> > danger sign implying the use of an integer sequence.
> 
> The RFC 3280 certification path validation process does not include a
> check of the sKID and/or aKID; if they don't match, there is nothing
> wrong with the path.  Path building implementations should never rely
on
> them being correct.  They may be useful if they are present and
correct,
> but as was said, may lead building algorithms astray if they are
present
> and incorrect.  Therefore implementations should use them if they are
> helpful, but not rely on their existence or fail if they are
incorrect.
> 
> --Peter
> 
> +---------------------------------------------------------------+
> | Peter Hesse                    [email-masked]     |
> | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> | ICQ: 1942828                     www.geminisecurity.com       |
> +---------------------------------------------------------------+
> "Pay no attention to what the critics say; there has never been
> a statue set up in honor of a critic." --Jean Sibelius
> 

Date: Tue, 21 Oct 2003 10:00:43 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: AKI and SKI problem with RFC 3280?
Cc: <[email-masked]>, "Russ Housley" <[email-masked]>
Sender: [email-masked]

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

At 11:12 +0100 10/20/03, Stefan Santesson wrote:
>
>I have come a cross a potential problem with RFC 3280 when working 
>on the new ETSI Certificate profile standard for identity certs.
>
>RFC 3280 states:
>
>4.2.1.1
>
>    The value of the keyIdentifier field SHOULD be derived from the
>    public key used to verify the certificate's signature or a method
>    that generates unique values.  Two common methods for generating key
>    identifiers from the public key, and one common method for generating
>    unique values, are described in section 4.2.1.2
>
>4.2.1.2
>    One common method for generating unique values is a monotonically
>    increasing sequence of integers.
>
>
>This means that a CA, following the recommendation can assign key 
>identifier values of e.g. 1, 2, 3, 4, 5, 6,..., n
>
>If many different CA:s would follow the "monotonically increasing 
>sequence of integers" procedure, multiple unrelated certificates 
>would end up having the same SKI and/or AKI values relating to 
>completely different public keys.
>
>I'm not sure how most path building clients would handle a situation 
>like that, but I fear that at least some would fail.
>
>Isn't the point that AKI:s and SKI:s should use a generation 
>algorithm that assigns them a globally unique value with high 
>probability and therefore SHOULD be derived from the public key and 
>NOT use a "monotonically increasing sequence of integers". At least 
>not starting from a small integer?
>
>/Stefan

For path building purposes, there is no need for uniqueness in these 
values.  We have stated several times that path building is NOT 
supposed to use these values to locate certs, but rather to 
disambiguate among certs that have the right Subject name (assuming a 
bottom's up path building).

However, when the SKI appears in an EE cert, and that EE cert is used 
in S/MIME, then we are assuming uniqueness, because the receiver uses 
the SKI to locate the right token for that receiver.  This support 
for S/MIME is why we put in the SKI requirement for EE certs, where 
it otherwise would not be needed (re path building).

Steve

P.S.  Peter, your example talked about signature verification, but I 
don't think that's right, because the signature info is not per 
recipient, it is per originator, and thus would not encounter this 
problem.
--============_-1145377522==_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: AKI and SKI problem with RFC
3280?</title></head><body>
<div>At 11:12 +0100 10/20/03, Stefan Santesson wrote:</div>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">I have
come a cross a potential problem with RFC 3280 when working on the new
ETSI Certificate profile standard for identity
certs.</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">RFC
3280 states:</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">4.2.1.1</font></blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;&nbsp; The value of the keyIdentifier field
SHOULD be derived from the</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;&nbsp; public key used to verify the
certificate's signature or</font><font color="#FF0000"> a
method</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#FF0000">&nbsp;&nbsp; that generates unique values</font><font
color="#000000">.&nbsp; Two common methods for generating
key</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;&nbsp; identifiers from the public
key,</font><font color="#FF0000"> and one common method for
generating</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#FF0000">&nbsp;&nbsp; unique values, are described in section
4.2.1.2</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">4.2.1.2</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;&nbsp;</font><font color="#FF0000"> One common
method for generating unique values is a
monotonically</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#FF0000">&nbsp;&nbsp; increasing sequence of
integers</font><font color="#000000">.</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">This means that a CA, following the recommendation can
assign key identifier values of e.g. 1, 2, 3, 4, 5, 6,...,
n</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">If many different CA:s would follow the
"</font><font color="#FF0000">monotonically increasing sequence of
integers</font><font color="#000000">" procedure, multiple unrelated
certificates would end up having the same SKI and/or AKI values
relating to completely different public keys.</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">I'm not sure how most path building clients would
handle a situation like that, but I fear that at least some would
fail.</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">Isn't the point that AKI:s and SKI:s should use a
generation algorithm that assigns them a globally unique value with
high probability and therefore SHOULD be derived from the public key
and NOT use a "</font><font color="#FF0000">monotonically increasing
sequence of integers</font><font color="#000000">". At least not
starting from a small integer?</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1"
color="#000000">/Stefan</font></blockquote>
<div><br></div>
<div>For path building purposes, there is no need for uniqueness in
these values.&nbsp; We have stated several times that path building is
NOT supposed to use these values to locate certs, but rather to
disambiguate among certs that have the right Subject name (assuming a
bottom's up path building).</div>
<div><br></div>
<div>However, when the SKI appears in an EE cert, and that EE cert is
used in S/MIME, then we are assuming uniqueness, because the receiver
uses the SKI to locate the right token for that receiver.&nbsp; This
support for S/MIME is why we put in the SKI requirement for EE certs,
where it otherwise would not be needed (re path building).</div>
<div><br></div>
<div><br></div>
<div>Steve</div>
<div><br></div>
<div>P.S.&nbsp; Peter, your example talked about signature
verification, but I don't think that's right, because the signature
info is not per recipient, it is per originator, and thus would not
encounter this problem.</div>
</body>
</html>
--============_-1145377522==_ma============--

From: "Peter Hesse" <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Tue, 21 Oct 2003 09:45:17 -0400
Organization: Gemini Security Solutions, Inc.
Importance: Normal
Sender: [email-masked]

"Peter Gutmann" <[email-masked]> writes:

> My code has included a check to ignore the sKID if it's less than 
> 40 bits for some time now, because anything less than that is a 
> danger sign implying the use of an integer sequence.

The RFC 3280 certification path validation process does not include a
check of the sKID and/or aKID; if they don't match, there is nothing
wrong with the path.  Path building implementations should never rely on
them being correct.  They may be useful if they are present and correct,
but as was said, may lead building algorithms astray if they are present
and incorrect.  Therefore implementations should use them if they are
helpful, but not rely on their existence or fail if they are incorrect.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

Date: Wed, 22 Oct 2003 02:26:16 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

Russ Housley <[email-masked]> writes:

>The only CA that I know about that did this has changed to a hash-based
>alternative.

There are European CAs that still do it AFAIK.  I have proof somewhere in the
cert menagerie :-).

Peter.

Date: Tue, 21 Oct 2003 09:16:24 -0400
To: [email-masked], [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: AKI and SKI problem with RFC 3280?
Sender: [email-masked]

Peter:

> >Isn't the point that AKI:s and SKI:s should use a generation algorithm that
> >assigns them a globally unique value with high probability and therefore
> >SHOULD be derived from the public key and NOT use a "monotonically 
> increasing
> >sequence of integers". At least not starting from a small integer?
>
>There is some reason why CAs do this, I can't remember why but I think it was
>the usual ostrich algorithm ("There is no CA but us; to think otherwise is
>treason punishable by limb reconstruction").  I'm not quite sure why the RFC
>tells you to do this though, since the only safe response to it is to ignore
>any sKIDs of that form.

The only CA that I know about that did this has changed to a hash-based 
alternative.

Russ

Date: Wed, 22 Oct 2003 02:09:34 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: AKI and SKI problem with RFC 3280?
Cc: [email-masked]
Sender: [email-masked]

"Al Arsenault" <[email-masked]> writes:

>Why does an AKI/SKI have to be globally unique?
>
>It strikes me that the AKI/SKI extensions are simply "search aids".  That is,
>they merely help the application (RP) determine which of a set of possible
>certificates to use is the correct one. While it would be kind of cool if an
>SKI/AKI would be globally unique (it would make searching a repository a
>little easier/quicker IN SOME CASES), it doesn't strike me as a huge deal.

  You send me a CMS signed message (say) with the key identified by sKID = 0.
  My MUA finds a cert with sKID = 0 and tries to verify the signature.  The
  verification fails, and I get a warning saying that the forces of darkness
  are tampering with my communications, I could be under attack, and the world
  is about to end.

  You send me a CMS signed message (say) with the key identified by sKID =
  aildhfsdfsjklhgdfjghkf.  My MUA can't find a cert with that sKID and
  displays an informational message saying that it couldn't find a signing
  key, and perhaps I should contact the sender for more information.

There's a big difference in terms of usability.

Peter.

From: "Al Arsenault" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: AKI and SKI problem with RFC 3280?
Date: Tue, 21 Oct 2003 08:38:43 -0400
Importance: Normal
Sender: [email-masked]

Okay, I'll bite...

Why does an AKI/SKI have to be globally unique?

It strikes me that the AKI/SKI extensions are simply "search aids".  That
is, they merely help the application (RP) determine which of a set of
possible certificates to use is the correct one. While it would be kind of
cool if an SKI/AKI would be globally unique (it would make searching a
repository a little easier/quicker IN SOME CASES), it doesn't strike me as a
huge deal.

Even using the "monotonically increasing integer sequence" scheme, what we'd
have is:

	Cert A and Cert B have the same AKI value
	Cert A is issued by CA Z, and has serial number N
	Cert B is issued by CA Y, and has serial number M

	(Note that the CA values would be different, because a single CA can't
issue the same AKI/SKI value to multiple certs.  The serial numbers could
coincidentally be the same; that's a random chance.)

	So the path validation software SHOULD say:  "gee, I fetched a cert from
the repository by matching on SKI - I didn't bother searching on issuer
name/serial, or subject name, or...  So now I've got two matches.  Which one
should I use?  Maybe I should actually try looking at one of the other
fields to get a clue, or maybe I'll just take a shot and die a horrible
screaming death if I guess wrong?"

	I'm foggy on the details, but it strikes me that the "monotonically
increasing integer" scheme was actually in use by somebody, and nobody
believed it was a real problem, given the use of the extensions, so we said,
in essence, "heck, why not?" How has that changed?

				Al Arsenault

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Peter Gutmann
Sent: Tuesday, October 21, 2003 2:03 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?

"Stefan Santesson" <[email-masked]> writes:

@microsoft.com?

>If many different CA:s would follow the "monotonically increasing sequence
of
>integers" procedure, multiple unrelated certificates would end up having
the
>same SKI and/or AKI values relating to completely different public keys.

Yup.  I've seen CAs use bits of key hashes, monotonically increasing
integers,
numeric text strings, MPEGs of cats...

>I'm not sure how most path building clients would handle a situation like
>that, but I fear that at least some would fail.

My code has included a check to ignore the sKID if it's less than 40 bits
for
some time now, because anything less than that is a danger sign implying the
use of an integer sequence.

>Isn't the point that AKI:s and SKI:s should use a generation algorithm that
>assigns them a globally unique value with high probability and therefore
>SHOULD be derived from the public key and NOT use a "monotonically
increasing
>sequence of integers". At least not starting from a small integer?

There is some reason why CAs do this, I can't remember why but I think it
was
the usual ostrich algorithm ("There is no CA but us; to think otherwise is
treason punishable by limb reconstruction").  I'm not quite sure why the RFC
tells you to do this though, since the only safe response to it is to ignore
any sKIDs of that form.

Peter.

Date: Tue, 21 Oct 2003 19:02:48 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: AKI and SKI problem with RFC 3280?
Cc: [email-masked]
Sender: [email-masked]

"Stefan Santesson" <[email-masked]> writes:

@microsoft.com?

>If many different CA:s would follow the "monotonically increasing sequence of
>integers" procedure, multiple unrelated certificates would end up having the
>same SKI and/or AKI values relating to completely different public keys.

Yup.  I've seen CAs use bits of key hashes, monotonically increasing integers,
numeric text strings, MPEGs of cats...

>I'm not sure how most path building clients would handle a situation like
>that, but I fear that at least some would fail.

My code has included a check to ignore the sKID if it's less than 40 bits for
some time now, because anything less than that is a danger sign implying the
use of an integer sequence.

>Isn't the point that AKI:s and SKI:s should use a generation algorithm that
>assigns them a globally unique value with high probability and therefore
>SHOULD be derived from the public key and NOT use a "monotonically increasing
>sequence of integers". At least not starting from a small integer?

There is some reason why CAs do this, I can't remember why but I think it was
the usual ostrich algorithm ("There is no CA but us; to think otherwise is
treason punishable by limb reconstruction").  I'm not quite sure why the RFC
tells you to do this though, since the only safe response to it is to ignore
any sKIDs of that form.

Peter.

Content-class: urn:content-classes:message
Subject: AKI and SKI problem with RFC 3280?
Date: Mon, 20 Oct 2003 11:12:24 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Cc: "Russ Housley" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C396F2.E09683D7"

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

=20

I have come a cross a potential problem with RFC 3280 when working on
the new ETSI Certificate profile standard for identity certs.

=20

RFC 3280 states:

=20

4.2.1.1

=20

   The value of the keyIdentifier field SHOULD be derived from the

   public key used to verify the certificate's signature or a method

   that generates unique values.  Two common methods for generating key

   identifiers from the public key, and one common method for generating

   unique values, are described in section 4.2.1.2

=20

4.2.1.2

   One common method for generating unique values is a monotonically

   increasing sequence of integers.

=20

=20

This means that a CA, following the recommendation can assign key
identifier values of e.g. 1, 2, 3, 4, 5, 6,..., n

=20

If many different CA:s would follow the "monotonically increasing
sequence of integers" procedure, multiple unrelated certificates would
end up having the same SKI and/or AKI values relating to completely
different public keys.

=20

I'm not sure how most path building clients would handle a situation
like that, but I fear that at least some would fail.

=20

Isn't the point that AKI:s and SKI:s should use a generation algorithm
that assigns them a globally unique value with high probability and
therefore SHOULD be derived from the public key and NOT use a
"monotonically increasing sequence of integers". At least not starting
from a small integer?

=20

/Stefan

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

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 77.95pt 70.85pt 77.95pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DSV
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I have come a cross a potential problem with RFC 3280 when =
working on the
new ETSI Certificate profile standard for identity =
certs.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>RFC 3280 states:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>4.2.1.1<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; The value of the
keyIdentifier field SHOULD be derived from =
the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; public key used to =
verify the
certificate's signature or </span></font><font color=3Dred><span
style=3D'color:red'>a method<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dred face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:red'>&nbsp;&nbsp; that generates unique =
values</span></font><font
color=3Dblack><span style=3D'color:black'>.&nbsp; Two common methods for =
generating
key<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; identifiers from the =
public
key, </span></font><font color=3Dred><span style=3D'color:red'>and one =
common
method for generating<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dred face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:red'>&nbsp;&nbsp; unique values, are =
described in
section 4.2.1.2</span></font><font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>4.2.1.2<o:p></o:p></span></font></=
p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>&nbsp;&nbsp; </span></font><font
color=3Dred><span style=3D'color:red'>One common method for generating =
unique
values is a monotonically<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dred face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:red'>&nbsp;&nbsp; increasing sequence of =
integers</span></font><font
color=3Dblack><span style=3D'color:black'>.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>This means that a CA, following =
the
recommendation can assign key identifier values of e.g. 1, 2, 3, 4, 5, =
6,..., n<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>If many different CA:s would =
follow the &#8220;</span></font><font
color=3Dred><span style=3D'color:red'>monotonically increasing sequence =
of integers</span></font><font
color=3Dblack><span style=3D'color:black'>&#8220; procedure, multiple =
unrelated certificates
would end up having the same SKI and/or AKI values relating to =
completely
different public keys.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>I&#8217;m not sure how most path =
building clients
would handle a situation like that, but I fear that at least some would =
fail.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>Isn&#8217;t the point that AKI:s =
and SKI:s
should use a generation algorithm that assigns them a globally unique =
value
with high probability and therefore SHOULD be derived from the public =
key and
NOT use a &#8220;</span></font><font color=3Dred><span =
style=3D'color:red'>monotonically
increasing sequence of integers</span></font><font color=3Dblack><span
style=3D'color:black'>&#8220;. At least not starting from a small =
integer?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'><o:p>&nbsp;</o:p></span></font></p=

<p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier =
New"><span
style=3D'font-size:10.0pt;color:black'>/Stefan<o:p></o:p></span></font></=
p>

</div>

</body>

</html>

------_=_NextPart_001_01C396F2.E09683D7--

--------------InterScan_NT_MIME_Boundary--

Date: Sat, 18 Oct 2003 22:49:39 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: DISCUSSION: Nonce-specific error code for OCSP
Sender: [email-masked]

Sorry, didn't mean to start a rehash of the original nonce argument.
My original point was in response to precise protocol assertion from 
Mike's last email:

     Further, the requestor which sent a nonce and received a
     non-nonced response can today infer "responder does not support
     nonces."

I was basically trying to say that, at a protocol level, this statement 
is false.

If a client sends a request to a responder that includes a nonce, and 
that client receives either:
    (a) an unsigned OCSPResponseStatus
     - or -
    (b) a signed response with no nonce and no special extensions
then that client has no way to tell whether that OCSP responder is 
intentionally configured to ignore nonces, or whether an attacker on the 
network is providing (a) bogus or (b) replayed information.

If the signed body of the response contains an extension that says "this 
OCSP infrastructure never provides nonces for any requests", then the 
client can securely determine that this declaration came from a trusted 
entity (the OCSP signer) and not an intermediate attacker.

> The requirement is to bind a request to its associated response
> and thus enable relying parties to mitigate replay risks.  I
> remain curious to an understanding of how unilateral server-side
> response extensions achieve this effect.

I disagree.  The real requirement is that the certificate status 
response be as provably up-to-date as possible for a given request.  All 
this "binding" stuff is just a particular mechanism which MAY achieve 
that requirement.

A nonce can be used to strongly bind a response to a specific request. 
This proves that the response is "fresh" from a responder.  This MAY 
give indication that the underlying status information is up-to-date. 
If, however, the response was provided by a responder which is using a 
CRL that is 11 hours old, the nonce is only providing me with the 
illusion of immediacy.  If a cert was revoked 6 hours ago, that 
responder will provide "fresh" responses validating that cert until the 
next CRL is released and processed.

A response based on a start time (thisUpdate) and end time (nextUpdate) 
more accurately reflects the real underlying status information in any 
system with responders using periodic CRLs.

> In the instance of explicit delegation from a certification
> authority, there then exists a business entity which places
> itself in a position of risk against damage claims.  Are you
> suggesting that an OCSP responder's unilateral inclusion of a
> technical artifact is an assertion of willingness to absorb such
> risks?

Oh, I don't think that lawyers would be quite as clear on the liability 
distinction between ACME Novelty's CA and its Responders.  In both 
cases, ACME has IT personnel running servers with HSMs that provide 
digitally signed information attesting to the identity and status of 
ACME employees.  I don't think you'd avoid any lawsuits by asserting 
that a revoked certificate was "validated" using a compromised ACME OCSP 
Responder rather than a bad CRL from a compromised ACME CA.

But I certainly wouldn't advocate any sort of unilateral inclusion of 
technical artifacts ... that's why we're discussing this as part of the 
standards process.

Thanks,
Dave

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Sat, 18 Oct 2003 18:14:26 -0700
Importance: Normal
Sender: [email-masked]

Dave,

A few thoughts embedded below.

Mike

> -----Original Message-----
> From: David Engberg
>
> . . .
>
> An existing client can't tell the difference between a
> server that doesn't support nonces and a replay
> attack by an attacker who made a nonceless request.
> An explicit "nonceUnsupported" extension in the signed
> body of the response allows a client to securely tell the
> difference between these cases.

The requirement is to bind a request to its associated response
and thus enable relying parties to mitigate replay risks.  I
remain curious to an understanding of how unilateral server-side
response extensions achieve this effect.

> OCSP and other PKIX standards currently allow some
> policy decisions to be made by the infrastructure
> authorities (CAs, responders) and others by the
> relying parties.  For example, the pkix-nocheck
> extension allows the infrastructure to tell clients
> that they should accept a delegated responder cert
> without performing validation.  This extension was
> approved, even though someone could have made an
> argument that "only clients should be allowed to
> set responder validation policies."

In the instance of explicit delegation from a certification
authority, there then exists a business entity which places
itself in a position of risk against damage claims.  Are you
suggesting that an OCSP responder's unilateral inclusion of a
technical artifact is an assertion of willingness to absorb such
risks?

Bear in mind that the relying party problem is notoriously
difficult.  It only appears in the heterogeneous context we are
now debating; else contracts suffice.  If you are unfamiliar
with the issue, you may wish to consult with our legal peers in
the American Bar Association's Information Security Committee.

> Something like "nonceUnsupported" would fall in the
> same category ... the infrastructure is telling
> interested clients about the security characteristics
> of that PK infrastructure and suggesting a security
> policy based on that information.

Infrastructure should serve the needs of its participants rather
than the other way around.

Mike
(602) 739-7744

From: "Piyush" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Subject: Re: Nonce-specific error code for OCSP
Date: Sat, 18 Oct 2003 16:41:00 -0700
Sender: [email-masked]

NO.

Piyush
----- Original Message ----- 
From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 15, 2003 2:02 PM
Subject: POLL: Nonce-specific error code for OCSP

> 
> All,
> 
> I recently received permission from the chairs to poll the WG
> against the following question.
> 
> Should we standardize an OCSP *V1* error code that enables a
> responder to indicate its inability to respond to nonced
> requests?
> 
> Please respond with either YES or NO.
> 
> Mike
> 
> 

Date: Sat, 18 Oct 2003 16:14:23 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: DISCUSSION: Nonce-specific error code for OCSP
Sender: [email-masked]

Michael Myers wrote:

> Further, the requestor which sent a nonce and received a
> non-nonced response can today infer "responder does not support
> nonces."  Something like 11 of 12 client side implementors claim
> ability to detect such.  Inclusion of an extension which in
> effect asserts that "I as responder give myself permission to
> disregard your nonce" does nothing to improve upon that.

I believe that it is not currently possible to infer this under the 
current spec.  An existing client can't tell the difference between a 
server that doesn't support nonces and a replay attack by an attacker 
who made a nonceless request.  An explicit "nonceUnsupported" extension 
in the signed body of the response allows a client to securely tell the 
difference between these cases.

OCSP and other PKIX standards currently allow some policy decisions to 
be made by the infrastructure authorities (CAs, responders) and others 
by the relying parties.  For example, the pkix-nocheck extension allows 
the infrastructure to tell clients that they should accept a delegated 
responder cert without performing validation.  This extension was 
approved, even though someone could have made an argument that "only 
clients should be allowed to set responder validation policies."

Something like "nonceUnsupported" would fall in the same category ... 
the infrastructure is telling interested clients about the security 
characteristics of that PK infrastructure and suggesting a security 
policy based on that information.

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, "'David Engberg'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Sat, 18 Oct 2003 19:49:23 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> It seems to me that an extended response is no improvement 
> upon a plain response when applied to replay detection.  It 
> too can be replayed because there is no dynamic binding 
> between request and response.  That's what the nonce 
> extension was defined to
> enable: client-side elimination of replay risks via dynamic binding.

The response can be replayed. Thats true. But the client now has a way
of dectecting if the responder supports nonces. So the client will ask
itself: Why should I accept a response without nonce from a responder
that supports nonce? Coming to the conclusion that something is wrong
the client can now disregard the response.

Today, when a client sends a request with nonce and gets a response
without nonce that can mean:

A) the responder does not support nonces
B) the responder would support nonces but this is a replay (the attacker
is replaying the response to a request without nonce)

With either one of the proposed extensions, the client would get a
secure method of differentiation between these two cases.

Imagine an attacker now recording an OCSP response to a request without
nonce and replaying this response to another request with nonce. With
the proposed extensions, the replayed response contains information
saying that this responder usually supports nonces. Thus the client will
reject the response, as it did not contain a nonce but the responder
simultaneous indicates that it would support nonce generation.

> Further, the requestor which sent a nonce and received a 
> non-nonced response can today infer "responder does not 
> support nonces."  Something like 11 of 12 client side 
> implementors claim ability to detect such.  Inclusion of an 
> extension which in effect asserts that "I as responder give 
> myself permission to disregard your nonce" does nothing to 
> improve upon that.

I know that 11 of 12 client side implementors think they can infer such
a conclusion. But - sad to say - this conclusion is not necessarily true
in the current state of RfC2560. The response could also be a replay of
a response to a request without nonce. Thats why we need the extension
(or server-generated nonces as a work-around).

So the inclusion of an extension saying that "I AS RESPONDER give myself
permission to disregard your nonce" has a real value. It indicates that
the responder KNOWS that this response may be used in replay or caching
situations. It is a lot better than the current situation. Currently a
response without nonce asserts that "I as responder OR ATTACKER give
myself permission to disregard your nonce".

I hope that clarifies why we want something to the effect of this
proposal so urgently.

-- 
Florian Oelmaier
SyTrust

From: "Michael Myers" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "'David Engberg'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Sat, 18 Oct 2003 10:24:51 -0700
Importance: Normal
Sender: [email-masked]

It seems to me that an extended response is no improvement upon
a plain response when applied to replay detection.  It too can
be replayed because there is no dynamic binding between request
and response.  That's what the nonce extension was defined to
enable: client-side elimination of replay risks via dynamic
binding.

Further, the requestor which sent a nonce and received a
non-nonced response can today infer "responder does not support
nonces."  Something like 11 of 12 client side implementors claim
ability to detect such.  Inclusion of an extension which in
effect asserts that "I as responder give myself permission to
disregard your nonce" does nothing to improve upon that.

Mike

From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: new WG
Date: Sat, 18 Oct 2003 09:23:22 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_002E_01C39559.7D2FABD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

A new working group is being formed to address long-term archive and notary
services.  Mailing list information can be found at
http://www.imc.org/ietf-ltans/index.html; additional details can be found
at: http://ltans.edelweb.fr.  We'll be meeting for the first time at the
upcoming IETF meeting in Minneapolis.  Anyone interested in giving a
presentation during the WG session should send a request to
[email-masked] or [email-masked].

------=_NextPart_000_002E_01C39559.7D2FABD0
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.2800.1264" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D774390113-18102003><FONT face=3DArial size=3D2>A new =
working group=20
is being&nbsp;formed&nbsp;to address long-term archive and notary=20
services.&nbsp; Mailing list information can be found at <A=20
href=3D"http://www.imc.org/ietf-ltans/index.html">http://www.imc.org/ietf=
-ltans/index.html</A>;=20
additional details can be found at: <A=20
href=3D"http://ltans.edelweb.fr">http://ltans.edelweb.fr</A>.&nbsp; =
We'll be=20
meeting for the first time at the upcoming IETF meeting in =
Minneapolis.&nbsp;=20
Anyone interested in giving a presentation during the WG session should =
send a=20
request to&nbsp;<A=20
href=3D"mailto:[email-masked]">[email-masked]</A>&nbsp;or=
 <A=20
href=3D"mailto:[email-masked]">[email-masked]</A>.</FONT></=
SPAN></DIV></BODY></HTML>

------=_NextPart_000_002E_01C39559.7D2FABD0--

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, <[email-masked]>
Cc: "'David Engberg'" <[email-masked]>, "'Alex Deacon'" <[email-masked]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Sat, 18 Oct 2003 12:52:06 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> Because willful disregard of a client's nonce violates first 
> principles.  Enabling service providers a legal basis to do 
> so via reliance on an IETF standard is a whole different question.

It is not a "willful disregard"! A caching responder CANNOT answer
nonces. 

And the IETF standard already defines a "legal basis" for a service
provide to do so: simply not answering the nonce. Thats not a perfect
way - but thats the way RfC2560 suggests.

Can you please tell me where those "first principles" of the IETF you
mention are defined? Where can I read more about it? What "first
principles" do you mean exactly?

Thanks for your help,

-- 
Florian Oelmaier
SyTrust

From: "Florian Oelmaier" <[email-masked]>
To: "'David Engberg'" <[email-masked]>, "'Michael Myers'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Sat, 18 Oct 2003 12:48:49 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

David Engberg wrote:
> Dumb question:  why is it possible to add a new 
> OCSPResponseStatus code 
> value (a non-backward-compatible addition) for v1, but not to convey 
> this information through a new responseExtension in the 
> signed body (a 
> backward compatible change with better security semantics)?

/agree

Even more as all extension procressing is optional, meaning that such an
addition IS completely backward compatible with all clients out there by
definiton. Why did we add the extension system in the first place? I
thought this was done with such extensions in mind.

After all this discussion, we have two options for adding such an
extension:

Option A) "The-signer-of-this-response-intended-it-to-be-cached
extension": Even when the request containes a nonce a responder may
answer with a response containing no nonce but this extension.

Clients supporting nonces should not accept a nonce-less response
without this extension.

Option B) "Usually-I-support-nonce extension": Responders that are able
to generate nonces and get a request without nonce add this extension.
(A responder could also indicate this by producing a server-generated
nonce). 

Clients supporting nonces should not accept responses containing this
extension but NOT containing a fitting nonce. Getting a response without
nonce and without this extension indicates, that the responder is not
able to generate nonces.

Mind: These options do basically the same, we only need one of them.

I strongly vote to include an extension according option A (Davids
proposal) into OCSPv1. 

If this is not possible, I would like to advise all responder
implementers to use Option B with server-generated nonces, as this
behaviour is already covered by OCSPv1 and does not need any changes to
the RfC. For OCSPv2 we should then go for an extension according to
option A.

-- 
Florian Oelmaier
SyTrust

From: "Richard Sinn (Infoblox)" <[email-masked]>
To: "Miguel Rodriguez" <[email-masked]>, "'Michael Myers'" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: POLL: Nonce-specific error code for OCSP
Date: Fri, 17 Oct 2003 18:03:59 -0700
Sender: [email-masked]

NO. 

Clearly after all these discussion. 

- Richard.

----- Original Message ----- 
From: "Miguel Rodriguez" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 17, 2003 6:44 AM
Subject: RE: POLL: Nonce-specific error code for OCSP

> 
> NO
> 
> Miguel A Rodriguez
> SeguriDATA
> Mexico
> 
> > 
> > This poll is focussed on the narrower v1 issue ONLY. Should we
> > or should we not standardize a v1 error code? If this poll is
> > inconclusive, then I suppose we'll get into the heart of the
> > matter, which is whether it is acceptable in v1 to disregard a
> > client's nonce.  But let's leave those discussions to another
> > thread and first get a vote tally.
> > 
> > Mike
> > 
> 
> 
> 

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: "David Engberg" <[email-masked]>, "Alex Deacon" <[email-masked]>
Subject: RE: DISCUSSION: Nonce-specific error code for OCSP
Date: Fri, 17 Oct 2003 15:53:02 -0700
Importance: Normal
Sender: [email-masked]

Because willful disregard of a client's nonce violates first
principles.  Enabling service providers a legal basis to do so
via reliance on an IETF standard is a whole different question.

Mike

> -----Original Message-----
> From: David Engberg [mailto:[email-masked]]
> Sent: Friday, October 17, 2003 2:26 PM
> To: Michael Myers
> Cc: [email-masked]
> Subject: DISCUSSION: Nonce-specific error code for OCSP
>
>
>
> Dumb question:  why is it possible to add a new
> OCSPResponseStatus code value (a non-backward-
> compatible addition) for v1, but not to convey
> this information through a new responseExtension in
> the signed body (a backward compatible change with
> better security semantics)?

Date: Fri, 17 Oct 2003 17:26:28 -0400
From: David Engberg <[email-masked]>
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: DISCUSSION: Nonce-specific error code for OCSP
Sender: [email-masked]

Dumb question:  why is it possible to add a new OCSPResponseStatus code 
value (a non-backward-compatible addition) for v1, but not to convey 
this information through a new responseExtension in the signed body (a 
backward compatible change with better security semantics)?

From: "Miguel Rodriguez" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Fri, 17 Oct 2003 08:44:19 -0500
Importance: Normal
Sender: [email-masked]

NO

Miguel A Rodriguez
SeguriDATA
Mexico

> 
> This poll is focussed on the narrower v1 issue ONLY. Should we
> or should we not standardize a v1 error code? If this poll is
> inconclusive, then I suppose we'll get into the heart of the
> matter, which is whether it is acceptable in v1 to disregard a
> client's nonce.  But let's leave those discussions to another
> thread and first get a vote tally.
> 
> Mike
> 

From: "Joseph A. Doekbrijder" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Fri, 17 Oct 2003 08:17:16 +0200
Organization: SwissSign
Importance: Normal
Sender: [email-masked]

No.

Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: +41 433 44 88 11
Mobile: +41 79 211 24 46
www.swisssign.com
--------------------------------------------------

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Myers
> Sent: Thursday, October 16, 2003 18:05
> To: [email-masked]
> Subject: RE: POLL: Nonce-specific error code for OCSP
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf Of Denis Pinkas
> > Sent: Thursday, October 16, 2003 12:34 AM
> > To: Michael Myers
> > Cc: [email-masked]
> > Subject: Re: POLL: Nonce-specific error code for OCSP
> >
> >
> >
> > Mike,
> >
> > > All,
> >
> > > I recently received permission from the chairs to
> > poll the WG
> > > against the following question.
> >
> > > Should we standardize an OCSP *V1* error code that enables a 
> > > responder to indicate its inability to respond to nonced requests?
> >
> > > Please respond with either YES or NO.
> >
> > I would suggest to you provide a resumé of the
> > advantages of this new error
> > code (and disadvantages if not supported), so that
> > people do not have to
> > look back at that long thread on that topic to make
> > up their opinion.
> >
> > Denis
> >
> > > Mike
> 
> 
> 
> A reasonable request.
> 
> In summary, we need to standardize the treatment of nonces 
> when nonces aren't supported.  RFC2560 is regrettably silent 
> on the point.  The need to do so is particularly acute in the 
> context of heterogeneous populations of clients and servers 
> (i.e. not operating under a single administrative authority). 
>  Some may be set up to use or support nonces and some may 
> not.  The question is of course moot for requests that don't 
> contain nonces.
> 
> The issue is further complicated by the use of pre-produced 
> responses to achieve scalability through caching (i.e.
> non-signing) servers.  A relay back to a master signing 
> server could work, but that doesn't seem to be a popular 
> option.  So that leaves us with two server-side options.  
> Either: 1) send back a non-nonced response anyway with 
> technical extensions; or
> 2) send back an error code.
> 
> Variations on option 1 have been discussed, with the 
> likelihood that an extended response syntax or equivalent 
> technical mechanisms will force a v2 and all that entails 
> with regard to IETF process.
> 
> Yet we also need to do something sooner about v1.  In this 
> case, an existing error could be designated or we could 
> define a new one that servers can send back in the event they 
> don't support nonces.  Absent a designated error code, it is 
> predictable that ad-hoc selections will be made to to address 
> the issue with a consequent reduction in Internet-wide OCSP 
> interoperability and security.
> 
> This poll is focussed on the narrower v1 issue ONLY. Should 
> we or should we not standardize a v1 error code? If this poll 
> is inconclusive, then I suppose we'll get into the heart of 
> the matter, which is whether it is acceptable in v1 to 
> disregard a client's nonce.  But let's leave those 
> discussions to another thread and first get a vote tally.
> 
> Mike
> 
> 
> 

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: DISCUSS: Nonce-specific error code for OCSP
Date: Thu, 16 Oct 2003 20:12:01 -0700
Importance: Normal
Sender: [email-masked]

Julien,

Perhaps this time the subject line modification will stick.  Two
discussion points embedded below.  Apologies in advance for the
abbreviation of your thoughtful comments.

Mike

> -----Original Message-----
> From: Julien Pierre
>
> . . .
>
> What prompted this discussion is that due to
> performance (and other) concerns, a lot of
> people are running caching responders today,
> and want their responses to be accepted by
> clients of type 2.

[mm] To my count, "a lot" is two among the
     twelve server-side implementors who
     responded to the prior poll.

>
> [well-reasoned v2-relevant discussion . . . ]
>

[mm] I agree there exists many variations
     in a v2 context and I agree that this
     WG should consider all such in the
     timeframe of that potential standard.

[mm] Meanwhile, what should we do for v1?
     The current de-facto default is that
     a nonce may be ignored. Does this WG
     support that premise?

Mike

Subject: Re: POLL: Nonce-specific error code for OCSP
To: [email-masked]
Cc: [email-masked]
From: "Frank Balluffi" <[email-masked]>
Date: Thu, 16 Oct 2003 21:35:56 -0400
Sender: [email-masked]

NO

Frank

                      "Michael Myers"                                                                                                  
                      <[email-masked]        To:       <[email-masked]>                                                           
                      >                        cc:                                                                                     
                      Sent by:                 Subject:  POLL: Nonce-specific error code for OCSP                                      
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      

                      10/15/2003 05:02                                                                                                 
                      PM                                                                                                               

All,

I recently received permission from the chairs to poll the WG
against the following question.

Should we standardize an OCSP *V1* error code that enables a
responder to indicate its inability to respond to nonced
requests?

Please respond with either YES or NO.

Mike

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Date: Thu, 16 Oct 2003 17:20:34 -0700
From: [email-masked] (Julien Pierre)
Subject: Re: POLL: Nonce-specific error code for OCSP
To: [email-masked]
cc: [email-masked]
Organization: Netscape
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080802040505
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

NO.

-- 
I am the dog in dogfood

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

--------------ms010704000904080802040505--

Date: Thu, 16 Oct 2003 17:16:19 -0700
From: Julien Pierre <[email-masked]>
Subject: Re: POLL: Nonce-specific error code for OCSP
To: [email-masked]
Reply-to: [email-masked]
Organization: America On-Line, Inc
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060809060100060006010102
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Michael Myers wrote:

>Julien,
>
>I modified the subject line to keep the POLL thread clean for
>votes.
>
>OCSP errors are unsigned to enable handling of DOS-type attacks
>at the edge rather than the core.  This feature was argued in
>favor of those who might deploy this protocol using pre-produced
>responses.
>
The nonce extension was introduced so that clients could make sure that 
they would get fresh responses from a live OCSP responder.
If we add an unsigned error code in the clear to state that the OCSP 
responder is not live and therefore can't sign nonce requests, then the 
purpose of the nonce extension can be easily defeated by a attacker who 
can replay that error code and fool the client into thinking that he is 
not talking to a live responder. I believe that is a security hole that 
defeats the purpose of nonce. This case is much different from DOS 
cases. Due to the other unsigned error codes in OCSP, DOS attacks cannot 
be avoided. But a client can handle them properly, by considering them 
the same as a failure to validate.
On the other hand with this "caching responder" error code, some invalid 
certs that were recently revoked might be considered valid because an 
attacker sent this error code, then served an older good cached response 
for the recently revoked cert. Validating invalid certs is a much more 
serious problem than DOS, in my opinion.

In the end, there are really only two real-world cases, and they come 
down to the OCSP client's policy :
1) If the client is willing to accept pre-produced responses, it should 
not send nonce in the OCSP request. End of story, all signed responses 
are good. The client is subject to replay attacks, but it is aware of 
that fact - that's how it was configured.
2) If the client insists on talking to a live responder, it should send 
nonce in the OCSP request, and check for the same nonce in the OCSP 
response. If they match, the response is accepted, otherwise, they are 
not accepted.

What prompted this discussion is that due to performance (and other) 
concerns, a lot of people are running caching responders today, and want 
their responses to be accepted by clients of type 2.
I don't think that's a good thing because nonce was specifically 
introduced to prevent replay attacks, and as a result, is incompatible 
with caching responders. The clients that send nonce in their requests 
are very few, but they probably have good reasons to do so.

>  That said, presenting a pre-fetched (pre-signed?)
>error response does nothing to mitigate anti-replay.
>
Not true if that response has an expiration time. As I mentioned above, 
to be useful, this signed error response would need to have a validity 
period : ie. between times t1 and t2, this responder may send 
pre-produced responses. If this cached signed response was sent, the 
client could be reasonably sure that the server truly intended to send 
cached responses for that period. This does mean that periodically (when 
t2 comes up), the caching responders would have to refetch this error 
response from the master (live) responder. However it still allows 
caching to work by dramatically reducing the signature operations.
This new type of error response would enable a third type of OCSP client 
policy that is not possible today :

3) Clients that prefer signed OCSP responses, but are willing to accept 
cached responses if the server can convince them that it is a caching 
responder.
They would work by sending a request with nonce. They would only fall 
back to accepting no-nonce responses if they first received a signed 
response with the "caching responder" error code from the responder. And 
they would only accept the pre-produced responses if the time of their 
OCSP requests fell between t1 and t2.

There could also be a statement in the "caching responder" response as 
to the maximum age of the subsequent cached responses. This would 
partially protect against replay attacks from the beginning of time.

I think this is definitely not something to consider for OCSP v1, but it 
can be discussed for v2.

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

--------------ms060809060100060006010102--

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Thu, 16 Oct 2003 16:39:49 -0700
Importance: Normal
Sender: [email-masked]

Julien,

I modified the subject line to keep the POLL thread clean for
votes.

OCSP errors are unsigned to enable handling of DOS-type attacks
at the edge rather than the core.  This feature was argued in
favor of those who might deploy this protocol using pre-produced
responses.  That said, presenting a pre-fetched (pre-signed?)
error response does nothing to mitigate anti-replay.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Julien Pierre
> Sent: Thursday, October 16, 2003 2:28 PM
> To: [email-masked]
> Subject: Re: POLL: Nonce-specific error code for OCSP
>
>
> Florian Oelmaier wrote:
>
> >Rationale:
> >My first idea was to say: if it is OPTIONAL for the
> responder to use that error code it is ok. But in
> fact even the OPTIONAL inclusion harms the security
> of the protocol, as an attacker can fool clients into
> believing a particular OCSP-Responder would not
> support nonces, when in fact it does.
> >
> Agreed. The OCSP responses with error codes are not
> signed, so this
> would present a security hole. We should not let the
> server return this
> error code in an unsigned response.
>
> IMO, it would be acceptable to have an error code
> only if the response
> was signed and included a validity period. Each
> caching responder would
> have to prefetch such a response in order to be able
> to serve it back to
> clients that send nonces.
>
>

content-class: urn:content-classes:message
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Fri, 17 Oct 2003 09:10:13 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

NO

----------
From: Michael Myers [mailto:[email-masked]]
Sent: Thursday, 16 October 2003 7:03 AM

Should we standardize an OCSP *V1* error code that enables a responder to indicate its inability to respond to nonced requests?

Please respond with either YES or NO.

To: IETF-Announce :;
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Last Call: 'X.509 Extensions for IP Addresses and AS Identifiers' to  Proposed Standard 
Reply-to: [email-masked]
Date: Thu, 16 Oct 2003 17:32:25 -0400
Sender: [email-masked]

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

- 'X.509 Extensions for IP Addresses and AS Identifiers'
   <draft-ietf-pkix-x509-ipaddr-as-extn-03.txt> as a Proposed Standard

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

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-03.txt

Date: Thu, 16 Oct 2003 14:27:49 -0700
From: Julien Pierre <[email-masked]>
Subject: Re: POLL: Nonce-specific error code for OCSP
To: [email-masked]
Reply-to: [email-masked]
Organization: America On-Line, Inc
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010503050308040105020007
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Florian Oelmaier wrote:

>Rationale: 
>My first idea was to say: if it is OPTIONAL for the responder to use that error code it is ok. But in fact even the OPTIONAL inclusion harms the security of the protocol, as an attacker can fool clients into believing a particular OCSP-Responder would not support nonces, when in fact it does.
>
Agreed. The OCSP responses with error codes are not signed, so this 
would present a security hole. We should not let the server return this 
error code in an unsigned response.

IMO, it would be acceptable to have an error code only if the response 
was signed and included a validity period. Each caching responder would 
have to prefetch such a response in order to be able to serve it back to 
clients that send nonces.

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

--------------ms010503050308040105020007--

Date: Thu, 16 Oct 2003 13:38:40 -0700
From: "Terry Hayes" <[email-masked]>
Subject: Re: POLL: Nonce-specific error code for OCSP
To: [email-masked]
Organization: AOL
Sender: [email-masked]

NO 

The response should be as if the nonce extension was not present in the request. An 
implementation that does not support nonces should simply ignore the extension and 
generate (provide) a non-nonced response. 

The error code does not serve any purpose. Since, the error response is not signed, the 
client cannot use it to implement a policy that allows using a non-nonced response 
in cases where the server does not support nonces.  I believe this is one proposed use 
of this error code. 

Terry 

Michael Myers wrote on 10/15/2003, 2:02 PM: 

All, 

I recently received permission from the chairs to poll the WG 
against the following question. 

Should we standardize an OCSP *V1* error code that enables a 
responder to indicate its inability to respond to nonced 
requests? 

Please respond with either YES or NO. 

Mike 

Date: Thu, 16 Oct 2003 10:36:59 -0700
From: Richard Sinn <[email-masked]>
To: Michael Myers <[email-masked]>, [email-masked]
Subject: Re: POLL: Nonce-specific error code for OCSP
Sender: [email-masked]

YES.

In general, the less information given out, the more secure the 
environment is. However, if I view OCSP could run in two different 
modes, one with nonce and one without, then, an error code will be 
useful to indicate which type of responder is out there. However, I 
agree with Denis, a resume of advantages vs disadvantages would be 
useful ... just do not want to miss anything.

Thanks,

Richard Sinn
Infoblox, Inc.

Michael Myers wrote:

>All,
>
>I recently received permission from the chairs to poll the WG
>against the following question.
>
>Should we standardize an OCSP *V1* error code that enables a
>responder to indicate its inability to respond to nonced
>requests?
>
>Please respond with either YES or NO.
>
>Mike
>
>
>
>  
>

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Thu, 16 Oct 2003 09:05:09 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Thursday, October 16, 2003 12:34 AM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: POLL: Nonce-specific error code for OCSP
>
>
>
> Mike,
>
> > All,
>
> > I recently received permission from the chairs to
> poll the WG
> > against the following question.
>
> > Should we standardize an OCSP *V1* error code that enables a
> > responder to indicate its inability to respond to nonced
> > requests?
>
> > Please respond with either YES or NO.
>
> I would suggest to you provide a resumé of the
> advantages of this new error
> code (and disadvantages if not supported), so that
> people do not have to
> look back at that long thread on that topic to make
> up their opinion.
>
> Denis
>
> > Mike

A reasonable request.

In summary, we need to standardize the treatment of nonces when
nonces aren't supported.  RFC2560 is regrettably silent on the
point.  The need to do so is particularly acute in the context
of heterogeneous populations of clients and servers (i.e. not
operating under a single administrative authority).  Some may be
set up to use or support nonces and some may not.  The question
is of course moot for requests that don't contain nonces.

The issue is further complicated by the use of pre-produced
responses to achieve scalability through caching (i.e.
non-signing) servers.  A relay back to a master signing server
could work, but that doesn't seem to be a popular option.  So
that leaves us with two server-side options.  Either: 1) send
back a non-nonced response anyway with technical extensions; or
2) send back an error code.

Variations on option 1 have been discussed, with the likelihood
that an extended response syntax or equivalent technical
mechanisms will force a v2 and all that entails with regard to
IETF process.

Yet we also need to do something sooner about v1.  In this case,
an existing error could be designated or we could define a new
one that servers can send back in the event they don't support
nonces.  Absent a designated error code, it is predictable that
ad-hoc selections will be made to to address the issue with a
consequent reduction in Internet-wide OCSP interoperability and
security.

This poll is focussed on the narrower v1 issue ONLY. Should we
or should we not standardize a v1 error code? If this poll is
inconclusive, then I suppose we'll get into the heart of the
matter, which is whether it is acceptable in v1 to disregard a
client's nonce.  But let's leave those discussions to another
thread and first get a vote tally.

Mike

Reply-To: <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, <[email-masked]>
Subject: RE: POLL: Nonce-specific error code for OCSP
Date: Thu, 16 Oct 2003 15:26:37 +0100
Importance: Normal
Sender: [email-masked]

NO

Not really needed in my opinion, generally the person (i.e. an
administrator) setting up the OCSP client software will know upfront the
capabilities of the responders that will be accessed by the OCSP client
and therefore configure the client accordingly (i.e. with or without
nonce).  

In the case that OCSP clients are dealing with random, previously
unknown OCSP responders, then such an error code may have some use in
pin-pointing the problem from the various things that may go wrong.  But
I don't think the limited value it adds is worth the change.  

Anyway, I agree with Denis, a summary would be useful though...in case I
have missed something important somewhere down the line...

Regards,
LK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: 15 October 2003 22:03
To: [email-masked]
Subject: POLL: Nonce-specific error code for OCSP

All,

I recently received permission from the chairs to poll the WG
against the following question.

Should we standardize an OCSP *V1* error code that enables a
responder to indicate its inability to respond to nonced
requests?

Please respond with either YES or NO.

Mike

Date: 16 Oct 2003 08:48:41 -0000
From: "Florian Oelmaier" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Subject: Re: POLL: Nonce-specific error code for OCSP
Sender: [email-masked]

> Should we standardize an OCSP *V1* error code that enables a
> responder to indicate its inability to respond to nonced
> requests?
> 
> Please respond with either YES or NO.

NO

Rationale: 
My first idea was to say: if it is OPTIONAL for the responder to use that error code it is ok. But in fact even the OPTIONAL inclusion harms the security of the protocol, as an attacker can fool clients into believing a particular OCSP-Responder would not support nonces, when in fact it does.

My conclusion: Dont include such an error code, due to security reasons. If other reasons (yet unknown to me) overrule these concerns make the use of this error code OPTIONAL for responders to allow compatibility with existing installations and not to harm the functionality of the protocol.

-- 
Florian Oelmaier
SyTrust

Date: Thu, 16 Oct 2003 09:34:09 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: POLL: Nonce-specific error code for OCSP
Sender: [email-masked]

Mike,

> All,

> I recently received permission from the chairs to poll the WG
> against the following question.

> Should we standardize an OCSP *V1* error code that enables a
> responder to indicate its inability to respond to nonced
> requests?

> Please respond with either YES or NO.

I would suggest to you provide a resumé of the advantages of this new error 
code (and disadvantages if not supported), so that people do not have to 
look back at that long thread on that topic to make up their opinion.

Denis

> Mike

Date: Wed, 15 Oct 2003 18:29:24 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft-ietf-pkix-x509-ipaddr-as-extn-03.txt
Cc: russ housley <[email-masked]>
Sender: [email-masked]

The subject ID was revised in response to comments during last call, 
and the new version was posted late last month, so I am now 
forwarding it to Russ Housely for IESG review.

Steve

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: POLL: Nonce-specific error code for OCSP
Date: Wed, 15 Oct 2003 14:02:39 -0700
Importance: Normal
Sender: [email-masked]

All,

I recently received permission from the chairs to poll the WG
against the following question.

Should we standardize an OCSP *V1* error code that enables a
responder to indicate its inability to respond to nonced
requests?

Please respond with either YES or NO.

Mike

Date: Sat, 11 Oct 2003 02:46:07 +0900
From: Nakagawa <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Subject: Re: request for reviewing our interoperability experiment report
Cc: <[email-masked]>
Sender: [email-masked]

Dear Rundgren-san,

Thank you for your comment, and very sorry for my late reply.
I conveyed your opinion to our team and am waiting for their comment.
If I get any, I'll post it to this mailing list ASAP. Anyway, we'll take
your comment into consideration when we have chance to revise
the Final Report.

Best Regards,

Nakagawa
Japan PKI Forum

----------------------- Original Message -----------------------
On Tue, 30 Sep 2003 13:23:43 +0200
"Anders Rundgren" <[email-masked]> wrote:

> 
> Dear Nakagawa-San,
> May I offer some comments not so much on the report itself, but
> on the architectures that you are working with?  The described
> CA structures represent one of three IMO entirely different ways
> to apply PKI:
> 
> 1. The "Classic".  Often using Cross-Certification (CC) and is fairly complex. 
>     Used by the FED-PKI and the PKIs described in the report.  Adding
>     CP extensions as "application trust filters", things get even more complex
>     to scale-up as the extensions are (and will likely continue to be) never
>     agreed upon except within certain "communities".  It is interesting to
>     note that AFAIK, no commercial TTP CA make their
>     issuance depending on CP extensions.  I.e., they all use the
>    "universal issuing formula" CA <=> Policy.
> 
> 2. Relying-party-only.   RP=CA.  Limited interoperability concerns but
>     potentially awkward out-of-band RA-arrangements when the number
>     of external partners increase.
> 
> 3. The bank-model PKI [*].  Builds on legacy IT architectures and is
>     simpler (but magnitudes more flexible) compared to the "Classic".
> Short "promotional" description: http://www.x-obi.com/OBI400/b2bsign.pdf
> Long(-winding) description: http://www.x-obi.com/OBI400/pki4org.pdf
> 
> Regarding interoperability I noted that you did not mention the four-corner
> model which if I'm not misinformed possibly to be used by the coming Japanese
> government PKI hosted by Identrus.  This system eliminates CC and
> interoperability (as it is a closed trust-network) but dramatically
> complicates RP software handling as there are no standards for
> managing independent (they all are) four-corner trust-networks.
> Most of these competing trust-networks require you to pay license
> fees and only use certified software.  This is how the Swedish
> banks currently operate.  A short [negative] description of four-corner:
> http://www.x-obi.com/OBI400/e-government-ID-A.Rundgren.pdf
> 
> Press-release indicating that the Japanese government indeed
> is considering supporting four-corner models:
> http://www.identrus.com/company/press_releases/release_030717.html
> 
> Regards
> Anders Rundgren
> 
> *] My participation in more or less related standards:
> http://shibboleth.internet2.edu/minutes/SHIB-05-Sept-2001.html
> 
> 
> ----- Original Message ----- 
> From: "Nakagawa" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, September 29, 2003 11:50
> Subject: request for reviewing our interoperability experiment report
> 
> 
> 
> Dear PKIX list members,
> 
> Korea PKI Forum, PKI Forum Singapore, Chinese Taipei PKI Forum, and Japan
> PKI Forum are pleased to announce the completion of the Final Report for
> the Experiment in PKI Interoperability in Asia region in 2002. These
> four countries/areas have been conducting the Experiment in PKI
> interoperability since 2001, and compiled the first report for the 2001
> experiment in the middle of 2002. A report compiled this time is
> extended version of the previous one. 
> 
> In 2002, we have conducted 3 experiments as follows: 
> 
> 1) CA-CA Interoperability Experiment with Cross Certification / Cross
> Recognition models;
> 
> 2) Path Processing Experiment intending to Resolve the certificate path
> processing issues of repository by clarifying the path processing logic
> described in RFC3280;
> 
> 3) PKCS#11 Experiment tempting to approach PKI application
> interoperability using a commonly defined API (application interface).
> The Final Report contains the recommended technical specifications and
> the lessons learnt, which are valuable for CA operators, VA (validation
> authority) and application developers when dealing with relevant
> interoperability matters.
> 
> In addition to this overall project result document, other five documents
> were developed as appendixes, which are: 
> - Appendix 1. IWG Recommended Profiles
> - Appendix 2. CA-CA Interoperability Interface Specification for
> experiment
> - Appendix 3. Certificate Path Processing Implementation Guideline
> - Appendix 4. Certificate Path Processing Testing Guideline
> - Appendix 5. PKCS#11 Testing
> 
> It will be highly appreciated if IETF members examine the
> report and let us know your thoughts/comments.
> You can download the report and the appendix from:
> 
> Achieving PKI Interoperability 2003 -Results of the JKST-IWG Interoperability project-
> http://www.japanpkiforum.jp/shiryou/IWG_2002/FinalReport2003-Version1.0.pdf
> Appendix
> http://www.japanpkiforum.jp/shiryou/IWG_2002/Appendix.pdf
> 
> Regards,
> 
> -- 
> Hiroyuki Nakagawa
> Japan PKI Forum

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Tim Polk" <[email-masked]>, "Carlisle Adams" <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Sat, 4 Oct 2003 07:47:48 -0700
Importance: Normal
Sender: [email-masked]

Well, it certainly wasn't in *my* mind at the time that nonces,
if used, would be ignored.  To my recollection, the discussions
between Carlisle and myself that lead to their definition were
quite robust on the point.

Indeed, as the poll indicates something close to 11 of 12 of
client side implementors treat (or can treat) the practice as an
error.  So it's not like this is a great revelation to anybody.
Yes, extensions are optional.  But extensions may have
additional semantics associated with their use.  The fact that
the definition of the nonce extension does not is where we got
started with a view towards clarifying original intent.

Since nonces break caching, don't use nonces in a cached
environment.  Send a non-nonced response anyway due to
server-side lack of control on the client side?  Maybe.  If the
chairs and the AD are comfortable allowing the IETF to
standardize the practice, I'd be happy to oblige.

Mike

From: "Florian Oelmaier" <[email-masked]>
To: "'Jean-Marc Desperrier'" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Sat, 4 Oct 2003 04:05:33 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> >>- re-assert that it is not conformant to RFC2560 to send back
> >>a response 
> >>without to nonce to a request requiring a nonce (it might 
> >>change in OCSPv2)
> > 
> > The RfC states: "[A request includes] [...] optional 
> extensions which 
> > MAY be processed by the OCSP Responder".
> 
> I don't know.
> This is not in line with RFC3280 definition of extensions, in 
> which if 
> you *do* recognize an extension, you have to treat it 
> correctly and not 
> simply ignore it.
> With that definition if you implement RFC2560, you can say I 
> don't know 
> what id-pkix-ocsp-nonce means so I don't care about it, because it's 
> defined in the standard.

You are partly right for RfC3280 - while it in fact lists some
extensions that SHALL be recognized by CAs/applications, in general
extension are optional. The exact wording of RfC3280 is:

"A certificate using system MUST reject the certificate if it encounters
a critical extension it does not recognize; however, a non-critical
extension MAY be ignored if it is not recognized. [...] [List of
extensions CAs and Applications SHOULD recognize] Support for the
remaining extensions is OPTIONAL." [nearly same wording for CRLs]

Nevertheless the wording of RfC3280 and RfC2560 is very different. If we
apply the rationale behind RfC3280 to RfC2560, we should allow a client
to mark his nonce-extension critical, thus indicating that it does not
wish that any responder ignores the nonce. But currently RfC2560 states
clearly: 

"Support for any specific extension is OPTIONAL. The critical flag
SHOULD NOT be set for any of them."

Allowing an extension (e.g. the nonce-extension) to be critical would be
a change to RfC2560. I would really like such a change, but as Ambarish
already pointed out, this may put an unwanted semantic into the requests
of some existing clients out there. As these clients adhere to RfC2560,
the nonce is not critical - thus they would indicate that a nonceless
response is ok for them.

Remark: With this whole system, we have not yet solved the problem
adressed by David's proposal: A client wants to know securely if a
response without nonce was generated by an OCSP-responder not supporting
nonces or by an OCSP-responder normally being able to generate nonces. 

-- 
Florian Oelmaier
SyTrust

From: "Deacon, Alex" <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, "'Michael Myers'" <[email-masked]>, "'Jean-Marc Desperrier'" <[email-masked]>, [email-masked]
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 15:54:49 -0700 
Sender: [email-masked]

Yes, I have an issue with "re-assert[ing] that it is not conformant to
RFC2560 to send back a response without to nonce to a request requiring a
nonce"

You can't re-assert something that was never asserted in the first place.
The current spec does not mandate that servers support extensions in OCSP
requests. (as Florian pointed out in a recent email)  Mandating that servers
MUST respond to a nonce extension would make currently compliant responders
non-compliant.   Not good...

Alex

> -----Original Message-----
> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Friday, October 03, 2003 10:35 AM
> To: 'Michael Myers'; 'Jean-Marc Desperrier'; [email-masked]
> Subject: RE: OCSP response pre-production
> 
> 
> 
> 
> Yup, sounds good to me. Is there rough concensus that this is what
> folks want? Anybody with a strong opinion to the contrary, please
> pipe up now.
> 
> Regards,
> Ambarish
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Michael Myers
> > Sent: Friday, October 03, 2003 9:17 AM
> > To: Jean-Marc Desperrier; [email-masked]
> > Subject: RE: OCSP response pre-production
> > 
> > 
> > 
> > 
> > This works for me, especially the part about getting 
> > definitive on 2560 as it stands.  Ambarish?
> > 
> > Mike
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]]On Behalf Of Jean-Marc 
> > Desperrier
> > > Sent: Friday, October 03, 2003 8:09 AM
> > > To: [email-masked]
> > > Subject: Re: OCSP response pre-production
> > >
> > >
> > >
> > > Frank Balluffi wrote:
> > > > My preference would be to define an extension (e.g., via an 
> > > > informational RFC) that can be used with v1 bits on
> > > the wire, and
> > > > then to formally incorporate the extension into v2.
> > > Again, if a
> > > > strong case can be made for v2 to use a different
> > > mechanism (than the
> > > > extension defined above), I am OK with that.
> > >
> > > I know understand better the case against the
> > > round-trip error discovery
> > > solution without a signed assertion from server.
> > >
> > > I think the above solution is something everybody can
> > > agree on, and stop
> > > discussing the point for ever.
> > >
> > > So can everybody agree on creating an informationnal
> > > RFC about how to
> > > handle cache response in OCSP v1 that would :
> > >
> > > - define an extension that enable a responder to
> > > assert the answer is a
> > > cached answer and not an answer to a nonce-less request
> > >
> > > - [MAYBE] define a value for that extension that says
> > > this answer does
> > > not include a nonce, but that the server can provide
> > > one if requested
> > >
> > > - re-assert that it is not conformant to RFC2560 to
> > > send back a response
> > > without to nonce to a request requiring a nonce (it
> > > might change in OCSPv2)
> > >
> > > - precise what error amongst the already defined one
> > > the OCSP server
> > > should send back when receiving a nonce if it can not
> > > send one back
> > >
> > > - describe that a client who wants the best possible
> > > answer can :
> > > * Ask for a nonce
> > > * Receive an error
> > > * Ask without nonce
> > > * Receive an answer that includes the extension that
> > > the server can not
> > > able to include nonces in answers.
> > >
> > > - describe another possible solution :
> > > * Don't ask for a nonce
> > > * Receive an answer that includes the extension that
> > > the server can
> > > include nonces in answers.
> > > * Ask with a nonce, because I want the very best I can have.
> > >
> > > The second solution might be better if the servers
> > > that send back cached
> > > answer have a very heavy load and want to avoid the 
> > round-trip, whilst
> > > the one that are ready to provide nonces are more
> > > likely not to have a
> > > problem with round-trips.
> > >
> > > An evolution could then be included in OCSPv2 to
> > > avoid the round-trip
> > > completely.
> > >
> > >
> > 
> > 
> 

From: "Florian Oelmaier" <[email-masked]>
To: "'Jean-Marc Desperrier'" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 23:23:00 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> What would you think if it'd also define an extension that the client 
> can use in a request including a nonce, in order to indicate it will 
> accept an answer without a nonce if it includes the 
> pre-produced extension.

If we do that, I agree with your course, Jean-Marc. Otherwise I would
feel strongly against it. In any case I would vote to go with Davids
proposal - it seems more simple to me while accomplishing the same task
with additional security.

> The server would be breaking RFC 2560 by sending back the 
> pre-produced 
> answer, but only with a client that has explicitly indicated it is 
> expecting this behaviour.

Once again: RfC2560 allows sending of nonceless responses to nonced
requests. It clearly states that processing of every extension (and
"nonce" is an extension) is optional for both responder and client. And
OPTIONAL is clearly defined. So if we define that request-extension, the
responder would be fully on the ground of RfC2560. 

In fact I would bet that currently nearly all caching servers send back
nonceless responses to nonced requests - as this is what the RfC seems
to suggest in ist current wording. At least this is what our responder
does when configured for caching.

-- 
Florian Oelmaier
SyTrust

Date: Fri, 03 Oct 2003 21:59:54 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

Florian Oelmaier wrote:
>>- re-assert that it is not conformant to RFC2560 to send back 
>>a response 
>>without to nonce to a request requiring a nonce (it might 
>>change in OCSPv2)
> 
> The RfC states: "[A request includes] [...] optional extensions which
> MAY be processed by the OCSP Responder". 

I don't know.
This is not in line with RFC3280 definition of extensions, in which if 
you *do* recognize an extension, you have to treat it correctly and not 
simply ignore it.
With that definition if you implement RFC2560, you can say I don't know 
what id-pkix-ocsp-nonce means so I don't care about it, because it's 
defined in the standard.

From: "Florian Oelmaier" <[email-masked]>
To: "'Jean-Marc Desperrier'" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 20:35:41 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> - re-assert that it is not conformant to RFC2560 to send back 
> a response 
> without to nonce to a request requiring a nonce (it might 
> change in OCSPv2)

The RfC states: "[A request includes] [...] optional extensions which
MAY be processed by the OCSP Responder". With the clear definition of
MAY according to RfC 2119:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

When writing such an informational RfC we also have to clarify that
extension processing is not optional anymore with this change (as every
responder MUST detect a nonce).

-- 
Florian Oelmaier
SyTrust

Date: Fri, 03 Oct 2003 19:52:41 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

Michael Myers wrote:
> This works for me, especially the part about getting definitive
> on 2560 as it stands.  Ambarish?

I've been thinking about something more, I hope it doesn't reopen the 
whole can of worms.

What would you think if it'd also define an extension that the client 
can use in a request including a nonce, in order to indicate it will 
accept an answer without a nonce if it includes the pre-produced extension.

The server would be breaking RFC 2560 by sending back the pre-produced 
answer, but only with a client that has explicitly indicated it is 
expecting this behaviour.

This, if acceptable, would enable to fully avoid the round-trip with 
compatible servers.
Legacy servers would send back an error to this kind of request if they 
can not supply a nonce, which does not break the expected behaviour.

>> - define an extension that enable a responder to
>> assert the answer is a
>> cached answer and not an answer to a nonce-less request

I'll correct myself : "is a pre-produced answer and this server can not 
successfully answer requests requiring a nonce."

From: "Ambarish Malpani" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, "'Jean-Marc Desperrier'" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 10:34:40 -0700
Importance: Normal
Sender: [email-masked]

Yup, sounds good to me. Is there rough concensus that this is what
folks want? Anybody with a strong opinion to the contrary, please
pipe up now.

Regards,
Ambarish

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Myers
> Sent: Friday, October 03, 2003 9:17 AM
> To: Jean-Marc Desperrier; [email-masked]
> Subject: RE: OCSP response pre-production
> 
> 
> 
> 
> This works for me, especially the part about getting 
> definitive on 2560 as it stands.  Ambarish?
> 
> Mike
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf Of Jean-Marc 
> Desperrier
> > Sent: Friday, October 03, 2003 8:09 AM
> > To: [email-masked]
> > Subject: Re: OCSP response pre-production
> >
> >
> >
> > Frank Balluffi wrote:
> > > My preference would be to define an extension (e.g., via an 
> > > informational RFC) that can be used with v1 bits on
> > the wire, and
> > > then to formally incorporate the extension into v2.
> > Again, if a
> > > strong case can be made for v2 to use a different
> > mechanism (than the
> > > extension defined above), I am OK with that.
> >
> > I know understand better the case against the
> > round-trip error discovery
> > solution without a signed assertion from server.
> >
> > I think the above solution is something everybody can
> > agree on, and stop
> > discussing the point for ever.
> >
> > So can everybody agree on creating an informationnal
> > RFC about how to
> > handle cache response in OCSP v1 that would :
> >
> > - define an extension that enable a responder to
> > assert the answer is a
> > cached answer and not an answer to a nonce-less request
> >
> > - [MAYBE] define a value for that extension that says
> > this answer does
> > not include a nonce, but that the server can provide
> > one if requested
> >
> > - re-assert that it is not conformant to RFC2560 to
> > send back a response
> > without to nonce to a request requiring a nonce (it
> > might change in OCSPv2)
> >
> > - precise what error amongst the already defined one
> > the OCSP server
> > should send back when receiving a nonce if it can not
> > send one back
> >
> > - describe that a client who wants the best possible
> > answer can :
> > * Ask for a nonce
> > * Receive an error
> > * Ask without nonce
> > * Receive an answer that includes the extension that
> > the server can not
> > able to include nonces in answers.
> >
> > - describe another possible solution :
> > * Don't ask for a nonce
> > * Receive an answer that includes the extension that
> > the server can
> > include nonces in answers.
> > * Ask with a nonce, because I want the very best I can have.
> >
> > The second solution might be better if the servers
> > that send back cached
> > answer have a very heavy load and want to avoid the 
> round-trip, whilst
> > the one that are ready to provide nonces are more
> > likely not to have a
> > problem with round-trips.
> >
> > An evolution could then be included in OCSPv2 to
> > avoid the round-trip
> > completely.
> >
> >
> 
> 

From: "Michael Myers" <[email-masked]>
To: "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 09:16:31 -0700
Importance: Normal
Sender: [email-masked]

This works for me, especially the part about getting definitive
on 2560 as it stands.  Ambarish?

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Jean-Marc Desperrier
> Sent: Friday, October 03, 2003 8:09 AM
> To: [email-masked]
> Subject: Re: OCSP response pre-production
>
>
>
> Frank Balluffi wrote:
> > My preference would be to define an extension (e.g., via an
> > informational RFC) that can be used with v1 bits on
> the wire, and
> > then to formally incorporate the extension into v2.
> Again, if a
> > strong case can be made for v2 to use a different
> mechanism (than the
> > extension defined above), I am OK with that.
>
> I know understand better the case against the
> round-trip error discovery
> solution without a signed assertion from server.
>
> I think the above solution is something everybody can
> agree on, and stop
> discussing the point for ever.
>
> So can everybody agree on creating an informationnal
> RFC about how to
> handle cache response in OCSP v1 that would :
>
> - define an extension that enable a responder to
> assert the answer is a
> cached answer and not an answer to a nonce-less request
>
> - [MAYBE] define a value for that extension that says
> this answer does
> not include a nonce, but that the server can provide
> one if requested
>
> - re-assert that it is not conformant to RFC2560 to
> send back a response
> without to nonce to a request requiring a nonce (it
> might change in OCSPv2)
>
> - precise what error amongst the already defined one
> the OCSP server
> should send back when receiving a nonce if it can not
> send one back
>
> - describe that a client who wants the best possible
> answer can :
> * Ask for a nonce
> * Receive an error
> * Ask without nonce
> * Receive an answer that includes the extension that
> the server can not
> able to include nonces in answers.
>
> - describe another possible solution :
> * Don't ask for a nonce
> * Receive an answer that includes the extension that
> the server can
> include nonces in answers.
> * Ask with a nonce, because I want the very best I can have.
>
> The second solution might be better if the servers
> that send back cached
> answer have a very heavy load and want to avoid the
> round-trip, whilst
> the one that are ready to provide nonces are more
> likely not to have a
> problem with round-trips.
>
> An evolution could then be included in OCSPv2 to
> avoid the round-trip
> completely.
>
>

Date: Fri, 03 Oct 2003 17:09:16 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

Frank Balluffi wrote:
> My preference would be to define an extension (e.g., via an 
> informational RFC) that can be used with v1 bits on the wire, and
> then to formally incorporate the extension into v2. Again, if a
> strong case can be made for v2 to use a different mechanism (than the
> extension defined above), I am OK with that.

I know understand better the case against the round-trip error discovery 
solution without a signed assertion from server.

I think the above solution is something everybody can agree on, and stop 
discussing the point for ever.

So can everybody agree on creating an informationnal RFC about how to 
handle cache response in OCSP v1 that would :

- define an extension that enable a responder to assert the answer is a 
cached answer and not an answer to a nonce-less request

- [MAYBE] define a value for that extension that says this answer does 
not include a nonce, but that the server can provide one if requested

- re-assert that it is not conformant to RFC2560 to send back a response 
without to nonce to a request requiring a nonce (it might change in OCSPv2)

- precise what error amongst the already defined one the OCSP server 
should send back when receiving a nonce if it can not send one back

- describe that a client who wants the best possible answer can :
* Ask for a nonce
* Receive an error
* Ask without nonce
* Receive an answer that includes the extension that the server can not 
able to include nonces in answers.

- describe another possible solution :
* Don't ask for a nonce
* Receive an answer that includes the extension that the server can 
include nonces in answers.
* Ask with a nonce, because I want the very best I can have.

The second solution might be better if the servers that send back cached 
answer have a very heavy load and want to avoid the round-trip, whilst 
the one that are ready to provide nonces are more likely not to have a 
problem with round-trips.

An evolution could then be included in OCSPv2 to avoid the round-trip 
completely.

Subject: RE: OCSP response pre-production
To: [email-masked]
Cc: [email-masked]
From: "Frank Balluffi" <[email-masked]>
Date: Fri, 3 Oct 2003 10:08:41 -0400
Sender: [email-masked]

Please disregard "Again," below. It referred to something I deleted before sending.

Frank

                      "Frank Balluffi"                                                                                                     
                      <frank.balluffi+exter        To:       [email-masked]                                                              
                      [email-masked]>                  cc:       [email-masked]                                                             
                      Sent by:                     Subject:  RE: OCSP response pre-production                                              
                      owner-ietf-pkix@mail.                                                                                                
                      imc.org                                                                                                              

                      10/03/2003 09:11 AM                                                                                                  

Mike,

My preference would be to define an extension (e.g., via an informational RFC) that can be used with v1 bits on the wire, and then to formally incorporate the extension into v2. Again, if a strong case can be made for v2 to use a different mechanism (than the extension defined above), I am OK with that.

I hope this answers your question.

Frank

                      "Michael Myers"
                      <[email-masked]        To:       Frank Balluffi/NewYork/DBNA/DeuBa@DBNA, <[email-masked]>
                      >                        cc:       "David Engberg" <[email-masked]>, <[email-masked]>
                      Sent by:                 Subject:  RE: OCSP response pre-production
                      owner-ietf-pkix@m
                      ail.imc.org

                      10/02/2003 06:08
                      PM

> -----Original Message-----
> From: Frank Balluffi
>
> . . .
>
> I too like the proposal to use a flag or an
> extension. Perhaps an extension could say the
> equivalent of, "This is a cached response."

Frank,

Would you object the v1/v2 dual paths as means of getting this
into place?

Mike

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

From: "Peter Hesse" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt
Date: Fri, 3 Oct 2003 09:17:55 -0400
Organization: Gemini Security Solutions, Inc.
Importance: Normal
Sender: [email-masked]

All,

To save everyone the trouble of trying to read through our entire
internet draft a second time, the following lists outline the main
changes made in the document since version 00.

Overall changes:
- made certain terminology more consistent ("certification 
   path" throughout the document instead of "certificate path", 
   "cert path", etc.)
- softened the tone; made it clear that the document provides 
   informational recommendations and does not prescribe a 
   particular method for certification path building
- removed statements on the document providing guidance based 
   on "best practices" but instead explicitly defined the 
   motivation and purpose behind the document, as well as the 
   criteria that led to the guidance provided. 
- removed some non-ascii characters that had snuck in

Specific changes:
- Thoroughly updated section 1.1 (Motivation) and 1.2 (Purpose)
- updated terminology section to include a few additional terms
- updated mesh PKI figure to better differentiate it from other
   structures
- included a section (2.2) that clearly identifies the authors'
   criteria for a path building implementation
- broke up section 2.4 (How to Build a Certification Path) with
   some subsections
- added section 3.3 (Representing the Decision Tree 
   Programmatically)
- updated section 3.5 to include additional information about 
   the sorting methods that follow.  Sorting methods are no 
   longer called "rules".
- added section 5.4 (Distinguished Name Encoding)
- added section 6.3 (Subject Information Access)

Cheers,

--Peter Hesse

+---------------------------------------------------------------+
| Peter Hesse                    [email-masked]     |
| Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Thursday, October 02, 2003 10:51 AM
To: IETF-Announce:; [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt

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

	Title		: Internet X.509 Public Key Infrastructure:

                          Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow et al.
	Filename	: draft-ietf-pkix-certpathbuild-01.txt
	Pages		: 67
	Date		: 2003-10-2
	
This document was written to provide guidance and recommendations to 
developers building X.509 public-key certification paths within their 
applications.  By following the guidance and recommendations defined 
in this document, an application developer is more likely to develop 
a robust X.509 certificate enabled application that can build valid 
certification paths across a wide range of PKI environments.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the
message.

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-certpathbuild-01.txt".

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

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

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

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

Subject: RE: OCSP response pre-production
To: [email-masked]
Cc: [email-masked]
From: "Frank Balluffi" <[email-masked]>
Date: Fri, 3 Oct 2003 09:11:15 -0400
Sender: [email-masked]

Mike,

My preference would be to define an extension (e.g., via an informational RFC) that can be used with v1 bits on the wire, and then to formally incorporate the extension into v2. Again, if a strong case can be made for v2 to use a different mechanism (than the extension defined above), I am OK with that.

I hope this answers your question.

Frank

                      "Michael Myers"                                                                                                  
                      <[email-masked]        To:       Frank Balluffi/NewYork/DBNA/DeuBa@DBNA, <[email-masked]>                  
                      >                        cc:       "David Engberg" <[email-masked]>, <[email-masked]>                    
                      Sent by:                 Subject:  RE: OCSP response pre-production                                              
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      

                      10/02/2003 06:08                                                                                                 
                      PM                                                                                                               

> -----Original Message-----
> From: Frank Balluffi
>
> . . .
>
> I too like the proposal to use a flag or an
> extension. Perhaps an extension could say the
> equivalent of, "This is a cached response."

Frank,

Would you object the v1/v2 dual paths as means of getting this
into place?

Mike

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, "'David Engberg'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 13:13:56 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

Michael,

> [...] An 
> environment called to task by a security auditor for sending 
> a canned response to a nonced request, the latter which by 
> technical definition is an assertion by a relying party that 
> the RP does NOT wish to receive a canned response, can very 
> easily send back any unsigned error.  

I want to comment two points here:

1) the "technical definition" you give in the sentence above: "[sending]
a nonced request [is by] technical definition [an] assertion by a
relying party [client] that the RP [client] does NOT wish to receive a
canned [pre-produced/cached] response".

I think the discussion here on the list shows that your "technical
definition" is not common ground here. It is NOT what I think and it is
NOT what RfC2560 states. There is another definition supported by
RfC2560 and some people here on the list: "A client sending a nonce
expresses its wish to get a nonced response."

>From my point of view this discussion showed:

A) your definition is not covered in RfC2560
B) there are multiple clients out there that make use of the benefits of
the definition as stated in RfC2560
C) there are multiple installations out there relying on these benefits

If you want to add such a change to the definition into the current
wording of RfC2560 one way or the other I think YOU are calling for
OCSPv2 - as this is a major change to some/many installations out there.

But I think thats the point where our discussion started :(

> [...] An 
> environment called to task by a security auditor for sending 
> a canned response to a nonced request, the latter which by 
> technical definition is an assertion by a relying party that 
> the RP does NOT wish to receive a canned response, can very 
> easily send back any unsigned error. It's best if we at least 
> standardize one for interoperability if nothing else.

2) I am not against an additional error message, as long as its use is
OPTIONAL for the responder and the current behaviour of the responders
(sending a non-nonced response back) is allowed, too. We can readily go
for a wording like this, if you need this error response urgently:

"If a responder cannot process a nonce he SHALL indicate this by sending
an error status "NonceNotAllowed" or by sending a response without
nonce."

-- 
Florian Oelmaier
SyTrust

From: "Michael Myers" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "'David Engberg'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 19:03:18 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Florian Oelmaier
>
> . . .
>
> I am not a friend of adding an error message that
> adds nothing to the security of the protocol but
> introduces the need for a second round-trip
> into OCSPv1. As a client cannot really rely on the
> error message the situation will not get better.
> From a security point of view, the proposed error
> message does not bring any advantage (as it can be
> faked), technically it introduces the disadvantage of
> having to do two requests.
>
> *** I therefore suggest to leave OCSPv1 as it is
> (instead of making it worse) and work with Davids
> extension to go in for OCSPv2. ***

Florian,

As I've been trying to explain, the capability for
error-triggered nonce discovery is already in place.  An
environment called to task by a security auditor for sending a
canned response to a nonced request, the latter which by
technical definition is an assertion by a relying party that the
RP does NOT wish to receive a canned response, can very easily
send back any unsigned error.  It's best if we at least
standardize one for interoperability if nothing else.

Mike

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, "'David Engberg'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 3 Oct 2003 03:18:03 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> The simple fix I most recently proposed could, I believe, be 
> applied to RFC 2560 as it progresses from Proposed to Draft 
> due to the poll's consensus.  Meanwhile, I strongly suspect 
> that the syntax and semantic changes of more sophisticated 
> solutions will force a version delta, a new I-D and all that 
> entails regarding WG, IETF and IESG ratification.  That is, OCSPv2.

I am not a friend of adding an error message that adds nothing to the
security of the protocol but introduces the need for a second round-trip
into OCSPv1. As a client cannot really rely on the error message the
situation will not get better. From a security point of view, the
proposed error message does not bring any advantage (as it can be
faked), technically it introduces the disadvantage of having to do two
requests.

*** I therefore suggest to leave OCSPv1 as it is (instead of making it
worse) and work with Davids extension to go in for OCSPv2. ***

In the meantime (until we get OCSPv2) people can use server-generated
nonces (which are compliant with the current state of RfC2560 and with
all existing clients out there). 

-- 
Florian Oelmaier
SyTrust

From: "Michael Myers" <[email-masked]>
To: "Frank Balluffi" <[email-masked]>, <[email-masked]>
Cc: "David Engberg" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 15:08:42 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: Frank Balluffi
>
> . . .
>
> I too like the proposal to use a flag or an
> extension. Perhaps an extension could say the
> equivalent of, "This is a cached response."

Frank,

Would you object the v1/v2 dual paths as means of getting this
into place?

Mike

Subject: RE: OCSP response pre-production
To: [email-masked]
Cc: "David Engberg" <[email-masked]>, [email-masked]
From: "Frank Balluffi" <[email-masked]>
Date: Thu, 2 Oct 2003 16:48:36 -0400
Sender: [email-masked]

I too like the proposal to use a flag or an extension. Perhaps an extension could say the equivalent of, "This is a cached response."

Frank

                      "Terry Hayes"                                                                                                    
                      <[email-masked]        To:       "David Engberg" <[email-masked]>                                         
                      om>                      cc:       [email-masked]                                                             
                      Sent by:                 Subject:  RE: OCSP response pre-production                                              
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      

                      10/02/2003 01:47                                                                                                 
                      PM                                                                                                               

I also like this proposal.  I believe that it is compatible with
existing responders that use pre-produced nonces, in the sense that
there aren't any changes required to allow them to continue operations.

Responders that only use pre-produced responses (with no nonce) would
benefit from changing their implement to add the extension.  This would
allow them to support the clients that implement dual-mode policy as
described in this thread.

As Florian has pointed out, this proposal is easier to understand than
having the server generate nonces.  In fact, I was going to write an
email that complained about overloading the nonce field to represent
this bit of information.  Given this proposal, I don't have to!

I also agree with Mike that we need to define an error that says that a
nonce is required for this responder.  This error is subject to
denial-of-service attacks (since it's unsigned), but we're already
exposed to that in this protocol anyway.

Terry

David Engberg wrote on 10/1/2003, 3:10 PM:

 > As an alternative, pre-generated responses could include a flag or
 > extension in their signed body to indicate that not only are they not
 > supplying a nonce with this response, but that they don't supply nonces
 > with any response, and if you trust that responder (via its public key
 > cert), then you may choose to accept the non-nonce-bearing response from
 > that server with this explicit flag (if that is your policy).
 >
 > This avoids the risk of someone replaying a response to you in which the
 > attacker chose not to supply a nonce, but you did.  It allows a client
 > to distinguish between a server saying "Here's a response without a
 > nonce because you I think you didn't ask for one" and "Here's a response
 > without a nonce because the responder for you or your CA does not use
 > nonces."
 >
 > I believe the following is a valid security policy which some (most?)
 > clients may choose to implement as an option:
 >
 >    - Send a nonce with every request
 >    - Accept a response with a matching nonce from any trusted responder
 >    - Accept a response with a nonceUnsupported extension from any
 >        trusted responder
 >    - Reject a response with no nonce and no nonceUnsupported extension
 >
 > This would allow the client to be much more usable with random public
 > certs (using AIA fields and delegated responder certs) in real-world
 > settings like secure email, etc.
 >

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Date: Thu, 02 Oct 2003 15:22:31 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet, Ltd.
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

If adding a new top-level error code is possible in v1, and adding a new 
response extension to indicate nonceUnsupported (or similar solution) is 
only possible in v2, then this may be the best course of action.

Thanks,
Dave

Michael Myers wrote:
> Dave,
> 
> Even if we do nothing, means currently exist for clients to
> discover if a server respects nonces via error signalling.  A
> non-nonced response to a nonced request itself being an error in
> perhaps then 11 of 12 client side implementions, including your
> own.
> 
> All along I've been trying to avoid opening the pandora's box of
> OCSPv2, but I guess it's time to do so.
> 
> The simple fix I most recently proposed could, I believe, be
> applied to RFC 2560 as it progresses from Proposed to Draft due
> to the poll's consensus.  Meanwhile, I strongly suspect that the
> syntax and semantic changes of more sophisticated solutions will
> force a version delta, a new I-D and all that entails regarding
> WG, IETF and IESG ratification.  That is, OCSPv2.
> 
> We have a narrow window of opportunity to fix v1 as proposed and
> so stem the tide of unilateral approaches to resolving its
> current ambiguity regarding the use of nonces.  This way,
> everybody's at least on the same page in the near term.
> 
> I propose we do so and in parallel move on to v2.  The v2
> discussions will predictably lead us into latent issues not
> associated with nonces.  As these things go, that will take a
> while.
> 
> Do you agree to this course of action?
> 
> Mike
> 
> 
> 
> 
> 

From: "Michael Myers" <[email-masked]>
To: "Terry Hayes" <[email-masked]>, "David Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 11:43:22 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From:  Terry Hayes
>
> . . .
>
> I also agree with Mike that we need to define an
> error that says that a nonce is required for this
> responder.  This error is subject to
> denial-of-service attacks (since it's unsigned),
> but we're already exposed to that in this protocol
> anyway.

Actually, Terry, errors were left unsigned largely to enable
edge servers to respond more effectively to a DOS flood than
might an interior signing server.

Mike

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 11:34:37 -0700
Importance: Normal
Sender: [email-masked]

Dave,

Even if we do nothing, means currently exist for clients to
discover if a server respects nonces via error signalling.  A
non-nonced response to a nonced request itself being an error in
perhaps then 11 of 12 client side implementions, including your
own.

All along I've been trying to avoid opening the pandora's box of
OCSPv2, but I guess it's time to do so.

The simple fix I most recently proposed could, I believe, be
applied to RFC 2560 as it progresses from Proposed to Draft due
to the poll's consensus.  Meanwhile, I strongly suspect that the
syntax and semantic changes of more sophisticated solutions will
force a version delta, a new I-D and all that entails regarding
WG, IETF and IESG ratification.  That is, OCSPv2.

We have a narrow window of opportunity to fix v1 as proposed and
so stem the tide of unilateral approaches to resolving its
current ambiguity regarding the use of nonces.  This way,
everybody's at least on the same page in the near term.

I propose we do so and in parallel move on to v2.  The v2
discussions will predictably lead us into latent issues not
associated with nonces.  As these things go, that will take a
while.

Do you agree to this course of action?

Mike

Date: Thu, 2 Oct 2003 10:47:30 -0700
From: "Terry Hayes" <[email-masked]>
Subject: RE: OCSP response pre-production
To: "David Engberg" <[email-masked]>
cc: [email-masked]
Organization: AOL
Sender: [email-masked]

I also like this proposal.  I believe that it is compatible with 
existing responders that use pre-produced nonces, in the sense that 
there aren't any changes required to allow them to continue operations.

Responders that only use pre-produced responses (with no nonce) would 
benefit from changing their implement to add the extension.  This would 
allow them to support the clients that implement dual-mode policy as 
described in this thread.

As Florian has pointed out, this proposal is easier to understand than 
having the server generate nonces.  In fact, I was going to write an 
email that complained about overloading the nonce field to represent 
this bit of information.  Given this proposal, I don't have to!

I also agree with Mike that we need to define an error that says that a 
nonce is required for this responder.  This error is subject to 
denial-of-service attacks (since it's unsigned), but we're already 
exposed to that in this protocol anyway.

Terry

David Engberg wrote on 10/1/2003, 3:10 PM:

 > As an alternative, pre-generated responses could include a flag or
 > extension in their signed body to indicate that not only are they not
 > supplying a nonce with this response, but that they don't supply nonces
 > with any response, and if you trust that responder (via its public key
 > cert), then you may choose to accept the non-nonce-bearing response from
 > that server with this explicit flag (if that is your policy).
 >
 > This avoids the risk of someone replaying a response to you in which the
 > attacker chose not to supply a nonce, but you did.  It allows a client
 > to distinguish between a server saying "Here's a response without a
 > nonce because you I think you didn't ask for one" and "Here's a response
 > without a nonce because the responder for you or your CA does not use
 > nonces."
 >
 > I believe the following is a valid security policy which some (most?)
 > clients may choose to implement as an option:
 >
 >    - Send a nonce with every request
 >    - Accept a response with a matching nonce from any trusted responder
 >    - Accept a response with a nonceUnsupported extension from any
 >        trusted responder
 >    - Reject a response with no nonce and no nonceUnsupported extension
 >
 > This would allow the client to be much more usable with random public
 > certs (using AIA fields and delegated responder certs) in real-world
 > settings like secure email, etc.
 >

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 10:06:52 -0700
Importance: Normal
Sender: [email-masked]

Dave,

I used the pop-up as an example.  It could very well be a
one-time configuration issue.   Or, as Jean-Marc Desperrier
suggested, all this hoo-hah could be a moot point when reduced
to practice.  In any case, specific software design features are
out of scope.

As you point out, caching servers today send back a non-nonced
response to a nonced request because 2560 is regrettably silent
on the point. 10 of 12 implementors seem to have understood the
principles of nonce use anyhow.  If that isn't rough consensus
and running code, I don't know what is.  Despite that, if this
WG, its chairs and our AD wish to condone the practice of
ignoring a nonce, I'd be happy to abide by that decision.

Mike

> -----Original Message-----
> From: David Engberg [mailto:[email-masked]]
> Sent: Thursday, October 02, 2003 9:41 AM
> To: Michael Myers
> Cc: [email-masked]
> Subject: Re: OCSP response pre-production
>
>
>
> If the only change is an error code in the unsigned
> portion of the
> protocol, there is no way for a client to
> automatically tell that the
> responder is intentionally configured to never send nonces.
>
> This prevents a client from choosing this
> automatically-enforced
> security policy:
>
>    Require nonce from servers that support nonces.
>    Accept responses without nonces from trusted
> responders that
>       securely indicate they won't ever provide a nonce.
>
> Like you said, a solution based only around an
> unsigned error code would
> require explicit user acceptance for each responder,
> while the most
> users don't have the faintest idea what nonces (or
> OCSP for that matter)
> are.  The pop-up example you listed may as well be in
> Latin for the
> majority of users.
>
> If nothing changes in the spec, caching-only servers
> will continue to
> send back a response without a nonce.  They won't
> send back any error
> because this is not an error under the current RFC.
>
>
> Michael Myers wrote:
> >
> >
> > If we don't define a nonce-specific error, it's
> predictable that
> > client developers will choose one of the existing 5 unsigned
> > error values in order to pop up a dialog that says,
> essentially,
> > "You used a nonce and received an error.  If you want to try
> > again not using nonces, click here."
> >
> > It doesn't matter much which error; any one will do
> in order to
> > discover if nonce use is the problem.  In fact if nothing
> > changed I'm wondering what the server side *would*
> send back?
> > I've recently seen suggestions on this list for
> > malFormedRequest, internalError and unauthorized.
> >
> > Not defining a nonce-specific error value escapes nothing.
> > Clients can today enable relying parties to achieve their
> > intended goals via error-triggered nonce capability
> discovery.
> >
> > Mike
> >
> >
> >
>
>

Date: Thu, 02 Oct 2003 12:41:06 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet, Ltd.
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

If the only change is an error code in the unsigned portion of the 
protocol, there is no way for a client to automatically tell that the 
responder is intentionally configured to never send nonces.

This prevents a client from choosing this automatically-enforced 
security policy:

   Require nonce from servers that support nonces.
   Accept responses without nonces from trusted responders that
      securely indicate they won't ever provide a nonce.

Like you said, a solution based only around an unsigned error code would 
require explicit user acceptance for each responder, while the most 
users don't have the faintest idea what nonces (or OCSP for that matter) 
are.  The pop-up example you listed may as well be in Latin for the 
majority of users.

If nothing changes in the spec, caching-only servers will continue to 
send back a response without a nonce.  They won't send back any error 
because this is not an error under the current RFC.

Michael Myers wrote:
> 
> 
> If we don't define a nonce-specific error, it's predictable that
> client developers will choose one of the existing 5 unsigned
> error values in order to pop up a dialog that says, essentially,
> "You used a nonce and received an error.  If you want to try
> again not using nonces, click here."
> 
> It doesn't matter much which error; any one will do in order to
> discover if nonce use is the problem.  In fact if nothing
> changed I'm wondering what the server side *would* send back?
> I've recently seen suggestions on this list for
> malFormedRequest, internalError and unauthorized.
> 
> Not defining a nonce-specific error value escapes nothing.
> Clients can today enable relying parties to achieve their
> intended goals via error-triggered nonce capability discovery.
> 
> Mike
> 
> 
> 

Date: Fri, 3 Oct 2003 04:30:04 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: OCSP response pre-production
Sender: [email-masked]

"Michael Myers" <[email-masked]> writes:

>If we don't define a nonce-specific error, it's predictable that client
>developers will choose one of the existing 5 unsigned error values in order
>to pop up a dialog that says, essentially, "You used a nonce and received an
>error.  If you want to try again not using nonces, click here."

.... which the user will mentally translate to "Quadrant change in relocatable
expression in subspace $CODE$" (yes, that's a real error message from HP-UX)
which after another level of mental translation becomes "Go boom fall down.
Click here make better".  After clicking OK, everything works again (or at
least something happens, either a cached response or a replay attack, but in
any case the annoying warning goes away so everything's all right).

Peter.

From: "Miguel Rodriguez" <[email-masked]>
To: "'Julien Stern'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 11:00:22 -0500
Importance: Normal
Sender: [email-masked]

I agree with this too, the support for nonces should indicated in the
signed content, either as a special flag or as Julien suggested using
the nextUpdate field. I prefer any of these options over the definition
of a new (unsigned) error message.

Miguel A Rodriguez
SeguriDATA
Mexico

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Julien Stern
> Sent: Thursday, October 02, 2003 8:41 AM
> To: [email-masked]
> Subject: Re: OCSP response pre-production
> 
> 
> I fully agree with this too. The server has to indicate whether it
> supports nonces or not INSIDE the signed content. Server generated
> nonces are a way, this extension is another (hmm, well, the equivalent
> of server generated nonces would be an ICanProvideANonceIfYouWish
> extension, but ...).
> On this other hand, I think that it is dangerous to indicate this fact
> as an _unsigned_ error, as this error reply could easily be faked by
an
> attacker, making him think a server does not support nonces while in
> fact it does.
> 
> --
> Julien

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 08:50:05 -0700
Importance: Normal
Sender: [email-masked]

If we don't define a nonce-specific error, it's predictable that
client developers will choose one of the existing 5 unsigned
error values in order to pop up a dialog that says, essentially,
"You used a nonce and received an error.  If you want to try
again not using nonces, click here."

It doesn't matter much which error; any one will do in order to
discover if nonce use is the problem.  In fact if nothing
changed I'm wondering what the server side *would* send back?
I've recently seen suggestions on this list for
malFormedRequest, internalError and unauthorized.

Not defining a nonce-specific error value escapes nothing.
Clients can today enable relying parties to achieve their
intended goals via error-triggered nonce capability discovery.

Mike

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-01.txt
Date: Thu, 02 Oct 2003 10:50:53 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure:       
                          Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow et al.
	Filename	: draft-ietf-pkix-certpathbuild-01.txt
	Pages		: 67
	Date		: 2003-10-2
	
This document was written to provide guidance and recommendations to 
developers building X.509 public-key certification paths within their 
applications.  By following the guidance and recommendations defined 
in this document, an application developer is more likely to develop 
a robust X.509 certificate enabled application that can build valid 
certification paths across a wide range of PKI environments.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-certpathbuild-01.txt".

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

From: "Ambarish Malpani" <[email-masked]>
To: "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Thu, 2 Oct 2003 07:15:41 -0700
Importance: Normal
Sender: [email-masked]

I agree.

A

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jean-Marc Desperrier
> Sent: Thursday, October 02, 2003 2:19 AM
> To: [email-masked]
> Subject: Re: OCSP response pre-production
> 
> 
> 
> David Engberg wrote:
> > I would prefer a signalling mechanism that does not require two 
> > round-trip communications to establish nonce support, 
> 
> May I say we should *NOT* aim to fullfill this ?
> 
> If we don't, everything is easy.
> 
> Clients that requires freshest response send a nonce, and get back an 
> error if it's not possible to give freshest response.
> Client that don't require it, send no nonce.
> 
> Client that would like it, but don't require it, make a round trip, and 
> cache the fact the server can't supply freshest response, so they do the 
> round trip only once.
> 
> My opinion is :
> - in real life implementations, it's not so common to both trust an OCSP 
> responder, and not know in advance if it can supply fresh responses or 
> not. Even if it's the case, there won't be so many different OCSP 
> responders, and it won't take long to discover they don't provide fresh 
> answers.
> 
> - The global security brought by trying to get a fresh response, but 
> being ready to accept a non-fresh one, can hardly be said to be any 
> different from directly accepting a non-fresh one. If the system was 
> audited, I'm doubtful auditors would think it brings any real difference.
> 
> So I don't see a reason to go such lengths to support this.
> 

From: "Julien Stern" <[email-masked]>
Date: Thu, 2 Oct 2003 15:40:38 +0200
To: [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

On Thu, Oct 02, 2003 at 08:45:39AM -0000, Florian Oelmaier wrote:
> 
> > As an alternative, pre-generated responses could include a flag or 
> > extension in their signed body to indicate that not only are they not 
> > supplying a nonce with this response, but that they don't supply nonces 
> > with any response, and if you trust that responder (via its public key 
> > cert), then you may choose to accept the non-nonce-bearing response from 
> > that server with this explicit flag (if that is your policy).
> > 
> > This avoids the risk of someone replaying a response to you in which the 
> > attacker chose not to supply a nonce, but you did.  It allows a client 
> > to distinguish between a server saying "Here's a response without a 
> > nonce because you I think you didn't ask for one" and "Here's a response 
> > without a nonce because the responder for you or your CA does not use 
> > nonces."
> > 
> > I believe the following is a valid security policy which some (most?) 
> > clients may choose to implement as an option:
> > 
> >    - Send a nonce with every request
> >    - Accept a response with a matching nonce from any trusted responder
> >    - Accept a response with a nonceUnsupported extension from any
> >        trusted responder
> >    - Reject a response with no nonce and no nonceUnsupported extension
> > 
> > This would allow the client to be much more usable with random public 
> > certs (using AIA fields and delegated responder certs) in real-world 
> > settings like secure email, etc.
> > 
> 
> I fully agree with this. It seems to be a good idea.
> 
> My idea of server-generated nonces is simply the other way round: If the responder wants to signal "nonceUnsupported", the response does not include a nonce, if the responder generally supports nonces it simply generates one for requests not containing one.
> 
> From my point of view both proposals do technically the same and are fine for me. Davids "nonceUnsupported"-extension is easier to understand and more clear while server generated nonces do not need changes in clients like Juliens or mine. I am fine with both - tell me when to begin implementing.

I fully agree with this too. The server has to indicate whether it
supports nonces or not INSIDE the signed content. Server generated
nonces are a way, this extension is another (hmm, well, the equivalent
of server generated nonces would be an ICanProvideANonceIfYouWish
extension, but ...).
On this other hand, I think that it is dangerous to indicate this fact
as an _unsigned_ error, as this error reply could easily be faked by an
attacker, making him think a server does not support nonces while in
fact it does.

--
Julien

Date: Thu, 02 Oct 2003 08:17:41 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Jean-Marc Desperrier <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

Jean-Marc Desperrier wrote:
> Clients that requires freshest response send a nonce, and get back an 
> error if it's not possible to give freshest response.
> Client that don't require it, send no nonce.
 >
> Client that would like it, but don't require it, make a round trip, and 
> cache the fact the server can't supply freshest response, so they do the 
> round trip only once.

I could live with a two-trip solution as an alternative as long as the 
error is contained in a signed message which can be pre-generated for 
that responder.  If the error is in the unsigned portion of the 
protocol, a client can't really tell a nonceUnsupported server from an 
attacker on the network, which means its only realistic option is to 
reject the response and quit.

An extra round-trip communication is unfortunate, but not a show-stopper 
if it conveys some other fundamental advantage that I'm missing.

> - in real life implementations, it's not so common to both trust an OCSP 
> responder, and not know in advance if it can supply fresh responses or 
> not. Even if it's the case, there won't be so many different OCSP 
> responders, and it won't take long to discover they don't provide fresh 
> answers.

You may be only thinking of closed internal PKIs with one or two CAs and 
hard-coded clients.  I'm thinking of the broader case where I may want 
to accept signed emails from everyone that chains or bridges to one of 
my trusted roots.  I may accept signed emails from employees of Acme 
Novelties because their CA chains to a Verisign root, and their AIA OCSP 
responder was properly delegated by their CA (OCSP Signing).  I 
certainly have no idea whether Acme's responder keys are online 
(nonce-supporting) or off (nonceUnsupported) before my first request, 
even though I'm prepared to accept whichever security policy the CA chooses.

I think it is a valid and secure _option_ for a client to say "accept 
the revocation security policies chosen by trusted CAs and/or 
responders."  If a CA only publishes CRLs every 24 hours, its OCSP 
infrastructure should be able to signal to interested clients that they 
shouldn't waste everyone's time and CPU cycles by sending nonces just to 
get "fresh" views of the same cached CRL.

Date: 2 Oct 2003 11:43:54 -0000
From: "Florian Oelmaier" <[email-masked]>
To: Jean-Marc Desperrier <[email-masked]>, [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

> David Engberg wrote:
> > I would prefer a signalling mechanism that does not require two 
> > round-trip communications to establish nonce support, 
> 
> May I say we should *NOT* aim to fullfill this ?

Seeing that it is rather easy to do it (as shown in both proposals), I would vote for fullfilling this requirement.

> My opinion is :
> - in real life implementations, it's not so common to both trust an OCSP 
> responder, and not know in advance if it can supply fresh responses or 
> not. 

A lot of clients use AIA to find the OCSP-URL and use the OCSP-signing certificate extension to trust the OCSP Responder. The case of contacting an "unknown" OCSP-Responder will even become more important the more PKIs we find our there.

> - The global security brought by trying to get a fresh response, but 
> being ready to accept a non-fresh one, can hardly be said to be any 
> different from directly accepting a non-fresh one. If the system was 
> audited, I'm doubtful auditors would think it brings any real difference.

With our proposals this depends on the responder. If your responder supports nonces, the described client WILL use it. If your responder does not, the client will not. The client will NOT accept a nonce-less response from a responder being able to support nonces. 

Thus an auditor will see a real difference regarding certificates from some CAs - as for certain CAs a client will not accept nonce-less OCSP responses. This is a very common thing for every auditor out there: having CAs with different trust levels.

Additionally when an OCSP client (for example an SCVP server) detects multiple paths for a given certificate, the "freshness" of a validation may be used in a policy to establish a certain "trust level".

-- 
Florian Oelmaier
SyTrust

Date: Thu, 02 Oct 2003 11:19:04 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

David Engberg wrote:
> I would prefer a signalling mechanism that does not require two 
> round-trip communications to establish nonce support, 

May I say we should *NOT* aim to fullfill this ?

If we don't, everything is easy.

Clients that requires freshest response send a nonce, and get back an 
error if it's not possible to give freshest response.
Client that don't require it, send no nonce.

Client that would like it, but don't require it, make a round trip, and 
cache the fact the server can't supply freshest response, so they do the 
round trip only once.

My opinion is :
- in real life implementations, it's not so common to both trust an OCSP 
responder, and not know in advance if it can supply fresh responses or 
not. Even if it's the case, there won't be so many different OCSP 
responders, and it won't take long to discover they don't provide fresh 
answers.

- The global security brought by trying to get a fresh response, but 
being ready to accept a non-fresh one, can hardly be said to be any 
different from directly accepting a non-fresh one. If the system was 
audited, I'm doubtful auditors would think it brings any real difference.

So I don't see a reason to go such lengths to support this.

Date: 2 Oct 2003 08:45:39 -0000
From: "Florian Oelmaier" <[email-masked]>
To: David Engberg <[email-masked]>, [email-masked]
Subject: RE: OCSP response pre-production
Sender: [email-masked]

> As an alternative, pre-generated responses could include a flag or 
> extension in their signed body to indicate that not only are they not 
> supplying a nonce with this response, but that they don't supply nonces 
> with any response, and if you trust that responder (via its public key 
> cert), then you may choose to accept the non-nonce-bearing response from 
> that server with this explicit flag (if that is your policy).
> 
> This avoids the risk of someone replaying a response to you in which the 
> attacker chose not to supply a nonce, but you did.  It allows a client 
> to distinguish between a server saying "Here's a response without a 
> nonce because you I think you didn't ask for one" and "Here's a response 
> without a nonce because the responder for you or your CA does not use 
> nonces."
> 
> I believe the following is a valid security policy which some (most?) 
> clients may choose to implement as an option:
> 
>    - Send a nonce with every request
>    - Accept a response with a matching nonce from any trusted responder
>    - Accept a response with a nonceUnsupported extension from any
>        trusted responder
>    - Reject a response with no nonce and no nonceUnsupported extension
> 
> This would allow the client to be much more usable with random public 
> certs (using AIA fields and delegated responder certs) in real-world 
> settings like secure email, etc.
> 

I fully agree with this. It seems to be a good idea.

My idea of server-generated nonces is simply the other way round: If the responder wants to signal "nonceUnsupported", the response does not include a nonce, if the responder generally supports nonces it simply generates one for requests not containing one.

>From my point of view both proposals do technically the same and are fine for me. Davids "nonceUnsupported"-extension is easier to understand and more clear while server generated nonces do not need changes in clients like Juliens or mine. I am fine with both - tell me when to begin implementing.

-- 
Florian Oelmaier
SyTrust

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: SUMMARY of  nonces in OCSP
Date: Thu, 2 Oct 2003 00:41:07 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

Michael,

can you please explain to me why we need 3 and 4? Both requirements seem
to be fulfilled rather fine in the current state of RfC2560: the
responder simply sends back a response without nonce. What is the
problem with the current solution to this problem?

-- 
Florian Oelmaier
SyTrust

PS: While our software is not broken by the proposed language due to
good configurability, I cannot guarantee for all installations.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Myers
> Sent: Wednesday, October 01, 2003 7:20 PM
> To: [email-masked]
> Subject: SUMMARY of nonces in OCSP
> 
> 
> 
> All,
> 
> Towards consensus on a path forward, here's where we are with 
> the poll and recent discussions:
> 
> 1.  Nonces break caching.  No news there.
> 
> 2.  Of the eleven responding implementors to the poll 
> regarding normative language in 2560 on the use of nonces, 
> nine are not broken by the proposed language while two rely 
> on a caching.
> 
> 3.  We need to define an error value specific to a 
> responder's inability to accept a nonce.
> 
> 4.  Closely related to #3, we need some means of signalling 
> between a requestor and a responder in order for the 
> requestor to determine if use of a nonce would be accepted.
> 
> Anyone disagree?
> 
> Below is the specific list of respondents to poll.  Did I 
> miss anybody?
> 
> 
> NOT BROKEN
> ----------
> Marius Marian, Politenico di Torino
> Ryan Hurst, Microsoft
> Yasir Khan, Ascertia
> Miguel Rodriguez, SeguriDATA
> Peter Gutman, (doing what Peter does)
> Eric Wertz, RSA
> Florian Oelmaier, SyTrust
> Terry Hayes, Netscape
> Stephen Henson, OpenSSL
> 
> 
> BROKEN DUE TO CACHING
> ---------------------
> Alex Deacon, VeriSign
> David Engberg, CoreStreet
> 
> 
> Mike
> 
> 
> 

Date: Wed, 01 Oct 2003 18:10:33 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet, Ltd.
To: [email-masked]
Subject: RE: OCSP response pre-production
Sender: [email-masked]

I agree with the general idea of having an unambiguous way for a 
responder to indicate that it will not provide nonces in responses.  I 
think it may be unnecessarily restrictive to say that every client must 
automatically reject a response without a nonce, but that would not 
directly impact our software either way.

I would prefer a signalling mechanism that does not require two 
round-trip communications to establish nonce support, and that does not 
add any significant size to the body of pre-generated responses to 
indicate that they don't have nonces in them (which is evident).

Michael's initial proposal (below) could work, but has the two issues of 
requiring two round-trips for negotiation and returning the 
"unsupported" message in the unsigned portion of the body rather than in 
the signed body.  I also would prefer to remove the last sentence of the 
semantics or at least tone it down as unnecessarily focused on one 
hypothetical risk above all others (e.g. remote server key compromise).

 > SYNTAX:     Expand v1 OCSPResponseStatus syntax to
 >             include (7) noncesNotAccepted.
 >
 >
 > SEMANTICS:  Responders SHOULD respond back with the
 >             requestor's nonce but if can't then SHALL
 >             respond with an error message of the value
 >             noncesNotAccepted.
 >
 >             Requestors SHALL reject signed responses
 >             that fail to incorporate a supplied nonce.
 >
 >             Upon receipt of noncesNotRequired, requestors
 >             MAY retry the request without using a nonce.
 >             Requestors are STRONGLY ADVISED that doing
 >             so MAY subject them to additional risk.

As an alternative, pre-generated responses could include a flag or 
extension in their signed body to indicate that not only are they not 
supplying a nonce with this response, but that they don't supply nonces 
with any response, and if you trust that responder (via its public key 
cert), then you may choose to accept the non-nonce-bearing response from 
that server with this explicit flag (if that is your policy).

This avoids the risk of someone replaying a response to you in which the 
attacker chose not to supply a nonce, but you did.  It allows a client 
to distinguish between a server saying "Here's a response without a 
nonce because you I think you didn't ask for one" and "Here's a response 
without a nonce because the responder for you or your CA does not use 
nonces."

I believe the following is a valid security policy which some (most?) 
clients may choose to implement as an option:

   - Send a nonce with every request
   - Accept a response with a matching nonce from any trusted responder
   - Accept a response with a nonceUnsupported extension from any
       trusted responder
   - Reject a response with no nonce and no nonceUnsupported extension

This would allow the client to be much more usable with random public 
certs (using AIA fields and delegated responder certs) in real-world 
settings like secure email, etc.

Content-class: urn:content-classes:message
Subject: RE: SUMMARY of  nonces in OCSP
Date: Wed, 1 Oct 2003 14:47:00 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

In-line

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Wednesday, October 01, 2003 10:20 AM
To: [email-masked]
Subject: SUMMARY of nonces in OCSP

All,

Towards consensus on a path forward, here's where we are with the poll
and recent discussions:

1.  Nonces break caching.  No news there.
[rmh] Yup.

2.  Of the eleven responding implementors to the poll regarding
normative language in 2560 on the use of nonces, nine are not broken by
the proposed language while two rely on a caching.
[rmh] Yup.

3.  We need to define an error value specific to a responder's inability
to accept a nonce.
[rmh] not sure we need this, I am OK with internalError, notAuthorized
or a new error but preferably I as a client want a response because I
want to decide if I care; that's what our client will be doing.

4.  Closely related to #3, we need some means of signalling between a
requestor and a responder in order for the requestor to determine if use
of a nonce would be accepted.
[rmh] I don't care about this, this assumes a server controls the
clients which doesn't seem to be realistic.

Anyone disagree?

Below is the specific list of respondents to poll.  Did I miss anybody?

NOT BROKEN
----------
Marius Marian, Politenico di Torino
Ryan Hurst, Microsoft
Yasir Khan, Ascertia
Miguel Rodriguez, SeguriDATA
Peter Gutman, (doing what Peter does)
Eric Wertz, RSA
Florian Oelmaier, SyTrust
Terry Hayes, Netscape
Stephen Henson, OpenSSL

BROKEN DUE TO CACHING
---------------------
Alex Deacon, VeriSign
David Engberg, CoreStreet

Mike

To: "Michael Myers" <[email-masked]>
Cc: [email-masked]
Subject: Nonce encoding (was RE: OCSP response pre-production)
From: Tom Gindin <[email-masked]>
Date: Wed, 1 Oct 2003 15:56:56 -0400
Sender: [email-masked]

        As far as I can tell, there is no explicit definition of the 
syntax of the nonce in RFC 2560.  If the syntax is actually OCTET STRING, 
we might be able to extend it as follows:
CHOICE  {
        requiredInResp          OCTET STRING,
        optionalInResp  [1]     EXPLICIT OCTET STRING
}
        which might not break existing code.  Or it could be
CHOICE  {
        original                        OCTET STRING,           -- 
undefined as to mandatory vs. optional in response.
        requiredInResp [0]      EXPLICIT OCTET STRING,
        optionalInResp  [1]     EXPLICIT OCTET STRING
}

                Tom Gindin

"Michael Myers" <[email-masked]>
Sent by: [email-masked]
09/26/2003 06:25 PM

        To:     "Deacon, Alex" <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: OCSP response pre-production

Alex,

I will, once I get them all integrated.  Given the volume of
today's discussions, that will likely be sometime early next
week.

Mike

> -----Original Message-----
> From: Deacon, Alex [mailto:[email-masked]]
> Sent: Friday, September 26, 2003 3:13 PM
> To: 'Michael Myers'; Deacon, Alex; [email-masked]
> Subject: RE: OCSP response pre-production
>
>
>
> Mike,
>
> As there has been some suggested changes to the text,
> can you post the most
> recent wording to get everyone back on the same page?
>
> Thanks
> Alex
>
>
> > -----Original Message-----
> > From: Michael Myers [mailto:[email-masked]]
> > Sent: Friday, September 26, 2003 2:35 PM
> > To: Deacon, Alex; [email-masked]
> > Subject: RE: OCSP response pre-production
> >
> >
> > Alex,
> >
> > I'm willing to discuss client-side "nonce
> capability discovery"
> > via this mechanism but it's clearly a v2 proposition.
> > Meanwhile, we're working to clarify what we meant
> in v1 when we
> > defined nonces in the first place.  The poll
> clearly establishes
> > a nearly unanimous consensus that the common
> understanding in
> > place at the time found its way into running code
> in all but, to
> > date, one case.  I propose we proceed on this basis.
> >
> > Mike
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Deacon, Alex [mailto:[email-masked]]
> > > Sent: Friday, September 26, 2003 2:09 PM
> > > To: 'Ryan M. Hurst'; Paul Hoffman / IMC; Michael
> > > Myers; David Engberg;
> > > [email-masked]; Ambarish Malpani; [email-masked]
> > > Cc: Russ Housley; Stephen Kent; Tim Polk
> > > Subject: RE: OCSP response pre-production
> > >
> > >
> > >
> > > This summary assumes that the OCSP responder has
> > > control of the OCSP clients.  This may not be the
> > > case, especially when responding to OCSP requests
> > > for certs issued from SSL CA's (i.e. every flavor
> > > of browser/ocsp client on earth).  As I stated in
> > > my response to Russ, the responder could reject a
> > > request with a nonce, but why not reply with a
> > > request without a nonce, and let the client decided
> > > if it wants to accept or reject it.  If a client
> > > requires that the nonce in the result, the result
> > > is the same, the response is rejected.
> > >
> > > Alex
> >
> >
>
>

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: "Ambarish Malpani" <[email-masked]>
Subject: RE: SUMMARY of  nonces in OCSP
Date: Wed, 1 Oct 2003 10:32:14 -0700
Importance: Normal
Sender: [email-masked]

Oops.  I missed Ambarish and Valicert as NOT BROKEN.  Sorry,
Ambarish.

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Wednesday, October 01, 2003 10:20 AM
> To: [email-masked]
> Subject: SUMMARY of nonces in OCSP
>
>
> All,
>
> Towards consensus on a path forward, here's where we
> are with the poll and recent discussions:
>
> 1.  Nonces break caching.  No news there.
>
> 2.  Of the eleven responding implementors to the poll
> regarding normative language in 2560 on the use of
> nonces, nine are not broken by the proposed language
> while two rely on a caching.
>
> 3.  We need to define an error value specific to a
> responder's inability to accept a nonce.
>
> 4.  Closely related to #3, we need some means of
> signalling between a requestor and a responder in
> order for the requestor to determine if use of a
> nonce would be accepted.
>
> Anyone disagree?
>
> Below is the specific list of respondents to poll.
> Did I miss anybody?
>
>
> NOT BROKEN
> ----------
> Marius Marian, Politenico di Torino
> Ryan Hurst, Microsoft
> Yasir Khan, Ascertia
> Miguel Rodriguez, SeguriDATA
> Peter Gutman, (doing what Peter does)
> Eric Wertz, RSA
> Florian Oelmaier, SyTrust
> Terry Hayes, Netscape
> Stephen Henson, OpenSSL
>
>
> BROKEN DUE TO CACHING
> ---------------------
> Alex Deacon, VeriSign
> David Engberg, CoreStreet
>
>
> Mike

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: SUMMARY of  nonces in OCSP
Date: Wed, 1 Oct 2003 10:20:11 -0700
Importance: Normal
Sender: [email-masked]

All,

Towards consensus on a path forward, here's where we are with
the poll and recent discussions:

1.  Nonces break caching.  No news there.

2.  Of the eleven responding implementors to the poll regarding
normative language in 2560 on the use of nonces, nine are not
broken by the proposed language while two rely on a caching.

3.  We need to define an error value specific to a responder's
inability to accept a nonce.

4.  Closely related to #3, we need some means of signalling
between a requestor and a responder in order for the requestor
to determine if use of a nonce would be accepted.

Anyone disagree?

Below is the specific list of respondents to poll.  Did I miss
anybody?

NOT BROKEN
----------
Marius Marian, Politenico di Torino
Ryan Hurst, Microsoft
Yasir Khan, Ascertia
Miguel Rodriguez, SeguriDATA
Peter Gutman, (doing what Peter does)
Eric Wertz, RSA
Florian Oelmaier, SyTrust
Terry Hayes, Netscape
Stephen Henson, OpenSSL

BROKEN DUE TO CACHING
---------------------
Alex Deacon, VeriSign
David Engberg, CoreStreet

Mike

From: "Wen-Cheng Wang" <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>, <[email-masked]>
Subject: Re: Self-Issued certificate requirements?
Date: Wed, 1 Oct 2003 16:52:20 +0800
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Faisal,

According to the X.509 standard 4th edition, there are three types of =
self-issued certificate:
  a) self-signed certificate (a special case of self-issued =
certificates)
  b) self-issued end certificate
  c) self-issued intermediate certificate

(Please refer to section 8.1.5 of the X.509 standard 4th edition.)

The definifion of self-issued certificate in RFC 3280 is not aligned =
with its definition in the
X.509 standard. The so-called self-issued certificates in RFC 3280 are =
mostly of type c) in
the X.509 standard. IMHO, currently both X.509 standard and PKIX have no =
clear
definition for the format and the handling of self-issued certificates =
of type b).

For self-issued certificates of type c), I believe that the requirement =
is hidden in steps
(k) and (n) of section 6.1.4 of RFC 3280 as:

  (k) Verify that the certificate is a CA certificate (as specified
        in a basicConstraints extension or as verified out-of-band).

  (n) If a key usage extension is present, verify that the
        keyCertSign bit is set.

Note that rules (k) and (n) apply to all intermediate certificates even =
if they are self-issued.

My interpretations to these two rule are:

For a v3 intermediate certificate (self-issued or not), it should =
contain a basicConstraints extension
with cA=3DTRUE. For a v1 intermediate certificate (self-issued or not), =
the RP need an out-of-band
method to make sure that it is a CA certificate.

For a v3 intermediate certificate (self-issued or not), it should =
contain a keyUsage extension
with keyCertSign bit asserted. For a v1 intermediate certificate =
(self-issued or not), there is no
need to check the key usage but the RP must make sure that it is a CA =
certificate.

Regards,
Wen-Cheng Wang

  ----- Original Message -----=20
  From: Faisal Maqsood=20
  To: [email-masked]=20
  Sent: Tuesday, September 30, 2003 10:03 PM
  Subject: Self-Issued certificate requirements?

  Hi All,

  RFC-3280 defines Self Signed certificate as:
  "A certificate is self-issued if the DNs that appear in the subject =
and issuer fields are  identical and are not empty."

  There might be two condition for self-issued certificate:
    1.. Version-1 certificate and has not any extension.=20
    2.. Version-3 certificate with set of extension/s.
  For version-1 it is clear but are there any extra required things for =
version-3 self-issued certificates?
  I mean for self-issued certificate is there any requirement that it =
Must be a CA certificate?
  I mean BasicConstraints =3D ?, Path Length =3D ?, KeyUsage =3D ? etc.

  Regards,
  FAISAL MAQSOOD

------=_NextPart_000_00D0_01C3883C.61144700
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252"><BASE=20
href=3D"file://F:\___Faisal-Data-Priv\Email Signature\">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>Faisal,</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>According to the =
X.509 standard 4th edition, there are=20
three types of self-issued certificate:</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>&nbsp; a) self-signed =
certificate (a special case of=20
self-issued certificates)</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>&nbsp; b) self-issued =
end certificate</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>&nbsp; c) self-issued =
intermediate certificate</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>(Please refer to =
section 8.1.5 of the X.509 standard 4th=20
edition.)</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>The definifion of =
self-issued certificate in RFC 3280 is=20
not aligned with its definition in the</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>X.509 standard. The =
so-called self-issued certificates in=20
RFC 3280 are mostly of type&nbsp;c) in</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>the X.509 =
standard.</FONT>&nbsp;<FONT =
face=3D&#26032;&#32048;&#26126;&#39636;>IMHO,=20
currently both X.509 standard and PKIX have no clear</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>definition for the =
format and the handling of self-issued=20
certificates of type b).</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>For self-issued =
</FONT><FONT face=3D&#26032;&#32048;&#26126;&#39636;>certificates of =
type=20
c), I believe that the requirement is hidden&nbsp;in steps</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>(k) and (n) of =
section </FONT><FONT face=3D&#26032;&#32048;&#26126;&#39636;>6.1.4 of =
RFC=20
3280 as:</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>&nbsp; =
(k)&nbsp;Verify that the certificate is a CA=20
certificate (as =
specified<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in=20
a basicConstraints extension or as verified out-of-band).</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>&nbsp; (n)&nbsp;If a =
key usage extension is present, verify=20
that the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;keyCertSign =
bit is=20
set.</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>Note that rules (k) =
and (n) apply to all intermediate=20
certificates even if they are self-issued.</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>My interpretations to =
these two rule are:</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>For a v3 intermediate =
certificate (self-issued or not), it=20
should contain a basicConstraints extension</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>with cA=3DTRUE. For a =
v1 intermediate certificate=20
(self-issued or not), the RP need an out-of-band</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>method to make sure =
that it is a CA=20
certificate.</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;></FONT>&nbsp;</DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>For a v3 intermediate =
certificate (self-issued or not), it=20
should contain a&nbsp;keyUsage extension</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>with keyCertSign bit =
asserted. For a v1 intermediate=20
certificate (self-issued or not), there is no</FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636;>need to check the key =
usage but the RP must&nbsp;make=20
</FONT><FONT face=3D&#26032;&#32048;&#26126;&#39636;>sure that it is a =
CA certificate.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>Wen-Cheng Wang</DIV></FONT></DIV>
<DIV><FONT face=3D&#26032;&#32048;&#26126;&#39636; =
size=3D2></FONT>&nbsp;</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 &#26032;&#32048;&#26126;&#39636;">----- =
Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;; font-color: black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Faisal Maqsood</A> </DIV>
  <DIV style=3D"FONT: 10pt &#26032;&#32048;&#26126;&#39636;"><B>To:</B> =
<A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Sent:</B> Tuesday, September 30, =
2003 10:03=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt =
&#26032;&#32048;&#26126;&#39636;"><B>Subject:</B> Self-Issued =
certificate=20
  requirements?</DIV>
  <DIV><BR></DIV>
  <DIV>Hi All,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>RFC-3280 defines Self Signed certificate as:</DIV>
  <DIV>"<EM>A certificate is self-issued if the DNs that appear in the =
subject=20
  and issuer fields are &nbsp;identical and are not empty.</EM>"</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>There might be two condition for self-issued certificate:</DIV>
  <OL>
    <LI>Version-1 certificate and has not any extension.=20
    <LI>Version-3 certificate with set of extension/s.</LI></OL>
  <DIV>For version-1 it is clear but are there any extra required things =
for=20
  version-3 self-issued certificates?</DIV>
  <DIV>I mean for self-issued certificate is there any requirement that=20
  it&nbsp;Must be a CA certificate?</DIV>
  <DIV>I mean BasicConstraints =3D ?, Path Length =3D ?, KeyUsage =3D ? =
etc.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Regards,</DIV>
  <DIV>FAISAL MAQSOOD</DIV>
  <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00D0_01C3883C.61144700--

Date: Wed, 01 Oct 2003 10:52:04 +0300
Subject: Re: Self-Issued certificate =?windows-1252?q?requirements=3F?=
From: Lars Johansson <[email-masked]>
To: Faisal Maqsood  <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Hi Faisal,

According to RFC 2510, chapter 3.2.5, self-signed certificates
should be constructed with the following requirements:

" The fields within this certificate are restricted as follows:

   - The certificate MUST be self-signed  (i.e., the signature must be
     verifiable using the SubjectPublicKeyInfo field);
   - The subject and issuer fields MUST be identical;
   - If the subject field is NULL then both subjectAltNames and
     issuerAltNames extensions MUST be present and have exactly the
same
     value;
   - The values of all other extensions must be suitable for a self-
     signed certificate (e.g., key identifiers for subject and issuer
     must be the same).
"

That's all I've been able to find.

Regards
/Lars
_________________________________________________
Lars Johansson | Consultant
[email-masked] | www.omegapoint.se
phone +46 70-915 88 40 | fax +46 8-517 008 29
Omegapoint AB, Stockholm, Sweden

-------------------
> Hi All,
> 
> RFC-3280 defines Self Signed certificate as:
> "A certificate is self-issued if the DNs that appear in the subject
and issuer fields are  identical and are not empty."
> 
> There might be two condition for self-issued certificate:
>   1.. Version-1 certificate and has not any extension.
>   2.. Version-3 certificate with set of extension/s.
> For version-1 it is clear but are there any extra required things
for version-3 self-issued certificates?
> I mean for self-issued certificate is there any requirement that it
Must be a CA certificate?
> I mean BasicConstraints = ?, Path Length = ?, KeyUsage = ? etc.
> 
> Regards,
> FAISAL MAQSOOD
> 
>