headers
Jim Schaad | 3 Mar 2003 07:43

RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt


Russ,

As an implementer, I think of dealing not only with the parameters but
the "data" value associated with the OID as being dependent on the OID.
This means that the following items are indexed on the OID.  The
parameters structure, the public key encoding and the signature value
encoding.  In the case of RSA the signature value encoding is really
simple - i.e. just the bytes - but for some signature algorithms this is
not true.  The fewer tables that I have to do lookups on the easer it is
to write general purpose code.  I would be perfectly happen to assign a
different OID for each different way that the encodings and mathematics
are done.  

A different question is whether the parameters should be different
between the different locations.  I agree that there should be a
restriction on only using PSS with a signature key, however I think
there is an interesting question about the requirement for different
certificates to be assigned if you want to use both SHA-256 and SHA-512
with the PSS key depending on the question of necessary duration of the
signature.

jim

> -----Original Message-----
> From: Russ Housley [mailto:housley <at> vigilsec.com] 
> Sent: Monday, February 24, 2003 1:28 PM
> To: BKaliski <at> rsasecurity.com; jimsch <at> exmsft.com
> Cc: IETF-PKIX <at> imc.org
> Subject: RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Denis Pinkas | 3 Mar 2003 13:48
Picon

Re: I-D ACTION:draft-ietf-pkix-acpolicies-extn-02.txt


To the WG,

I have re-issued a new version of the
Attribute Certificate Policies extension document.

The intent is to fully align the content with the equivalent extension
policy for Public Key Certificates (i.e. certificate policies extension,
id-ce-certificatePolicies): the additions that were initially proposed have 
been removed.

You will (certainly) notice that there is an error in the ASN.1 module which 
omits to import the PolicyQualifierId from RFC 3280. This will be corrected 
once the web server is re-opened.

The new OID is proposed in the arc for attribute certificate attributes
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }

Denis
Permalink | Reply | 0 comments |
headers
Russ Housley | 3 Mar 2003 14:31

Re: I-D ACTION:draft-ietf-pkix-acpolicies-extn-02.txt


Denis:

The document defines an extension, not an attribute.  I have assigned the 
following OID to identify this extension:

    id-pe-acPolicies             OBJECT IDENTIFIER ::= { id-pe 15 }

Russ

At 01:48 PM 3/3/2003 +0100, Denis Pinkas wrote:

>To the WG,
>
>I have re-issued a new version of the
>Attribute Certificate Policies extension document.
>
>The intent is to fully align the content with the equivalent extension
>policy for Public Key Certificates (i.e. certificate policies extension,
>id-ce-certificatePolicies): the additions that were initially proposed 
>have been removed.
>
>You will (certainly) notice that there is an error in the ASN.1 module 
>which omits to import the PolicyQualifierId from RFC 3280. This will be 
>corrected once the web server is re-opened.
>
>The new OID is proposed in the arc for attribute certificate attributes
>id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
>
>Denis
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 3 Mar 2003 16:29

Re: I-D ACTION:draft-ietf-pkix-acpolicies-extn-02.txt


Denis:

Sorry, I misspelled the the name that I assigned to identify this 
extension.  Here is the corrected entry:

    id-pe-ac-policies            OBJECT IDENTIFIER ::= { id-pe 15 }

Russ

At 01:48 PM 3/3/2003 +0100, Denis Pinkas wrote:

>To the WG,
>
>I have re-issued a new version of the
>Attribute Certificate Policies extension document.
>
>The intent is to fully align the content with the equivalent extension
>policy for Public Key Certificates (i.e. certificate policies extension,
>id-ce-certificatePolicies): the additions that were initially proposed 
>have been removed.
>
>You will (certainly) notice that there is an error in the ASN.1 module 
>which omits to import the PolicyQualifierId from RFC 3280. This will be 
>corrected once the web server is re-opened.
>
>The new OID is proposed in the arc for attribute certificate attributes
>id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
>
>Denis
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Sylvester | 3 Mar 2003 18:14
Picon
Picon
Favicon

Re: RFC3161(TSP): doubts about tcp protocol


Hi,

after more than 2 weeks of no response, it would be nice from the editor
of 3161bis to indicate a procedure to get whatever kind of answer to this
question as a possible clarification into the 3161bis document.

Peter

> From: "Pere Fiol" <pfiol <at> semarket.com>
> To: "ietf" <ietf-pkix <at> imc.org>
> Subject: RFC3161(TSP): doubts about tcp protocol 
> Date: Thu, 13 Feb 2003 17:47:55 +0100
> 
> Hi,
> 
> I've developed a TSA but I have a doubt in TCP protocol: if a client
> sends a request to TSA with invalid TCP message (for example with a flag
> different of '00'H, with wrong number of bytes in length,...) What must
> do a TSA in this situations?? RFC3161 mustn't talk something about it??
> 
> Thanks and Best Regards,
> Pere Fiol
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 3 Mar 2003 19:19
Picon
Picon
Picon
Favicon

Re: RFC3161(TSP): doubts about tcp protocol


Peter Sylvester <Peter.Sylvester <at> edelweb.fr> writes:

>after more than 2 weeks of no response, it would be nice from the editor of
>3161bis to indicate a procedure to get whatever kind of answer to this
>question as a possible clarification into the 3161bis document.

