Carlisle Adams | 1 May 15:54 2003

RE: draft-ietf-pkix-rfc2511bis

Hi Russ,
 
In RFC 2511, the body of the spec (in Section 7, on page 11) says that {id-regInfo 1} is called "id-regInfo-asciiPairs" with a syntax of OCTET STRING, but the ASN.1 module (a few lines before the END statement, on page 23) says that this same OID is called "id-regInfo-utf8Pairs" with a syntax of UTF8String.
 
The change made in rfc2511bis was to correct this error and align the text in the body of the spec with the ASN.1 module.  Thus, both places now say that the {id-regInfo 1} OID is called "id-regInfo-utf8Pairs" with a syntax of UTF8String.  There was no intent to change the semantics of an existing OID.
 
Carlisle.
 
 
-----Original Message-----
From: Russ Housley [mailto:housley <at> vigilsec.com]
Sent: Tuesday, April 29, 2003 9:54 AM
To: ietf-pkix <at> imc.org
Subject: draft-ietf-pkix-rfc2511bis

I am concerned about the change that is illustrated below (please excuse the HTML).

   -- Registration Info in CRMF    id-regInfo       OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }    id-regInfo-asciiPairs    id-regInfo-utf8Pairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }    --with syntax OCTET STRING UTF8STRING    id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }    --with syntax CertRequest First, I am concerned about the change in the semantics associated with an OID that was assigned a long time ago.  This could lead to interoperability issues.  Why would we change the semantics of an existing OID instead of assigning a new OID.

Second, this change does not show up in the ASN.1 module.  Why are the OIDs not part of the ASN.1 module?

Russ
Russ Housley | 1 May 20:11 2003

RE: draft-ietf-pkix-rfc2511bis

Carlisle:

Thanks for getting back to me.  It would be very helpful if the document included a section on changes since RFC 2511.  We included a similar section in RFC 3280 that describes the changes since RFC 2459.  In that section, you can say that the inconsistency was corrected.

Can you post a proposal for such a section?

Russ

At 09:54 AM 5/1/2003 -0400, Carlisle Adams wrote:
Hi Russ,
 
In RFC 2511, the body of the spec (in Section 7, on page 11) says that {id-regInfo 1} is called "id-regInfo-asciiPairs" with a syntax of OCTET STRING, but the ASN.1 module (a few lines before the END statement, on page 23) says that this same OID is called "id-regInfo-utf8Pairs" with a syntax of UTF8String.
 
The change made in rfc2511bis was to correct this error and align the text in the body of the spec with the ASN.1 module.  Thus, both places now say that the {id-regInfo 1} OID is called "id-regInfo-utf8Pairs" with a syntax of UTF8String.  There was no intent to change the semantics of an existing OID.
 
Carlisle.
 
 
-----Original Message-----
From: Russ Housley [mailto:housley <at> vigilsec.com]
Sent: Tuesday, April 29, 2003 9:54 AM
To: ietf-pkix <at> imc.org
Subject: draft-ietf-pkix-rfc2511bis

I am concerned about the change that is illustrated below (please excuse the HTML).


   -- Registration Info in CRMF    id-regInfo       OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }   id-regInfo-asciiPairs   id-regInfo-utf8Pairs   OBJECT IDENTIFIER ::= { id-regInfo 1 }    --with syntax OCTET STRING UTF8STRING    id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }    --with syntax CertRequest First, I am concerned about the change in the semantics associated with an OID that was assigned a long time ago.  This could lead to interoperability issues.  Why would we change the semantics of an existing OID instead of assigning a new OID.

Second, this change does not show up in the ASN.1 module.  Why are the OIDs not part of the ASN.1 module?

Russ
Brian Korver | 3 May 00:19 2003

IPsec PKIX profile draft


For those of you who aren't on the IPsec list, I'd like to
mention that a new revision of the IPsec PKIX profile draft
is available.

  http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-profile-02.txt

This document would benefit greatly from review by additional
PKI experts and vendors, especially those who are familiar with
IPsec PKI deployment issues.  Comments should be sent to the
ipsec <at> lists.tislabs.com mailing list.

-brian
briank <at> briank.com

Jim Schaad | 4 May 09:00 2003

Proxy -05 comments


Comments are divided into two sections, those of substance and
nit-picking.

Substance:

1.  I still get confused because of the language used between PKC policy
and PC policy.  To clarify this I would like to see the following items
changed:

A) change acceptable-pc-policy-set to acceptable-pc-policy-language-set
B) change any-policy to any-policy-language and assign an OID for this
C) in 4.1.3 (c) the discription of the tuple is harder than it needs to
be.  "containing the certificate subject name, proxyPolicy, key usage
extension..."

2) The following text:
    *  InheritAll, as defined by the oid value iso(1) identified-
       organization(3) dod(6) internet(1) security(5) mechanisms(5) 
       pkix(7) ppl(21) inheritall(1)

	says that the ASN.1 module needs the following change

 id-ppl-inheritall           OBJECT IDENTIFIER ::= { id-ppl 1 } 
	
	to

 id-ppl-inheritall           OBJECT IDENTIFIER ::= { id-ppl
inheritall(1) } 

3)  The following text:
    *  Independent, as defined by the oid value iso(1) identified-
       organization(3) dod(6) internet(1) security(5) mechanisms(5) 
       pkix(7) ppl(21) independent(2)

	says that the ASN.1 module needs the following change

 id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl 2 } 

	to

 id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl independent(2) } 

4)  If I have the following chain of certificates, please explain why it
should be rejected

	EE	subject="cn=me"
	PC1	subject="cn=me,cn=1"  Policy=id-pp-inheritall
	PC2	subject="cn=me,cn=1,cn=1" Policy=MySpecialPolicy
	PC3	subject="cn=me,cn=1,cn=1,cn=1" Policy=id-pp-independent

If I set acceptable-pc-policy-set to "inheritall, independent" this get
rejected, but the evaluation code would seem to be fine in terms of
evaluating this policy as MySpecialPolicy does not get involved in
making any proxy decisions for PC3.  It's proxy rights are independent
of any previous statements.

Nits:

1.  Certificates don't issue anything, holders of certificates issue
things.  In section 2.1 I suggest the following text:

  * PI: A "Proxy Issuer" is an entity with an End Entity Certificate or
a Proxy Certificate that issues a Proxy Certificates.

2.  Sec 3.8 - second to last paragarph.  MUST NOT rather than MUST not
--- alt. MUST be absent.

3.  inheritAll and Independent oid definitions in the text.

4.  I don't like this sentence for independent.

       The only rights this PC has are those granted explicitly to it. 

	I suggest

	The only rights the holder of this PC has are those explicitly
granted by other  means than the proxy certificate.

Jim

Hamid Asadi | 4 May 10:14 2003
Picon

Request for CA Trust Evaluation

Hello Dear Sir/Madam
am Hamid Asadi,Master student form Isfahan University of Technology.
I am working on Trust evaluation in public key infrastructure.
Ms David Chadwick  purposed method that based on knowledge based system.
But we wanna to make a new system that is differ from purposed method but we need to know  your view point about many questions about Certificate Authority.
This email has a attachment . You can see  questions that
 Ms  David Chadwick   used for last method.
we wanna you -if possible-  answer those questions according to a specific CPS like Verisign ,Entrust... and assign to each question a number between 0 and 10.If  You wanna answer Questions ,please write the CPS that has been used.
You can see last method that emplemented at http://huan.isi.salford.ac.uk:7007/ .
 
With best regard
Hamid Asadi
Electerical and computer Dep.
Isfahan University of Technology

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
Attachment (Questions.doc): application/msword, 35 KiB
Russ Housley | 5 May 06:24 2003

Re: IPsec PKIX profile draft


Steve Bellovin and myself would like to see support for certificates in 
IKEv2 become a SHOULD requirement.  The authors of this specification 
believe that it could apply to IKEv1 as well as IKEv2.  Perhaps all we need 
to do is reference this document.

Please review it.

Russ

At 03:19 PM 5/2/2003 -0700, Brian Korver wrote:

>For those of you who aren't on the IPsec list, I'd like to
>mention that a new revision of the IPsec PKIX profile draft
>is available.
>
>   http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-profile-02.txt
>
>This document would benefit greatly from review by additional
>PKI experts and vendors, especially those who are familiar with
>IPsec PKI deployment issues.  Comments should be sent to the
>ipsec <at> lists.tislabs.com mailing list.
>
>-brian
>briank <at> briank.com

Denis Pinkas | 5 May 17:10 2003
Picon
Picon

Re: Question about the edition of RFC 3280


Peter,

> hi Denis,

> Do you have some result? 

Thank you for inquiring.

> regards
> Peter

The following people have participated to a meeting held on Monday April, 14 
during the RSA Security Conference :

  - Tim Polk, editor of RFC 3280 and PKIX co-chair;
  - Russ Housley, editor of RFC 3280 and recently designated as
    Security Area Director;
  - Denis Pinkas, PKIX participant;
  - Hoyt Kesterson, chair of the ISO/ITU SC 6 X.509 WG (partly);

History

The change was made during the 48 hours window period for editorial changes. 
The requestor for the change was Stefan Santesson. Neither Russ, Tim or 
Stefan have any record of the e-mail from Stefan that lead to that change.

Russ and Tim said, that in the opinion of the editors, the change that 
happened between draft 12 and RFC 3280 was purely editorial, to make it 
consistent with the sentence that has been added after a long debate 
("Further distinctions between the digitalSignature and nonRepudiation bits 
may be provided in specific certificate policies"). An observation was made 
that a simple way to resolve the consistency would have been to remove the 
additional sentence (which had been accepted on the basis that no other 
change was being made to the remaining text).

However, the RFC editor was wondering whether that change was really 
editorial, but both Steve Kent (co-chair of the PKIX WG) and Jeff Schiller 
(Security Area Director) confirmed that the change was editorial. The PKIX 
list has not been informed of the change.

The Monday discussion

 From the discussion that took place on the Monday, it appears that the 
rational for the use of bits 0 and 1 as defined in both X.509 and RFC 2459 
was not fully understood by Tim Polk.

The rational has to do with the use of private keys in untrusted 
environments: in an untrusted environment, a private key holder cannot make 
sure of the data that is being signed.

In a trusted environment, a private key holder is able to control the data 
that is being signed. For example, if the private key is used to sign 
contracts, the client software may display the contract on which a hash will 
be computed, or if the key is used for authentication purposes, the client 
software may combine the random value sent by a server with a random number 
chosen by the client software.

An example has been used to illustrate the problem:

A signature private key is being used for authentication purposes to open a 
door lock placed in an *untrusted* environment. The door lock sends a 
challenge and the challenge is signed. The signer has no control on the 
value of the challenge. If that challenge happened not to be to be a random 
number, but the hash of a contract, the signer would have signed the 
contract without knowing it ! Without an indication for the key usage it 
would be impossible for the signer to say that he only intended to sign a 
challenge but not a contract.

This is exactly why two bits are being used.

If the key is usable for authentication purposes, then the key usage bit 0 
shall be set.

If the key is usable for non-repudiation purposes, then the key usage bit 1 
shall be set.

In order to make the difference, the signer should use two certificates:

- one for non-repudiation purposes, that is only usable
   in trusted environments;

- one for authentication purposes, usable in any kind
   of environment (i.e.untrusted or trusted).

When using the door lock if a contract has been signed, the signer can say: 
a key corresponding for an authentication certificate has been used, so the 
contract is non valid since a certificate with the bit 1 set (the non 
repudiation bit) should have been used. Now, if the signer willingly 
recognizes that the signature is good, that fine, but it is similar as 
making a transaction with a credit card over the Internet: the card holder 
may repudiate the transaction at any time without the need to prove anything 
and independently of any context.

A certificate policy may further restrict the use of the certificate but may 
not override the meaning of the bits.

Now, if both bits are set in a certificate, what are the implications ?

The private key corresponding to that certificate can only be used safely, 
if always used in trusted environments. For example, a smart card protecting 
the private key is always used with client software trusted by the signer.

It may be observed that all key usage bits (except bit 0) are defined as 
security service bits, while bit 0 is defined as a security mechanism bit 
with the exception of a few security services (notably the non-repudiation 
service).

It would be better to define bit 0 as a service bit saying explicitly which 
are the security services for which the private key can be used for, namely 
an authentication service and/or an integrity service.

A way forward

The topic is being discussed within ISO SC 6 since a Defect Report has been 
raised. A "clarification" is indeed needed, but opinions differ whether it 
is really a "defect" or not. It is desirable to maintain alignment between 
the IETF RFCs and ISO X.509.

At this time it is too early to know which text will be proposed and adopted 
by ISO, but it is clear that the current text from RFC 3280 will *not* be 
used. As a matter of fact, RFC 3280 is no more backwards compatible with RFC 
2459 nor X.509, since the meaning of the DS bit has been changed. In X.509 
and RFC 2459 this bit is set when a digital signature mechanism is being 
used, but not when the digital signature mechanism is used to provide a non 
repudiation service. In RFC 3280, the later restriction has disappeared. The 
signer is thus loosing its argument to repudiate its signature.

When the new proposal from ISO will circulate, the PKIX WG should consider it.

A draft 3280bis document should be started now and include for the time 
being an indication which shall be placed in section 4.2.1.3 (Key Usage) to 
warn the reader that the text is not backward compatible with RFC 2459 and 
that section is subject to changes. People wishing to comply with the text 
from section 4.2.1.3 (Key Usage) from RFC 2459 will be unable to reference 
RFC 3280 until a new RFC is produced. However, X.509 (2000) can be 
referenced instead.

It is expected that ISO could agree on a final text in the September time-frame.

Denis

PS.Extracts from the Introduction of ISO 10181-4 (Non-repudiation 
Framework). "The goal of the Non-repudiation service is to collect, 
maintain, make available and validate irrefutable evidence concerning a 
claimed event or action in order to resolve disputes about the occurence or 
non-occurrence of the event or action".

"Non-repudiation involves the generation of evidence that can be used to 
prove some kind of event or action has taken place, so that this event or 
action cannot be repudiated later".

>>Date: Thu, 10 Apr 2003 10:54:54 +0200
>>From: Denis Pinkas <Denis.Pinkas <at> bull.net>
>>
>>Stefan,
>>
>>Thank you for the response.
>>
>>I realize that very unfortunately both the sender of the message and the 
>>receivers of the message lost the message. :-|
>>
>>Now, looking forward, I would like to make the following proposal:
>>
>>Next week there is the RSA 2003 Security Conference. I will attend the 
>>Conference and I guess may other people from the PKIX WG will do so as well.
>>
>>Since there is the speaker's dinner on the Tuesday and the Gala Dinner of 
>>the Wednesday, I propose to have an informal meeting about key usage bits 0 
>>and 1 on the Monday evening for anyone interrested.
>>
>>I thus propose to meet in the North Lobby, in front of the registration 
>>desks at 5:30 p.m. on the Monday evening.
>>
>>I would like to discuss the meaning of a certificate that has:
>>
>>  1° only the key usage bit 1 set,
>>  2° only the key usage bit 0 set,
>>  3° both the key usage bits 0 and 1 set.
>>
>>   ... when looking at the writing of RFC 2459 and
>>       when looking at the writing of RFC 3280.
>>
>>Denis
>>
> 
> 

Peter Sylvester | 5 May 17:58 2003
Picon
Picon

Re: Question about the edition of RFC 3280


Thanks for your reply. 

Is the description of 'The Monday discussion'
an agreed report shared by the participants of the meeting?

A way forward

> In X.509 and RFC 2459 this bit is set when a digital signature mechanism is being 
  used, but not when the digital signature mechanism is used to provide a non repudiation
  service. In RFC 3280, the later restriction has disappeared. The signer is thus loosing
  its argument to repudiate its signature.

Are you saying that with the new text, when there is ONLY
the DS bit a signer is no longer able to repudiate a signature? 

Hoyt L. Kesterson II | 5 May 20:50 2003
Picon
Picon

Re: Question about the edition of RFC 3280

you can always repudiate anything, even that it was your system doing a key exchange. the question is whether you are successful.

the defect report to which denis is referring is not that new and is not being done as an alignment issue but in response to the obvious confusion on this subject. the first version was drafted at a meeting in september.

it has already had one ballot round but clearly still had some problems. comments on that dtc were addressed at a meeting in london in february with a revision of the dtc that will be resubmitted soon for ballot. (i want to get the new pdam out first).

i don't want to discuss the proposed text here. please wait until it is available to the group. however, one item of text in the first proposal that was not contested in the ballot and is in the revised dtc  that will be balloted

More than one bit may be set in an instance of the keyUsage extension. The setting of multiple bits shall not change the meaning of each individual bit but indicates that the certificate can be used for all of the purposes indicated by the set bits.

i discussed the conclusions of the group working on the dtc in my two presentations at the rsa conference. if interested, you should be able to find my slides on their conference presentation site

    hoyt


At 17:58 +0200 5/5/03, Peter Sylvester wrote:
Thanks for your reply.

Is the description of 'The Monday discussion'
an agreed report shared by the participants of the meeting?


A way forward

> In X.509 and RFC 2459 this bit is set when a digital signature mechanism is being
  used, but not when the digital signature mechanism is used to provide a non repudiation
  service. In RFC 3280, the later restriction has disappeared. The signer is thus loosing
  its argument to repudiate its signature.

Are you saying that with the new text, when there is ONLY
the DS bit a signer is no longer able to repudiate a signature?

Miguel Rodriguez | 6 May 02:58 2003

time stamp of a CMS with multiple signatures

Hi!

 

In TSP (RFC 3161) appendix A there’s a guideline on how to store a time stamp in a CMS, and it says that the messageImprint shall be the hash of the signature field within the SignerInfo  for the SignedData being timestamped. What should be the messageImprint for a SignedData with multiple SignerInfo fields?

 

Thanks,

 

Miguel A. Rodriguez

Software Engineer

SeguriDATA

 


Gmane