Well, as a non-editor of 3161, I guess I can provide an implementor's comment
to help the original poster out: Since the TCP protocol in RFC 3161 serves no
identifiable purpose, and since I've seen implementations put all sorts of
weird stuff in there, my code just strips the TCP header out and uses the
ASN.1 data.  This means it works with any implementation, whether they get the
TCP protocol wrapper right or not (I think some do it via memcpy() of a
template, based on values I've had returned).

(I simpler alternative is just to forget about it and use HTTP transport,
 which has well-defined semantics).

Peter.
Permalink | Reply | 6 comments |
headers
Anders Rundgren | 3 Mar 2003 22:44
Picon

Trivial PKI Question


A "TRIVIAL" PKI QUESTION
-----------------------------------

Assume that you have a business message like a purchase order

    <Order>
        <From name="Big Buyer Corp.">
            <OurRef name="John Doe"/>
        </From>
        <To name="MegaCar International"/>
        <Item>10 Medium-sized SUVs</Item>
        <Comment>Make it quick please!</Comment>
    </Order>

Now assume that "Big Buyer Corp." is an advanced organization
using digital signatures.

==============================================
Question:  How should the identity as expressed in the document
relate to the identity as expressed by the signer's certificate?
==============================================

Among the complications we find

1.  The PKI-identity is presumably "strong" as it is vouched for by a
     CA, while the identity in the business document is only "claimed"
     by the entity itself.  ==> The PKI identity is governing?

2.  The hierarchical naming system used by PKI (X.500) is completely
(Continue reading)

Permalink | Reply | 4 comments |
headers
Manger, James H | 4 Mar 2003 01:11

RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt


> I want the PKI standards to become stable, permitting development and deployment.

draft-ietf-pkix-rsa-pkalgs-00.txt does not offer stability.  By defining new public key alg ids for 2
algorithms (RSASA-PSS signatures & RSAES-OAEP encryption) it immediately means new versions of every
other existing public key alg id need to be defined so they also support the algorithm constraint concept. 
A precession of new public key alg ids (for existing keys and existing algs) can hardly be called "stability".

> [can] PKI components more easily accept a new algorithm OID or a new extension definition

The question should be "can PKI components more easily accept a procession of new algorithm OIDs over an
indefinite period or a new extension".

A new extension should be easier to accepted as the rules for processing unrecognised extensions are
already well defined, understood & implemented.

> an impact on certification path validation logic  ..  LESS ripple impact

I am not sure what you mean.  Could you give an example?

> the algorithm OID is "fail safe."

Marking an extension as critical is just as fail safe as using a new public key alg id.  The extension approach
gives certificate issuers the option to choose (on a per-certificate basis) to enforce algorithm
constraints in a fail safe or more lenient manner.  This is a benefit of extensions, not a disadvantage.

Sensible security policies might be:
1* Any application or protocol must be able to support multiple algorithms (in case weaknesses are
discovered in one).
2* Any particular key should only be used with one algorithm.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jean-Marc Desperrier | 4 Mar 2003 01:31
Picon
Favicon

Re: RFC3161(TSP): doubts about tcp protocol


Peter Gutmann wrote:

>Peter Sylvester <Peter.Sylvester <at> edelweb.fr> writes:
>  
>
>>after more than 2 weeks of no response, it would be nice from the editor of
>>3161bis to indicate a procedure to get whatever kind of answer to this
>>question as a possible clarification into the 3161bis document.
>>
One possible solution would be that errors that can be detected at TCP 
protocol level without decoding anything in the data should receive a 
TCP protocol level error in return (errorMsgRep : 06).
3161 is restricting errorMsgRep to be only an answer to an invalid pollReq.
Is it really intended that it would be it's sole usage ?

In my opinion, it would make sense in a layer oriented handling of 
message to do that.
If the data didn't make it through the TCP protocol layer because that 
layer detected an inconsistency, then it will get back a TCP error.
If  the data makes it through up to the TimeStampReq decoding layer, 
then that layer will format a TimeStampResp message as an error response.

But for implementers, using only answers of finalMsgRep with the error 
inside the TimeStampResp would convert more directly to what is done for 
the http protocol (but you could map errorMsgRep to "Status: 403 human 
readable error\n\n" in HTTP).

>[...] my code just strips the TCP header out and uses the
>ASN.1 data.  This means it works with any implementation, whether they get the
(Continue reading)

Permalink | Reply | 5 comments |
headers
Olle Mulmo | 4 Mar 2003 03:08
Picon
Picon
Favicon

RE: Trivial PKI Question


Anders,

For S/MIME, the problem you state was circumvented by putting the
email address in SubjectAltName::rfc822Name. In the case of Kerberos
and PKInit, they added the Kerberos principal name in SubjectAltName
as well. Same thing with Microsoft and their smart card login.

So why not just create another such circumvention for XML-based
naming? Something like an OtherName of type

  XmlName ::= SEQUENCE {
     identifier        UTF8String,
     nameSpace  [0]    UTF8String OPTIONAL }

/Olle

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org
[mailto:owner-ietf-pkix <at> mail.imc.org]On Behalf Of Anders Rundgren
Sent: den 3 mars 2003 22:45
To: ietf-pkix <at> imc.org
Subject: Trivial PKI Question

A "TRIVIAL" PKI QUESTION
-----------------------------------

Assume that you have a business message like a purchase order

    <Order>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane