Subject: Check out hot deals

From: <[email-masked]>
Date: Sat, 28 Feb 2009 15:09:00 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.flipzap.com, click on "My Account",
click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.

Or unsubscribe at
http://flipzap.com/faq.php

Privacy Statement |
Terms & Conditions |
Contact

KEYWORD Ltd.

Tower Bridge Business Complex. Unit 9, B338. 247 Clements Road. London. SE72 5DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1RKLnA7076401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 13:21:49 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1RKLnEq076400; Fri, 27 Feb 2009 13:21:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1RKLc96076392 for ; Fri, 27 Feb 2009 13:21:48 -0700 (MST) (envelope-from [email-masked])
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99918.FDF59A75"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: TAC I-D comments and responses
Date: Fri, 27 Feb 2009 15:21:37 -0500
Message-ID: <[email-masked]>
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: TAC I-D comments and responses
Thread-Index: AcmZBP28q7odKhMuQzm7UQ4mhV8vDQACiq3Q
References: <[email-masked]>
From: "Kemp, David P."
To:
X-OriginalArrivalTime: 27 Feb 2009 20:17:07.0578 (UTC) FILETIME=[5D0715A0:01C99918]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C99918.FDF59A75
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

A minor nit on the rewording:

=20

The Attributes field MAY also contain a PKCS#9 [RFC2985]
extensionRequest attribute used to carry information about certificate
extensions the requester wishes to be included in a certificate. The
profile for certificate extensions is specified in RFC5280[2].

=20

Other PKCS#10 attributes (e.g., an attribute with an extension OID as
its type) can be sent to the CA. PKCS#10 says CAs may use the contents
of PKCS#9 attributes, "as well as other information known to the CA" to
construct certificate extensions. So sending a bare extension attribute
might conceivably result in that extension being included in the issued
certificate. But the documented way to request an extension is to use
the extensionRequest attribute.

=20

Dave

=20

=20

From: David A. Cooper

- Section 5.3.1, Attributes: "This attribute contains
X509v3 Certificate Extensions." Which attribute? Not the
id-kisa-tac attribute mentioned in the previous sentence? Is
inclusion of extension in the PKCS10 optional or are there
certain extensions that must be included?

Whether extensions are required, optional, or permitted is a function of
the CP for the TAC CA. However, We can add a note that, in general, it
is a bad idea to allow users to include extensions in a cert request
because that probably will allow the BI to match the issued cert to the
user.

The biggest problem is simply that the text says "this attribute" and I
cannot what tell which attribute it means by "this". Perhaps the text
could be reworded as (if my proposed rewording is technically correct):

Attributes=20
PKCS10[3] defines the attributes field as key-value pairs =20
where the key is an OID and the value's structure depends on the =20
key. The Attributes field MUST include the id-kisa-tac attribute,
which holds the Token and is defined below. The Attributes field
MAY also contain X509v3 Certificate Extensions that the subscriber
would like to have included in the certificate. The profile for
extensions in certificate requests is specified in the RFC5280[2].

=20

------_=_NextPart_001_01C99918.FDF59A75
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

A minor nit on the rewording:

The Attributes field =
MAY also
contain a PKCS#9 [RFC2985] extensionRequest attribute used to carry =
information
about certificate extensions the requester wishes to be included in a
certificate.  The profile for certificate extensions is specified =
in RFC5280[2].

Other PKCS#10 attributes (e.g., an attribute with an =
extension
OID as its type) can be sent to the CA.  PKCS#10 says CAs may use =
the contents
of PKCS#9 attributes, “as well as other information known to the =
CA” to
construct certificate extensions.  So sending a bare extension =
attribute might
conceivably result in that extension being included in the issued =
certificate.
But the documented way to request an extension is to use the =
extensionRequest
attribute.

Dave

From: David A. Cooper

- Section 5.3.1, Attributes: "This attribute =
contains

X509v3 Certificate Extensions."  Which attribute?  =
Not
the

id-kisa-tac attribute mentioned in the previous sentence?  =
Is

inclusion of extension in the PKCS10 optional or are there

certain extensions that must be included?

Whether extensions are required, optional, or =
permitted
is a function of the CP for the TAC CA. However, We can add a note that, =
in
general, it is a bad idea to allow users to include extensions in a cert
request because that probably will allow the BI to match the issued cert =
to the
user.

The biggest problem is simply that the text says "this =
attribute" and
I cannot what tell which attribute it means by "this".  =
Perhaps
the text could be reworded as (if my proposed rewording is technically
correct):

Attributes

PKCS10[3] defines the =
attributes
field as key-value pairs

where the key is an OID and the value's structure depends =
on
the

key.  The Attributes field MUST include the =
id-kisa-tac
attribute,

which holds the Token and is defined below.  The =
Attributes
field

MAY also contain X509v3 Certificate Extensions that the =
subscriber

would like to have included in the certificate.   =
The
profile for

extensions in certificate requests is specified in the =
RFC5280[2].

------_=_NextPart_001_01C99918.FDF59A75--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1RH3Mhc065096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 10:03:22 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1RH3M0r065095; Fri, 27 Feb 2009 10:03:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1RH3JqQ065087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Feb 2009 10:03:20 -0700 (MST) (envelope-from [email-masked])
Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n1RH2HmE025106; Fri, 27 Feb 2009 12:02:17 -0500
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id n1RH2GEl019266; Fri, 27 Feb 2009 12:02:16 -0500
Message-ID: <[email-masked]>
Date: Fri, 27 Feb 2009 12:02:16 -0500
From: "David A. Cooper"
User-Agent: Thunderbird 2.0.0.19 (X11/20090114)
MIME-Version: 1.0
To: Stephen Kent
CC: [email-masked]
Subject: Re: TAC I-D comments and responses
References:
In-Reply-To:
Content-Type: multipart/alternative; boundary="------------000508000602040505000606"
X-NIST-MailScanner-Information:
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.
--------------000508000602040505000606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Steve,

Thanks for taking the time to respond to my comments. I've included my
responses in-line below for those items that I believe still need to be
addressed.

Dave

Stephen Kent wrote:
> Dave,
>
> Thanks for your careful review of the TAC I-D. Here are responses to
> your comments,
>
> Section 3 (Requirements):
>
> - This section begins by stating that the "document describes a
> new separation-of-authority model". How does the model in this
> document differ from the one in [13], "An Architecture for
> Pseudonymous e-Commerce"? What properties does the protocol
> in this document have that the protocol in [13] does not?
> *In the architecture for Pseudonymous e-Commerce, a CA can link the
> pseudonym in the subject field to the real identity unilaterally,
> which can lead to a potential 'big brother problem'. In order to
> address this issue, this document proposes the separation of authority
> concepts (two CAs to issue TAC, which tries to prevent one CA from
> linking pseudonym to real identity unilaterally).
> *

This is incorrect. In "An Architecture for Pseudonymous e-Commerce",
the subscriber requests a certificate from CA A (i.e., the BI). The
subscriber authenticates to CA A using his/her real identity. CA A
issues certificate A to the subscriber with a pseudonymous subject
name. The subscriber then requests a certificate from CA B (i.e., the
AI). The subscriber authenticates to CA B using certificate A. CA B
issues certificate B to the subscriber with a pseudonymous subject name
(a name that cannot be connected to the subject name in certificate A).
The subscriber then uses certificate B to authenticate him/herself
during normal transactions. Thus, the subscribers' real identity cannot
be tied to the subject name in certificate B without the cooperation of
both CA A and CA B.

Note that the subscriber could even use certificate B to obtain yet
another pseudonymous certificate from CA C so that it would require the
collusion of three CAs to tie the pseudonymous identity that he/she uses
to his/her real identity.

> Section 5 (Issuing a TAC):
>
> - The protocol involves a complicated scheme involving split
> signatures and blind signatures. The use of split signatures
> complicates the issuance of both certificates and CRLs, yet
> the need for this scheme is not clear. It was previously
> argued that the split signature scheme prevents the CA from
> issuing a certificate to a user by itself, which could
> result in a non-traceable certificate. However, the CA
> could still create a non-traceable certificate by simply
> not maintaining the link between the TAC and the Token.
> An untrustworthy CA could even use a Token issued by the BI
> to one user as the basis for issuing a certificate to a
> different user. Similarly, a BI could issue a Token to a
> user without first identifying that user. Since both the AI
> and BI need to cooperate to identify the user associated with
> a TAC, there is no benefit in trying to prevent the AI from
> issuing a non-traceable certificate, as there is no way to
> force the AI (or BI) from cooperating in the tracing of a
> certificate if the AI (or BI) simply chooses not the store
> the information required to perform the trace.
>
> *It's fair to say that use of the mechanisms mandated by the protocol
> is not a technical guarantee of the split between the RA and CA
> functions, e.g., for the reasons you note. However, use of these
> mechanisms probably makes it easier to conduct an audit that verifies
> the desired separation of duties. One could define a TAC system that
> did not specify these mechanistic details. However, verifying that
> such a system provides the desired separation would be more difficult,
> on a case-by-case basis. Since you work at NIST, I think a reasonable
> analogy here is with some of the specs used for FIPS 140-n compliance.
> For example, there is a spec for a PRNG because it makes it easy for a
> lab to evaluate a product claiming compliance with 140, not because
> that PRNG is the only good way to generate random values for use in
> crypto algorithms.
> *

Can you please explain how the use of threshold signatures (combined
with blinded signatures) makes it easier to conduct an audit that
verifies that the AI and BI are performing their duties properly?

> - Section 5 says that "Blinding is also defined for signature
> algorithms like DSA, but the explanation is more complex, since
> DSA does not natively encrypt data." Can a reference be
> provided? I can only find references to papers that propose
> blinding schemes for variants of DSA.
> *You can refer to the blind DSA signature based on MacKenzie and
> Reiter,*_* http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf*_*.
> *

This paper seems to describe a threshold signature scheme (in particular
two-party generation of DSA signatures), not a blind signature scheme.

> **- Section 5.1, Step 1 states "The signature on a Token is
> generated by the BI using a private key employed only for
> this purpose." Step 2 states "The signature (SignatureValue
> of SignerInfo) is generated using the BI's private signature
> key, corresponding to the public key present in the BI's
> certificate. (Note that this certificate is just a certificate
> suitable for use with TLS, and is NOT the split-key certificate
> used to verify a TAC.)" May the BI use the same private key
> and certificate to sign Tokens and for TLS authentication? If
> not (as stated in Step 1), then why is it necessary for the
> certificate corresponding to the Token signing key to be
> "suitable for use with TLS"? Many other places in the document
> state that certificates used to verify signatures on CMS
> messages should be "suitable for use with TLS".
>
> *There are several questions here:*
> *
> - We recommend use of different keys for TLS authentication and for
> Token signing, as you noted above. Our advice is conservative,
> following the principle that one should use distinct keys for distinct
> purposes. Key generation is not so expensive as to warrant reuse of
> keys for these two purposes.*
> *
> - we use the phrase "suitable for use with TLS" to distinguish the
> certificates used for CMS message verification as distinct from the
> split-key certificates, as a shorthand. If you have a preferred
> wording for EE certificates being used in these cases, I think we
> would be happy to use that wording instead.
> *

Why not say "(Note that this certificate is just a certificate suitable
for use with CMS, and is NOT the split-key certificate used to verify a
TAC.)"?

> - Section 5.1, Step 6 states:
> Note that the user should be prepared to accommodate delays
> in the certificate issuance process. For example, a
> connection between the user and the AI might fail sometime
> after the user submits a certificate request at the end of
> Step 3 and before the AI returns the certificate at the end
> of Step 6. If this happens, the user should resubmit the
> request. The AI and BI retain sufficient state to be able to
> match the resubmitted request to the original request, and
> respond accordingly.
>
> This seem appropriate, but it is contradicted by the following
> text in Section 5.1, Step 4:
> Next, the AI compares the received Token against a cache of
> recent (i.e., not "timed out"), validated Tokens. If a
> duplicate is detected, the certificate request is rejected as
> a replay.
>
> *The comments in step 4 are design guidance; they don't impose
> specific constraints on how long an AI holds onto a Token. We can
> revise the step 6 text to note that although the AI and BI maintain
> state, they do not do so forever.
> *

The problem isn't that Step 6 implies that the AI and BI have to
maintain state forever (although that is a good point as well). The
problem is that Step 4 says that "If a duplicate is detected, the
certificate request is rejected as a replay". Step 6 implies that a AI
should (when possible) respond to a resubmitted request by resending the
previous generated response, whereas Step 4 implies that the AI must
respond to a resubmitted request by rejected it (i.e., by not responding
to the request).

> - Section 5.2, Step A states that "we propose creating a second
> CA, under the TAC CA and have it be the CRL issuer for the EE
> certificates issued by the TAC CA." However, the actual
> proposal is to create a second (CRL signing only) key for the
> CA, not to create a second CA.
>
> *Sorry if this is not clear enough. The other CRL is issued using a
> private key known to the AI unilaterally. Since the key is distinct,
> but we want the CRL Issuer name to be the same, we elected to have a
> new CA, represented by a new CA certificate issued under the jointly
> managed CA certificate.
> *

A CA is identified by its name, not by its key. So, in the scenario you
are describing, you are not creating a new CA that issues CRLs under the
same name as the AI. You have a single CA with two keys, one for
signing certificates and one for signing CRLs.

> ****- Section 5.2, Step A states that "If the AI uses OCSP [14] or
> SCVP [15] to convey the revocation status of TACs, an equivalent
> procedure is employed." SCVP cannot be used by a CA to convey
> status information in the same way that CRLs and OCSP can, and
> so it should not be mentioned here.
>
> *SCVP responses are more encompassing than OCSP and CRLs, but they
> can still provide an RP with an indication of whether a given
> certificate has been revoked, or not. So, I'm not sure why you feel
> that SCVP ought not be mentioned here.
> *

OCSP can (generally) be used in one of two ways: (1) it can be operated
on behalf of a CA to provide all relying parties with status information
for the certificates issued by that CA; or (2) it can be operated on
behalf a relying party to provide status information for all
certificates that the relying party wishes to validate. Section 5.2,
Step A is describing (1), which is appropriate for OCSP but not SCVP.
Trust model (2) would work for either OCSP or SCVP, but the use of SCVP
here would relate to the way in which the relying party obtains status
information, not the way in which the AI makes status information available.

> **- Section 5.3.1, Attributes: "This attribute contains
> X509v3 Certificate Extensions." Which attribute? Not the
> id-kisa-tac attribute mentioned in the previous sentence? Is
> inclusion of extension in the PKCS10 optional or are there
> certain extensions that must be included?
> *Whether extensions are required, optional, or permitted is a function
> of the CP for the TAC CA. However, We can add a note that, in general,
> it is a bad idea to allow users to include extensions in a cert
> request because that probably will allow the BI to match the issued
> cert to the user.
> *

The biggest problem is simply that the text says "this attribute" and I
cannot what tell which attribute it means by "this". Perhaps the text
could be reworded as (if my proposed rewording is technically correct):

Attributes
PKCS10[3] defines the attributes field as key-value pairs
where the key is an OID and the value's structure depends on the
key. The Attributes field MUST include the id-kisa-tac attribute,
which holds the Token and is defined below. The Attributes field
MAY also contain X509v3 Certificate Extensions that the subscriber
would like to have included in the certificate. The profile for
extensions in certificate requests is specified in the RFC5280[2].

> **- Section 5.3.1 says:
> This profile applies the following additional constraints to
> fields that MAY appear in a CertificationRequest Object:
>
> signatureAlgorithm
> This field specifies the signature algorithm.
>
> What does this mean? The signatureAlgorithm is mandatory and
> this text does not impose any constraints on the field.
>
> *We'll fix the text to reflect the fact that this is a mandatory field.
> *

Why not simply delete this? Based on the second sentence of Section
5.3.1, the document should not even bother to mention a field unless it
is to specify an "additional constraint".

> **- Section 5.3.2, Extensions: Is inclusion of extension optional
> or are there certain extensions that must be included?
> *See the reply above for 5.3.1.
> *

As above, the text about Extensions should simply be deleted unless the
document will impose "additional constraints".

> **General:
>
> *We'll review the document and fix the citation errors.
>
> *- The protocol messages defined in this document all use the
> same basic format: a CMS signed data object. For all of these
> messages, the eContentType is specified as id-data and
> (presumably) the MIME type is application/pkcs7-mime, perhaps
> with the parameter smime-type=signed-data. Each of the
> protocol messages should have its own MIME type and/or
> eContentType. Otherwise, there is no way for the recipient to
> know how to process the data.
>
> *We adopted use of CMS to move the data between the AI and BI via our
> TLS-protected channel because Jim Schaad noted that we needed to have
> some way to carry the data that is already known and accepted by the
> application ADs, and CMS satisfies this criteria. Presumably we can
> use a new content type, w/o encryption and still keep them happy, even
> though this is NOT a content type that is generally supported.**
> *

If using a contentType other than id-data is problematic (although I
can't see why since no standard library can meaningfully process
something tagged as id-data), at least specify a different MIME type for
each message.

> **- Referring to the certificates issued using this protocol as
> anonymous rather than pseudonymous is confusing. The editors
> note in the Introduction that pseudonymous is the correct term,
> but still choose to use the misleading term "anonymous". I do
> not agree that the terms are commonly used interchangeably, and
> believe that the use of the correct term, pseudonymous, would
> make the privacy properties of the certificates more clear.
> People already understand the idea of using different names
> (pseudonyms) in different contexts in order to increase privacy.
> Anonymity is achieved by not identifying (authenticating)
> oneself at all, not by identifying oneself using a pseudonym.
>
> *It is true that the terms are not equivalent, even though many folks
> do use them interchangeably. However, the term pseudonymous isn't
> ideal here as it suggests that only RPs don't know the true identity
> of the Subject. TACs do provide a form of conditional anonymity, hence
> the name.
> *

I have never heard this definition of pseudonymous. Anonymous implies
that no name is used, whereas pseudonymous implies that a fictitious
name is used. There is no implication that anyone (other than the person
using the pseudonym) knows the true identity of the person using the
pseudonym.

> **- The protocol should allow for the possibility of rekey. In many
> cases, users will want to use the same pseudonym for an
> extended period of time. For example, many people use a
> pseudonym when posting to message boards or when selling items
> on-line (e.g., on eBay). People who earn good reputations as
> sellers would not want to have to periodically change
> pseudonyms. A TAC for these users would allow them perform
> strong authentication to prevent others from accessing their
> accounts. The TAC would allow the sellers to keep their true
> identities a secret while at the same time reassuring buyers
> that sellers' true identities could be determined in case a
> seller committed fraud. While this type of scenario may not
> have been the original motivation for TAC, is there any reason
> that it should not be supported?
> *I agree that the ability to retain the same pseudonym would have
> advantages in the contexts you cite above, but we dropped support for
> rekey as it added complexity (as noted by Jim) that we didn't want to
> address at this stage.*
*
*If the requirement to use a threshold signature scheme were removed,
then the AI could accept and process standard certificate management
request messages (including rekey requests) and so support for rekey
would not add any additional complexity. It is only the use of the
threshold signature scheme that makes support for standard certificate
management operations complex, and as noted above, I still do not see
how the threshold signature scheme requirement provides any real benefit.

**

--------------000508000602040505000606
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Steve,

Thanks for taking the time to respond to my comments.  I've included my
responses in-line below for those items that I believe still need to be
addressed.

Dave

Stephen Kent wrote:

TAC I-D comments and responses

Dave,

Thanks for your careful review of the TAC
I-D.  Here are responses to your comments,

Section 3 (Requirements):

- This section begins by stating that the "document describes
a

new separation-of-authority model".  How does the
model in this

document differ from the one in
[13], "An Architecture for

Pseudonymous e-Commerce"?  What properties does the
protocol

in this document have that the
protocol in [13] does not?

In the architecture for Pseudonymous
e-Commerce, a CA can link the pseudonym in the subject field to the
real identity unilaterally, which can lead to a potential 'big brother
problem'. In order to address this issue, this document proposes the
separation of authority concepts (two CAs to issue TAC, which tries to
prevent one CA from linking pseudonym to real identity
unilaterally).

This is incorrect.  In "An Architecture for Pseudonymous e-Commerce",
the subscriber requests a certificate from CA A (i.e., the BI).  The
subscriber authenticates to CA A using his/her real identity.  CA A
issues certificate A to the subscriber with a pseudonymous subject
name.  The subscriber then requests a certificate from CA B (i.e., the
AI).  The subscriber authenticates to CA B using certificate A.  CA B
issues certificate B to the subscriber with a pseudonymous subject name
(a name that cannot be connected to the subject name in certificate
A).  The subscriber then uses certificate B to authenticate him/herself
during normal transactions.  Thus, the subscribers' real identity
cannot be tied to the subject name in certificate B without the
cooperation of both CA A and CA B.

Note that the subscriber could even use certificate B to obtain yet
another pseudonymous certificate from CA C so that it would require the
collusion of three CAs to tie the pseudonymous identity that he/she
uses to his/her real identity.

Section 5 (Issuing a TAC):

- The protocol involves a complicated scheme involving split

signatures and blind signatures.  The use of split
signatures

complicates the issuance of both certificates and CRLs, yet

the need for this scheme is not clear.  It was
previously

argued that the split signature scheme prevents the CA from

issuing a certificate to a user by itself, which could

result in a non-traceable certificate.  However, the
CA

could still create a non-traceable certificate by simply

not maintaining the link between the TAC and the Token.

An untrustworthy CA could even use a Token issued by the BI

to one user as the basis for issuing a certificate to a

different user.  Similarly, a BI could issue a Token to
a

user without first identifying that user.  Since both the
AI

and BI need to cooperate to identify the user associated
with

a TAC, there is no benefit in trying to prevent the AI from

issuing a non-traceable certificate, as there is no way to

force the AI (or BI) from cooperating in the tracing of a

certificate if the AI (or BI) simply chooses not the store

the information required to perform the trace.

It's fair to say that use of the mechanisms mandated by the
protocol is not a technical guarantee of the split between the RA and
CA functions, e.g., for the reasons you note. However, use of these
mechanisms probably makes it easier to conduct an audit that verifies
the desired separation of duties. One could define a TAC system that
did not specify these mechanistic details. However, verifying that
such a system provides the desired separation would be more difficult,
on a case-by-case basis. Since you work at NIST, I think a reasonable
analogy here is with some of the specs used for FIPS 140-n compliance.
For example, there is a spec for a PRNG because it makes it easy for a
lab to evaluate a product claiming compliance with 140, not because
that PRNG is the only good way to generate random values for use in
crypto algorithms.

Can you please explain how the use of threshold signatures (combined
with blinded signatures) makes it easier to conduct an audit that
verifies that the AI and BI are performing their duties properly?

- Section 5 says that "Blinding is also defined for
signature

algorithms like DSA, but the explanation
is more complex,
since

DSA does not natively encrypt data."  Can a reference
be

provided?  I can only find references to papers that
propose

blinding schemes for variants of
DSA.

You can refer to the blind DSA
signature
based on MacKenzie and Reiter,
http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf.

This paper seems to describe a threshold signature scheme (in
particular two-party generation of DSA signatures), not a blind
signature scheme.

- Section 5.1, Step 1 states "The
signature on a Token is

generated by the BI using a private key employed only for

this purpose."  Step 2 states "The signature
(SignatureValue

of SignerInfo) is generated using the BI's private
signature

key, corresponding to the public key present in the BI's

certificate. (Note that this certificate is just a
certificate

suitable for use with TLS, and is NOT the split-key
certificate

used to verify a TAC.)"  May the BI use the same
private key

and certificate to sign Tokens and for TLS authentication?
If

not (as stated in Step 1), then why is it necessary for the

certificate corresponding to the Token signing key to be

"suitable for use with TLS"?  Many other places
in the document

state that certificates used to verify signatures on CMS

messages should be "suitable for use with TLS".

There are several questions here:

- We recommend use of different keys for TLS authentication and for
Token signing, as you noted above. Our advice is conservative,
following the principle that one should use distinct keys for distinct
purposes. Key generation is not so expensive as to warrant reuse of
keys for these two purposes.

-  we use the phrase "suitable for use with TLS" to
distinguish the certificates used for CMS message verification as
distinct from the split-key certificates, as a shorthand. If you have
a preferred wording for EE certificates being used in these cases, I
think we would be happy to use that wording instead.

Why not say “(Note that this certificate is just a certificate suitable
for use with CMS, and is NOT the split-key certificate used to verify a
TAC.)”?

- Section 5.1, Step 6 states:

Note that the user should be prepared
to
accommodate delays

in the certificate issuance process. For
example, a

connection between the user and the AI might
fail sometime

after the user submits a certificate request
at the end of

Step 3 and before the AI returns the
certificate at the end

of Step 6. If this happens, the user should
resubmit the

request. The AI and BI retain sufficient
state to be able to

match the resubmitted request to the original
request, and

respond accordingly.

This seem appropriate, but it is contradicted by the
following

text in Section 5.1, Step 4:

Next, the AI compares the received Token
against a cache of

recent (i.e., not "timed out"),
validated Tokens. If a

duplicate is detected, the certificate
request is rejected as

a replay.

The comments in step 4 are design guidance; they don't impose
specific constraints on how long an AI holds onto a Token.  We
can revise the step 6 text to note that although the AI and BI
maintain state, they do not do so forever.

The problem isn't that Step 6 implies that the AI and BI have to
maintain state forever (although that is a good point as well).  The
problem is that Step 4 says that "If a duplicate is detected, the
certificate request is rejected as a replay".  Step 6 implies that a AI
should (when possible) respond to a resubmitted request by resending
the previous generated response, whereas Step 4 implies that the AI
must respond to a resubmitted request by rejected it (i.e., by not
responding to the request).

- Section 5.2, Step A states that "we
propose creating a
second

CA, under the TAC CA and have it be the CRL issuer for the
EE

certificates issued by the TAC CA."  However, the
actual

proposal is to create a second (CRL signing only) key for
the

CA, not to create a second CA.

Sorry if this is not clear enough. The other CRL is issued using a
private key known to the AI unilaterally. Since the key is distinct,
but we want the CRL Issuer name to be the same, we elected to have a
new CA, represented by a new CA certificate issued under the jointly
managed CA certificate.

A CA is identified by its name, not by its key. So, in the scenario you
are describing, you are not creating a new CA that issues CRLs under
the same name as the AI.  You have a single CA with two keys, one for
signing certificates and one for signing CRLs.

- Section 5.2, Step A states
that "If the AI uses OCSP [14]
or

SCVP [15] to convey the revocation status of TACs, an
equivalent

procedure is employed."  SCVP cannot be used by a CA
to convey

status information in the same way that CRLs and OCSP can,
and

so it should not be mentioned here.

SCVP responses are more  encompassing than OCSP and CRLs, but
they can still provide an RP with an indication of whether a given
certificate has been revoked, or not. So, I'm not sure why you feel
that SCVP ought not be mentioned here.

OCSP can (generally) be used in one of two ways: (1) it can be operated
on behalf of a CA to provide all relying parties with status
information for the certificates issued by that CA; or (2) it can be
operated on behalf a relying party to provide status information for
all certificates that the relying party wishes to validate.  Section
5.2, Step A is describing (1), which is appropriate for OCSP but not
SCVP.  Trust model (2) would work for either OCSP or SCVP, but the use
of SCVP here would relate to the way in which the relying party obtains
status information, not the way in which the AI makes status
information available.

- Section 5.3.1, Attributes: "This
attribute contains

X509v3 Certificate Extensions."  Which attribute?
Not the

id-kisa-tac attribute mentioned in the previous sentence?
Is

inclusion of extension in the PKCS10 optional or are there

certain extensions that must be included?

Whether extensions are required, optional, or permitted is a
function of the CP for the TAC CA. However, We can add a note that, in
general, it is a bad idea to allow users to include extensions in a
cert request because that probably will allow the BI to match the
issued cert to the user.

The biggest problem is simply that the text says "this attribute" and I
cannot what tell which attribute it means by "this".  Perhaps the text
could be reworded as (if my proposed rewording is technically correct):

Attributes

PKCS10[3] defines the attributes field as key-value pairs

where the key is an OID and the value's structure depends on the

key.  The Attributes field MUST include the id-kisa-tac attribute,

which holds the Token and is defined below.  The Attributes field

MAY also contain X509v3 Certificate Extensions that the subscriber

would like to have included in the certificate.   The profile for

extensions in certificate requests is specified in the RFC5280[2].

-
Section 5.3.1 says:

This profile applies the following additional
constraints to      fields that MAY appear in
a CertificationRequest Object:

signatureAlgorithm

This field specifies the signature algorithm.

What does this mean?  The signatureAlgorithm is mandatory
and

this text does not impose any constraints on the field.

We'll fix the text to reflect the fact that this is a mandatory
field.

Why not simply delete this?  Based on the second sentence of Section
5.3.1, the document should not even bother to mention a field unless it
is to specify an "additional constraint".

- Section 5.3.2, Extensions: Is
inclusion of extension
optional

or are there certain extensions that must be
included?

See the reply above for 5.3.1.

As above, the text about Extensions should simply be deleted unless the
document will impose "additional constraints".

General:

We'll review the document and fix the citation errors.

- The protocol messages defined in this document all use the

same basic format: a CMS signed data object.  For all of
these

messages, the eContentType is specified as id-data and

(presumably) the MIME type is application/pkcs7-mime,
perhaps

with the parameter smime-type=signed-data.  Each of
the

protocol messages should have its own MIME type and/or

eContentType.  Otherwise, there is no way for the
recipient to

know how to process the
data.

We adopted use of CMS to move the data between the AI and BI
via our TLS-protected channel because Jim Schaad noted that we needed
to have some way to carry the data that is already known and accepted
by the application ADs, and CMS satisfies this criteria. Presumably we
can use a new content type, w/o encryption and still keep them happy,
even though this is NOT a content type that is generally
supported.

If using a contentType other than id-data is problematic (although I
can't see why since no standard library can meaningfully process
something tagged as id-data), at least specify a different MIME type
for each message.

-
Referring to the certificates
issued using this protocol as

anonymous rather than pseudonymous is confusing.  The
editors

note in the Introduction that pseudonymous is the correct
term,

but still choose to use the misleading term
"anonymous".  I do

not agree that the terms are commonly used interchangeably,
and

believe that the use of the correct term, pseudonymous,
would

make the privacy properties of the certificates more
clear.

People already understand the idea
of using different names

(pseudonyms) in different contexts in order to increase
privacy.

Anonymity is achieved by not identifying (authenticating)

oneself at all, not by identifying oneself using a
pseudonym.

It is true that the terms are not equivalent, even though many
folks do use them interchangeably. However, the term pseudonymous
isn't ideal here as it suggests that only RPs don't know the true
identity of the Subject. TACs do provide a form of conditional
anonymity, hence the name.

I have never heard this definition of pseudonymous.  Anonymous implies
that no name is used, whereas pseudonymous implies that a fictitious
name is used. There is no implication that anyone (other than the
person using the pseudonym) knows the true identity of the person using
the pseudonym.

- The protocol should allow for the
possibility of rekey.  In
many

cases, users will want to use the same pseudonym for an

extended period of time.  For example, many people use
a

pseudonym when posting to message boards or when selling
items

on-line (e.g., on eBay).  People who earn good reputations
as

sellers would not want to have to periodically change

pseudonyms.  A TAC for these users would allow them
perform

strong authentication to prevent others from accessing
their

accounts.  The TAC would allow the sellers to keep their
true

identities a secret while at the same time reassuring
buyers

that sellers' true identities could be determined in case a

seller committed fraud.  While this type of scenario may
not

have been the original motivation for TAC, is there any
reason

that it should not be supported?

I agree that the ability to retain the
same pseudonym would have advantages in the contexts you cite above,
but we dropped support for rekey as it added complexity (as noted by
Jim) that we didn't want to address at this stage.

If the requirement to use a threshold signature scheme were
removed, then the AI could accept and process standard certificate
management request messages (including rekey requests) and so support
for rekey would not add any additional complexity.  It is only the use
of the threshold signature scheme that makes support for standard
certificate management operations complex, and as noted above, I still
do not see how the threshold signature scheme requirement provides any
real benefit.

--------------000508000602040505000606--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1O9q7s0051173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 02:52:07 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1O9q7bx051172; Tue, 24 Feb 2009 02:52:07 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1O9psRB051156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Feb 2009 02:52:06 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id A045F10041539; Tue, 24 Feb 2009 09:51:53 +0000 (GMT)
X-Virus-Scanned: amavisd-new at newbay.com
Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKdctYSE2-K1; Tue, 24 Feb 2009 09:51:50 +0000 (GMT)
Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id A70CD1003EB59; Tue, 24 Feb 2009 09:51:50 +0000 (GMT)
Message-ID: <[email-masked]>
Date: Tue, 24 Feb 2009 09:51:54 +0000
From: Stephen Farrell
User-Agent: Thunderbird 2.0.0.16 (X11/20080707)
MIME-Version: 1.0
To: [email-masked]
CC: [email-masked]
Subject: Re: Long Name Requirements
References: <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

So I reckon if this is a real use-case then we should think
about a change. And while it sounds like it is a real use
case it'd be good to see some example names that are longer
than those allowed by 5280. (And any issued certs that are
in the wild containing those.)

Having said that, I do wonder whether the organisations
actually also have unique shorter names - hard to imagine
people always using such long names - in which case why
not modify the policy to work within the 5280 limits? A
policy change like that is much cheaper than modifying
and deploying new s/w everywhere. If the authors of the
policy are offered the choice between their current
scheme (full long names in subject field) vs. the cost
of doing so (for everyone else), and the lack of benefit
during Internet-scale deployment, and if they are reasonable,
then they may well change the policy. If OTOH, the policy
only covers certs for some particular application then
I don't care too much anyway that they are x.509 but
not 5280 compliant.

E.g. in our case, we like to be called Trinity College
Dublin even though our name in contracts is much longer (*)
and would in fact break the 5280 limit. (A certain
irony there since my affiliation is mentioned in 5280;-)
But I don't see a need for that name to be in any X.509
certs so I don't mind.

Stephen.

(*) In contracts, but essentially nowhere else, TCD is called
"The Provost Fellows and Scholars of the College of the Holy
and Undivided Trinity of Queen Elisabeth Near Dublin" which
is a 5280-unfriendly 113 characters. I guess the short-sighted
folks 400 years ago just didn't plan ahead for x.509:-)

Ersin GÃ¼laÃ§tÄ± wrote:
>
> First, I like to clarify some points. What I am trying is to put a legal
> person's name (i.e Company Title) in the Subject field of the certificate
> (CN=ACME Company ...). The company will be the owner of the certificate.
> Since company names are longer than 64 characters in nature, I have to
> devise a solution for creating standards compatible certificates.
>
> I have reviewed the discussions between the PKIX and ITU on upper bounds. I
> wish and hope that RFC 5280 bis will follow X.509's lead on handling longer
> names. In practice our CA software and verification API had strict
> enforcement of the 64 characters based on RFC 3280, 4 years ago. At that
> time we encountered some root certificates that had longer CN and OU
> components than 64 characters. To make our API compatible with those
> certificates we relaxed our upper bounds limit to 128 characters for the
> decoding of certificates. Our CA software still creates certificates
> according to the 64 characters upper bound limitation. I think it would be
> better to modify our CA software and create certificates with no upper bound
> limits on name structures.
>
> -----Original Message-----
> From: Kemp, David P. [mailto:[email-masked]]
> Sent: Monday, February 23, 2009 8:29 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Long Name Requirements
>
> Ersin,
>
> While X.509 permits unlimited-length strings in the Subject field, it may be
> worth considering usability before making a decision to exercise that
> freedom.
>
>>From a practical perspective, applications may handle long names with
> varying degrees of grace - some may have hard-coded upper bounds based on
> 5280 and will refuse to accept longer strings; others may have user
> interface layouts based on length assumptions and may truncate or wrap for
> display purposes without rejecting the certificate. If you buy or develop
> applications designed to handle long strings, then no problem as long as
> every application that touches your certificates can handle them properly.
>
>>From a theoretical perspective, title (regardless of length) probably
> doesn't belong in the Subject field. The Subject name is an identifier that
> tells "who" the certificate applies to. Other information about the user,
> such as height, weight, date of birth, fax number, or title/role/position
> within the organization can be included in certificates but are not
> semantically identifiers. Contact information can go either way - at the
> office a fax number is probably shared but you have a private voice line
> that uniquely refers to you, while at home the voice line may be shared with
> the wife and kids but the only fax machine is in your home office. If your
> purpose is to issue a "role certificate" to a position without regard to who
> occupies the position, then title is an identifier and does belong in the
> Subject name. But in most cases, title is an attribute of the user, not
> part of the user's name. The X.520 title attribute is most appropriately
> placed in the Subject Directory Attributes extension, with the same
> implementation considerations as above.
>
> As Eric says, defining a new attribute type is not necessary because it
> would be at least as difficult to get applications to support a new type as
> it would be to support the new syntax of the existing attribute.
> Hopefully RFC 5280 bis will follow X.509's lead, making upper bounds minima
> that implementations MUST support, not maxima that implementations MUST NOT
> exceed.
>
> I'm sure someone will point out that there is precedent for putting almost
> anything you want in the Subject name, including certificate policy
> statements and mpeg videos of cats. But don't be persuaded that everything
> that is syntactically valid is necessarily wise.
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Erik Andersen
> Sent: Monday, February 23, 2009 9:57 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Long Name Requirements
>
>
> Hi Ersin,
>
> In the latest edition of X.509, we removed the length restrictions on
> attribute types. The PKIX group did not follow suit, but retained the length
> restriction. A field of 500 characters will not comply with RFC 5280, but it
> will comply with the X.509 itself, and that is what is important.
>
> You can find links to the lasted documents on
> http://www.x500standard.com/index.php?n=Extension.Ed6.
>
> You do not need to define own attribute types.
>
> Erik Andersen
> Andersen's L-Service
> Elsevej 48, DK-3500 Vaerloese
> Denmark
> Mobile: +45 2097 1490
> email: [email-masked]
> www.x500.eu
> www.x500standard.com
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On
> Behalf Of [email-masked]
> Sent: 23. februar 2009 14:42
> To: [email-masked]
> Subject: Long Name Requirements
>
>
> Hi,
>
> I have read through the PKIX mailing list archives to find a method for
> using name components longer than 64 characters in the Subject field of an
> X.509 v3 certificate. Unfortunately I could not find a solution which
> satisfies RFC 5280 (3280) by using standard CN, Title, O or OU components.
>
> Now I plan to use a custom attribute-value pair in the Subject field. Is
> there any widely used OID for really long names in the Subject field? I need
> to put full company titles, up to 500 characters long, in the Subject field.
>
> Regards,
>
> Ersin
>
>
>
>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1O8ZmOE047512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 01:35:48 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1O8ZmC2047509; Tue, 24 Feb 2009 01:35:48 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.kamusm.gov.tr (ns1.kamusm.gov.tr [193.140.71.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1O8ZjYW047493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Feb 2009 01:35:47 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 27125 invoked by uid 89); 24 Feb 2009 08:35:43 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=private; d=kamusm.gov.tr; b=wcyhhofAiScwdzRXnv0L9JTdhzkk+L9xdm75o2xpKEWT9Xm22TOg/k4yRKLZqqf6fjkgDULaGSFgh+4vvCnmtg==;
Received: by simscan 1.3.1 ppid: 27117, pid: 27120, t: 0.0173s scanners: regex: 1.3.1 attach: 1.3.1 clamav: 0.94.2/m:49
Received: from unknown (HELO LENOVO2DE2357D) ([email-masked]) by mail.kamusm.gov.tr with ESMTPA; 24 Feb 2009 08:35:43 -0000
Reply-To:
From: =?iso-8859-9?B?RXJzaW4gR/xsYed0/Q==?=
To:
Subject: RE: Long Name Requirements
Date: Tue, 24 Feb 2009 10:35:46 +0200
Organization: TUBITAK UEKAE
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-9"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
thread-index: AcmVxPmSRdg/2yWETEq5nGDMIFyj9AAAMVgQAAKeFDAAIaBfkA==
In-Reply-To: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

First, I like to clarify some points. What I am trying is to put a legal
person's name (i.e Company Title) in the Subject field of the certificate
(CN=ACME Company ...). The company will be the owner of the certificate.
Since company names are longer than 64 characters in nature, I have to
devise a solution for creating standards compatible certificates.

I have reviewed the discussions between the PKIX and ITU on upper bounds. I
wish and hope that RFC 5280 bis will follow X.509's lead on handling longer
names. In practice our CA software and verification API had strict
enforcement of the 64 characters based on RFC 3280, 4 years ago. At that
time we encountered some root certificates that had longer CN and OU
components than 64 characters. To make our API compatible with those
certificates we relaxed our upper bounds limit to 128 characters for the
decoding of certificates. Our CA software still creates certificates
according to the 64 characters upper bound limitation. I think it would be
better to modify our CA software and create certificates with no upper bound
limits on name structures.

-----Original Message-----
From: Kemp, David P. [mailto:[email-masked]]
Sent: Monday, February 23, 2009 8:29 PM
To: [email-masked]; [email-masked]
Subject: RE: Long Name Requirements

Ersin,

While X.509 permits unlimited-length strings in the Subject field, it may be
worth considering usability before making a decision to exercise that
freedom.

>From a practical perspective, applications may handle long names with
varying degrees of grace - some may have hard-coded upper bounds based on
5280 and will refuse to accept longer strings; others may have user
interface layouts based on length assumptions and may truncate or wrap for
display purposes without rejecting the certificate. If you buy or develop
applications designed to handle long strings, then no problem as long as
every application that touches your certificates can handle them properly.

>From a theoretical perspective, title (regardless of length) probably
doesn't belong in the Subject field. The Subject name is an identifier that
tells "who" the certificate applies to. Other information about the user,
such as height, weight, date of birth, fax number, or title/role/position
within the organization can be included in certificates but are not
semantically identifiers. Contact information can go either way - at the
office a fax number is probably shared but you have a private voice line
that uniquely refers to you, while at home the voice line may be shared with
the wife and kids but the only fax machine is in your home office. If your
purpose is to issue a "role certificate" to a position without regard to who
occupies the position, then title is an identifier and does belong in the
Subject name. But in most cases, title is an attribute of the user, not
part of the user's name. The X.520 title attribute is most appropriately
placed in the Subject Directory Attributes extension, with the same
implementation considerations as above.

As Eric says, defining a new attribute type is not necessary because it
would be at least as difficult to get applications to support a new type as
it would be to support the new syntax of the existing attribute.
Hopefully RFC 5280 bis will follow X.509's lead, making upper bounds minima
that implementations MUST support, not maxima that implementations MUST NOT
exceed.

I'm sure someone will point out that there is precedent for putting almost
anything you want in the Subject name, including certificate policy
statements and mpeg videos of cats. But don't be persuaded that everything
that is syntactically valid is necessarily wise.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Erik Andersen
Sent: Monday, February 23, 2009 9:57 AM
To: [email-masked]; [email-masked]
Subject: RE: Long Name Requirements

Hi Ersin,

In the latest edition of X.509, we removed the length restrictions on
attribute types. The PKIX group did not follow suit, but retained the length
restriction. A field of 500 characters will not comply with RFC 5280, but it
will comply with the X.509 itself, and that is what is important.

You can find links to the lasted documents on
http://www.x500standard.com/index.php?n=Extension.Ed6.

You do not need to define own attribute types.

Erik Andersen
Andersen's L-Service
Elsevej 48, DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
email: [email-masked]
www.x500.eu
www.x500standard.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of [email-masked]
Sent: 23. februar 2009 14:42
To: [email-masked]
Subject: Long Name Requirements

Hi,

I have read through the PKIX mailing list archives to find a method for
using name components longer than 64 characters in the Subject field of an
X.509 v3 certificate. Unfortunately I could not find a solution which
satisfies RFC 5280 (3280) by using standard CN, Title, O or OU components.

Now I plan to use a custom attribute-value pair in the Subject field. Is
there any widely used OID for really long names in the Subject field? I need
to put full company titles, up to 500 characters long, in the Subject field.

Regards,

Ersin

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1O7DCxY044082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 00:13:12 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1O7DCZt044081; Tue, 24 Feb 2009 00:13:12 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1O7CwHU044066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Feb 2009 00:13:10 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 68775 invoked from network); 24 Feb 2009 07:13:00 -0000
Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 24 Feb 2009 07:13:00 -0000
Received: (qmail 96822 invoked from network); 24 Feb 2009 07:12:58 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 24 Feb 2009 07:12:57 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Tue, 24 Feb 2009 08:12:54 +0100
Subject: Re: Long Name Requirements
From: Stefan Santesson
To: Nelson B Bolyard ,
CC:
Message-ID:
Thread-Topic: Long Name Requirements
Thread-Index: AcmWT0+reA1Bqk8c4U+qB1X3VPbCcQ==
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Feel free to enlighten me/us.

This is of course significant even though less of an issue if its limited to
creation of certificates. I was more thinking of decoding and validation of
certificates.

/Stefan

On 2/24/09 6:41 AM, "Nelson B Bolyard" wrote:

>
> Stefan Santesson wrote, On 2009-02-23 14:36:
>> While RFC 5280 has retained upper bounds for backwards compatibility I would
>> not expect products on the market to enforce them.
>
> I can name products that do enforce it, when encoding a DER DN from some
> (any) other form.
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1O5g5Od040175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 22:42:05 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1O5g5Op040174; Mon, 23 Feb 2009 22:42:05 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n1O5frxA040160 for ; Mon, 23 Feb 2009 22:42:03 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 7862 invoked from network); 24 Feb 2009 05:41:53 -0000
Received: from unknown (64.202.165.33) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 24 Feb 2009 05:41:53 -0000
Message-ID: <[email-masked]>
Date: Mon, 23 Feb 2009 21:41:45 -0800
From: Nelson B Bolyard
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: [email-masked]
CC: [email-masked]
Subject: Re: Long Name Requirements
References:
In-Reply-To:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Stefan Santesson wrote, On 2009-02-23 14:36:
> While RFC 5280 has retained upper bounds for backwards compatibility I would
> not expect products on the market to enforce them.

I can name products that do enforce it, when encoding a DER DN from some
(any) other form.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NManCj020722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 15:36:49 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NManqC020721; Mon, 23 Feb 2009 15:36:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NMaa3r020705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Feb 2009 15:36:48 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 90722 invoked from network); 23 Feb 2009 22:36:43 -0000
Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 23 Feb 2009 22:36:43 -0000
Received: (qmail 49052 invoked from network); 23 Feb 2009 22:36:33 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Feb 2009 22:36:33 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Mon, 23 Feb 2009 23:36:32 +0100
Subject: Re: Long Name Requirements
From: Stefan Santesson
To: "Kemp, David P." , ,
Message-ID:
Thread-Topic: Long Name Requirements
Thread-Index: AcmVxPmSRdg/2yWETEq5nGDMIFyj9AAAMVgQAAKeFDAADb1sZQ==
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

While RFC 5280 has retained upper bounds for backwards compatibility I would
not expect products on the market to enforce them. Microsoft for one does
not.

If you are applying this in a controlled environment, you could simply test
with the OS versions and applications that are being used to see if there is
any problem.

However, eventhough your description is brief, it strikes me whether it
would be more suitable to define a subjectAltName for your "long" name form
instead of throwing it into a subject attribute. It appears to me as you are
building a unique alternative identifier through this long string rather
than an attribute of a relative distinguished name structure.

/stefan

On 2/23/09 7:28 PM, "Kemp, David P." wrote:

>
> Ersin,
>
> While X.509 permits unlimited-length strings in the Subject field, it
> may be worth considering usability before making a decision to exercise
> that freedom.
>
> From a practical perspective, applications may handle long names with
> varying degrees of grace - some may have hard-coded upper bounds based
> on 5280 and will refuse to accept longer strings; others may have user
> interface layouts based on length assumptions and may truncate or wrap
> for display purposes without rejecting the certificate. If you buy or
> develop applications designed to handle long strings, then no problem as
> long as every application that touches your certificates can handle them
> properly.
>
> From a theoretical perspective, title (regardless of length) probably
> doesn't belong in the Subject field. The Subject name is an identifier
> that tells "who" the certificate applies to. Other information about
> the user, such as height, weight, date of birth, fax number, or
> title/role/position within the organization can be included in
> certificates but are not semantically identifiers. Contact information
> can go either way - at the office a fax number is probably shared but
> you have a private voice line that uniquely refers to you, while at home
> the voice line may be shared with the wife and kids but the only fax
> machine is in your home office. If your purpose is to issue a "role
> certificate" to a position without regard to who occupies the position,
> then title is an identifier and does belong in the Subject name. But in
> most cases, title is an attribute of the user, not part of the user's
> name. The X.520 title attribute is most appropriately placed in the
> Subject Directory Attributes extension, with the same implementation
> considerations as above.
>
> As Eric says, defining a new attribute type is not necessary because it
> would be at least as difficult to get applications to support a new type
> as it would be to support the new syntax of the existing attribute.
> Hopefully RFC 5280 bis will follow X.509's lead, making upper bounds
> minima that implementations MUST support, not maxima that
> implementations MUST NOT exceed.
>
> I'm sure someone will point out that there is precedent for putting
> almost anything you want in the Subject name, including certificate
> policy statements and mpeg videos of cats. But don't be persuaded that
> everything that is syntactically valid is necessarily wise.
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Erik Andersen
> Sent: Monday, February 23, 2009 9:57 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Long Name Requirements
>
>
> Hi Ersin,
>
> In the latest edition of X.509, we removed the length restrictions on
> attribute types. The PKIX group did not follow suit, but retained the
> length
> restriction. A field of 500 characters will not comply with RFC 5280,
> but it
> will comply with the X.509 itself, and that is what is important.
>
> You can find links to the lasted documents on
> http://www.x500standard.com/index.php?n=Extension.Ed6.
>
> You do not need to define own attribute types.
>
> Erik Andersen
> Andersen's L-Service
> Elsevej 48, DK-3500 Vaerloese
> Denmark
> Mobile: +45 2097 1490
> email: [email-masked]
> www.x500.eu
> www.x500standard.com
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On
> Behalf Of [email-masked]
> Sent: 23. februar 2009 14:42
> To: [email-masked]
> Subject: Long Name Requirements
>
>
> Hi,
>
> I have read through the PKIX mailing list archives to find a method for
> using name components longer than 64 characters in the Subject field of
> an
> X.509 v3 certificate. Unfortunately I could not find a solution which
> satisfies RFC 5280 (3280) by using standard CN, Title, O or OU
> components.
>
> Now I plan to use a custom attribute-value pair in the Subject field. Is
> there any widely used OID for really long names in the Subject field? I
> need to put full company titles, up to 500 characters long, in the
> Subject
> field.
>
> Regards,
>
> Ersin
>
>
>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NITqcP006252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 11:29:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NITqw8006251; Mon, 23 Feb 2009 11:29:52 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NITgLc006240 for ; Mon, 23 Feb 2009 11:29:52 -0700 (MST) (envelope-from [email-masked])
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Long Name Requirements
Date: Mon, 23 Feb 2009 13:28:43 -0500
Message-ID: <[email-masked]>
In-Reply-To: <225D7BAE722B45BD82D788A9D52A58C0@ERA1>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Long Name Requirements
Thread-Index: AcmVxPmSRdg/2yWETEq5nGDMIFyj9AAAMVgQAAKeFDA=
References: <[email-masked]> <225D7BAE722B45BD82D788A9D52A58C0@ERA1>
From: "Kemp, David P."
To: ,
X-OriginalArrivalTime: 23 Feb 2009 18:25:15.0937 (UTC) FILETIME=[12ECF110:01C995E4]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Ersin,

While X.509 permits unlimited-length strings in the Subject field, it
may be worth considering usability before making a decision to exercise
that freedom.

>From a practical perspective, applications may handle long names with
varying degrees of grace - some may have hard-coded upper bounds based
on 5280 and will refuse to accept longer strings; others may have user
interface layouts based on length assumptions and may truncate or wrap
for display purposes without rejecting the certificate. If you buy or
develop applications designed to handle long strings, then no problem as
long as every application that touches your certificates can handle them
properly.

>From a theoretical perspective, title (regardless of length) probably
doesn't belong in the Subject field. The Subject name is an identifier
that tells "who" the certificate applies to. Other information about
the user, such as height, weight, date of birth, fax number, or
title/role/position within the organization can be included in
certificates but are not semantically identifiers. Contact information
can go either way - at the office a fax number is probably shared but
you have a private voice line that uniquely refers to you, while at home
the voice line may be shared with the wife and kids but the only fax
machine is in your home office. If your purpose is to issue a "role
certificate" to a position without regard to who occupies the position,
then title is an identifier and does belong in the Subject name. But in
most cases, title is an attribute of the user, not part of the user's
name. The X.520 title attribute is most appropriately placed in the
Subject Directory Attributes extension, with the same implementation
considerations as above. =20

As Eric says, defining a new attribute type is not necessary because it
would be at least as difficult to get applications to support a new type
as it would be to support the new syntax of the existing attribute.
Hopefully RFC 5280 bis will follow X.509's lead, making upper bounds
minima that implementations MUST support, not maxima that
implementations MUST NOT exceed.

I'm sure someone will point out that there is precedent for putting
almost anything you want in the Subject name, including certificate
policy statements and mpeg videos of cats. But don't be persuaded that
everything that is syntactically valid is necessarily wise.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Erik Andersen
Sent: Monday, February 23, 2009 9:57 AM
To: [email-masked]; [email-masked]
Subject: RE: Long Name Requirements

Hi Ersin,

In the latest edition of X.509, we removed the length restrictions on
attribute types. The PKIX group did not follow suit, but retained the
length
restriction. A field of 500 characters will not comply with RFC 5280,
but it
will comply with the X.509 itself, and that is what is important.

You can find links to the lasted documents on
http://www.x500standard.com/index.php?n=3DExtension.Ed6.

You do not need to define own attribute types.

Erik Andersen
Andersen's L-Service
Elsevej 48, DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
email: [email-masked]
www.x500.eu
www.x500standard.com
=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On
Behalf Of [email-masked]
Sent: 23. februar 2009 14:42
To: [email-masked]
Subject: Long Name Requirements

Hi,

I have read through the PKIX mailing list archives to find a method for
using name components longer than 64 characters in the Subject field of
an
X.509 v3 certificate. Unfortunately I could not find a solution which
satisfies RFC 5280 (3280) by using standard CN, Title, O or OU
components.

Now I plan to use a custom attribute-value pair in the Subject field. Is
there any widely used OID for really long names in the Subject field? I
need to put full company titles, up to 500 characters long, in the
Subject
field.

Regards,

Ersin

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NHOAOJ002440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 10:24:10 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NHOAvs002439; Mon, 23 Feb 2009 10:24:10 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NHO8vS002428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Feb 2009 10:24:09 -0700 (MST) (envelope-from [email-masked])
Received: from ERA1 ([78.156.215.7]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id ETV01106; Mon, 23 Feb 2009 18:24:06 +0100
From: "Erik Andersen"
To: "'Paul Hoffman'" , ,
Subject: RE: Long Name Requirements
Date: Mon, 23 Feb 2009 18:24:10 +0100
Message-ID: <3F088A8D12E949028B7328B4F393768F@ERA1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
Thread-Index: AcmV1s6wTtNylMDuSGiE9XfELXTKbgABIhhQ
In-Reply-To:
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Importance: Normal
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

I was not trying to rate standards, just to express that even a field is
longer than 64 characters, it still complies.

Erik Andersen
Andersen's L-Service
Elsevej 48, DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
email: [email-masked]
www.x500.eu
www.x500standard.com

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]]
Sent: 23. februar 2009 17:50
To: Erik Andersen; [email-masked]; [email-masked]
Subject: RE: Long Name Requirements

At 3:56 PM +0100 2/23/09, Erik Andersen wrote:
>In the latest edition of X.509, we removed the length restrictions on
>attribute types. The PKIX group did not follow suit, but retained the
length
>restriction. A field of 500 characters will not comply with RFC 5280, but
it
>will comply with the X.509 itself, and that is what is important.

Different people might have differing opinions about which standard is
"important".

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NGoK4S099974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 09:50:20 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NGoKv0099973; Mon, 23 Feb 2009 09:50:20 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NGoCwp099962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 09:50:13 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <225D7BAE722B45BD82D788A9D52A58C0@ERA1>
References: <225D7BAE722B45BD82D788A9D52A58C0@ERA1>
Date: Mon, 23 Feb 2009 08:50:11 -0800
To: "Erik Andersen" , ,
From: Paul Hoffman
Subject: RE: Long Name Requirements
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 3:56 PM +0100 2/23/09, Erik Andersen wrote:
>In the latest edition of X.509, we removed the length restrictions on
>attribute types. The PKIX group did not follow suit, but retained the length
>restriction. A field of 500 characters will not comply with RFC 5280, but it
>will comply with the X.509 itself, and that is what is important.

Different people might have differing opinions about which standard is "important".

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NFIfHn095380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 08:18:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NFIfsb095379; Mon, 23 Feb 2009 08:18:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n1NFIU4m095367 for ; Mon, 23 Feb 2009 08:18:40 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 1865 invoked by uid 0); 23 Feb 2009 15:18:27 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.144.212) by woodstock.binhost.com with SMTP; 23 Feb 2009 15:18:27 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 23 Feb 2009 10:06:30 -0500
To: [email-masked], [email-masked]
From: Russ Housley
Subject: Re: Long Name Requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Characters or octets?

At 08:41 AM 2/23/2009, [email-masked] wrote:

>Hi,
>
>I have read through the PKIX mailing list archives to find a method for
>using name components longer than 64 characters in the Subject field of an
>X.509 v3 certificate. Unfortunately I could not find a solution which
>satisfies RFC 5280 (3280) by using standard CN, Title, O or OU components.
>
>Now I plan to use a custom attribute-value pair in the Subject field. Is
>there any widely used OID for really long names in the Subject field? I
>need to put full company titles, up to 500 characters long, in the Subject
>field.
>
>Regards,
>
>Ersin

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NEuvLM093785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 07:56:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NEuv9o093784; Mon, 23 Feb 2009 07:56:57 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NEujdo093768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Feb 2009 07:56:56 -0700 (MST) (envelope-from [email-masked])
Received: from ERA1 ([78.156.215.7]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id EQB51743; Mon, 23 Feb 2009 15:56:43 +0100
From: "Erik Andersen"
To: ,
Subject: RE: Long Name Requirements
Date: Mon, 23 Feb 2009 15:56:48 +0100
Message-ID: <225D7BAE722B45BD82D788A9D52A58C0@ERA1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6838
Thread-Index: AcmVxPmSRdg/2yWETEq5nGDMIFyj9AAAMVgQ
In-Reply-To: <[email-masked]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Importance: Normal
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi Ersin,

In the latest edition of X.509, we removed the length restrictions on
attribute types. The PKIX group did not follow suit, but retained the =
length
restriction. A field of 500 characters will not comply with RFC 5280, =
but it
will comply with the X.509 itself, and that is what is important.

You can find links to the lasted documents on
http://www.x500standard.com/index.php?n=3DExtension.Ed6.

You do not need to define own attribute types.

Erik Andersen
Andersen's L-Service
Elsevej 48, DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
email: [email-masked]
www.x500.eu
www.x500standard.com
=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of [email-masked]
Sent: 23. februar 2009 14:42
To: [email-masked]
Subject: Long Name Requirements

Hi,

I have read through the PKIX mailing list archives to find a method for
using name components longer than 64 characters in the Subject field of =
an
X.509 v3 certificate. Unfortunately I could not find a solution which
satisfies RFC 5280 (3280) by using standard CN, Title, O or OU =
components.

Now I plan to use a custom attribute-value pair in the Subject field. Is
there any widely used OID for really long names in the Subject field? I
need to put full company titles, up to 500 characters long, in the =
Subject
field.

Regards,

Ersin

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NDhPdg089560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 06:43:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NDhPcj089559; Mon, 23 Feb 2009 06:43:25 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from postaci.uekae.tubitak.gov.tr (postaci.uekae.tubitak.gov.tr [193.140.74.8]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NDhDQe089547 for ; Mon, 23 Feb 2009 06:43:24 -0700 (MST) (envelope-from [email-masked])
Received: from webmail.uekae.tubitak.gov.tr (hitit.uekae.tubitak.gov.tr [192.168.5.6]) by postaci.uekae.tubitak.gov.tr (UEKAE_MAIL_SERVER_V4) with ESMTP id 0F4CA2258026 for ; Mon, 23 Feb 2009 15:43:09 +0200 (EET)
Received: from 193.140.71.1 (SquirrelMail authenticated user egulacti) by webmail.uekae.tubitak.gov.tr with HTTP; Mon, 23 Feb 2009 15:41:53 +0200 (EET)
Date: Mon, 23 Feb 2009 15:41:53 +0200 (EET)
Subject: Long Name Requirements
From: [email-masked]
To: [email-masked]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-9
X-Priority: 3 (Normal)
Importance: Normal
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hi,

I have read through the PKIX mailing list archives to find a method for
using name components longer than 64 characters in the Subject field of a=
n
X.509 v3 certificate. Unfortunately I could not find a solution which
satisfies RFC 5280 (3280) by using standard CN, Title, O or OU components=
.

Now I plan to use a custom attribute-value pair in the Subject field. Is
there any widely used OID for really long names in the Subject field? I
need to put full company titles, up to 500 characters long, in the Subjec=
t
field.

Regards,

Ersin

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1L0FHTU031017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Feb 2009 17:15:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1L0FHcd031016; Fri, 20 Feb 2009 17:15:17 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1L0FHat031010 for ; Fri, 20 Feb 2009 17:15:17 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id CD3FB3A6B54; Fri, 20 Feb 2009 16:15:01 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-3281update-04.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Fri, 20 Feb 2009 16:15:01 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--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 : An Internet Attribute Certificate Profile for Authorization
Author(s) : R. Housley, S. Farrell, S. Turner
Filename : draft-ietf-pkix-3281update-04.txt
Pages : 47
Date : 2009-2-20

This specification defines a profile for the use of X.509 Attribute
Certificates in Internet Protocols. Attribute certificates may be
used in a wide range of applications and environments covering a
broad spectrum of interoperability goals and a broader spectrum of
operational and assurance requirements. The goal of this document is
to establish a common baseline for generic applications requiring
broad interoperability as well as limited special purpose
requirements. The profile places emphasis on attribute certificate
support for Internet electronic mail, IPSec, and WWW security
applications. This document obsoletes RFC 3281.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
name="draft-ietf-pkix-3281update-04.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

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

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1JFMN6Y024550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2009 08:22:23 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1JFMNbh024549; Thu, 19 Feb 2009 08:22:23 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1JFMCBF024524 for ; Thu, 19 Feb 2009 08:22:22 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.16.3.109]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LaAj3-00022j-Ep for [email-masked]; Thu, 19 Feb 2009 10:22:11 -0500
Mime-Version: 1.0
Message-Id:
Date: Wed, 18 Feb 2009 16:27:56 -0500
To: [email-masked]
From: Stephen Kent
Subject: TAC I-D comments and responses
Content-Type: multipart/alternative; boundary="============_-977065565==_ma============"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

Dave,

Thanks for your careful review of the TAC I-D. Here are responses to
your comments,

Section 1 (Introduction

- The final paragraph begins:

The conditional traceability offered by this model assumes
strong separation between the RA and CA roles, and employs
technical means (threshold cryptography and "blinded"
signatures), to enforce that separation.

The threshold cryptography and "blinded" signatures do not
enforce separation, as they actually require the RA and CA roles
to work more closely together than if these techniques were not
used. The use of the Token provides a technical means to
*permit* the separation of the RA and CA roles, but does not
enforce it. The TAC protocol cannot prevent the RA and CA from
sharing identity information (either by exchanging the
information in non-TAC messages or by the RA encoding the user's
identity in the UserKey of the Token. A more appropriate
statement would be:

The conditional traceability offered by this model assumes
strong separation between the RA and CA roles, and employs
technical means to facilitate that separation.

You are absolutely right! The use of these crypto mechanisms
facilitates separation, but does not enforce it. We will make your
recommended change.

Section 3 (Requirements):

- This section begins by stating that the "document describes a
new separation-of-authority model". How does the model in this
document differ from the one in [13], "An Architecture for
Pseudonymous e-Commerce"? What properties does the protocol
in this document have that the protocol in [13] does not?

In the architecture for Pseudonymous e-Commerce, a CA can link the
pseudonym in the subject field to the real identity unilaterally,
which can lead to a potential 'big brother problem'. In order to
address this issue, this document proposes the separation of
authority concepts (two CAs to issue TAC, which tries to prevent one
CA from linking pseudonym to real identity unilaterally).

- The document explains the need to be able to learn the true
identity of the holder of a TAC, but not the need to learn
a user's pseudonym given the user's true identity, yet this
section states that the solution must enable determining the
TAC from the true identity? Why is this a requirement? What
protocol messages support this capability?

Mapping from a true identity to a pseudonym is a holdover from an
early version of the document and can be removed as a requirement.

Section 5 (Issuing a TAC):

- The protocol involves a complicated scheme involving split
signatures and blind signatures. The use of split signatures
complicates the issuance of both certificates and CRLs, yet
the need for this scheme is not clear. It was previously
argued that the split signature scheme prevents the CA from
issuing a certificate to a user by itself, which could
result in a non-traceable certificate. However, the CA
could still create a non-traceable certificate by simply
not maintaining the link between the TAC and the Token.
An untrustworthy CA could even use a Token issued by the BI
to one user as the basis for issuing a certificate to a
different user. Similarly, a BI could issue a Token to a
user without first identifying that user. Since both the AI
and BI need to cooperate to identify the user associated with
a TAC, there is no benefit in trying to prevent the AI from
issuing a non-traceable certificate, as there is no way to
force the AI (or BI) from cooperating in the tracing of a
certificate if the AI (or BI) simply chooses not the store
the information required to perform the trace.

It's fair to say that use of the mechanisms mandated by the protocol
is not a technical guarantee of the split between the RA and CA
functions, e.g., for the reasons you note. However, use of these
mechanisms probably makes it easier to conduct an audit that verifies
the desired separation of duties. One could define a TAC system that
did not specify these mechanistic details. However, verifying that
such a system provides the desired separation would be more
difficult, on a case-by-case basis. Since you work at NIST, I think a
reasonable analogy here is with some of the specs used for FIPS 140-n
compliance. For example, there is a spec for a PRNG because it makes
it easy for a lab to evaluate a product claiming compliance with 140,
not because that PRNG is the only good way to generate random values
for use in crypto algorithms.

- The document says that "The reader is referred to [17] and [18]
where procedures for implementing RSA and DSA threshold
signatures are described, respectively." I am assuming that this
text intended to refer to [16], "Two-Party Generation of DSA
Signature", for DSA rather than [18]. However, [16] specifies
protocols that require either 4 or 8 messages, but the protocol
in this paper only allows for a single round trip between the AI
and BI when performing the split signing operation. This seems
to suggest that the current protocol cannot support split
signing using DSA.

DSA-based approaches works but require some changes to the protocols
between AI and BI. We'll make a future version of the TAC spec
incorporate the necessary changes,but stick with just RSA for now.

- Section 5 says that "Blinding is also defined for signature
algorithms like DSA, but the explanation is more complex, since
DSA does not natively encrypt data." Can a reference be
provided? I can only find references to papers that propose
blinding schemes for variants of DSA.

You can refer to the blind DSA signature based on MacKenzie and
Reiter, http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf.

- Section 5.1, Step 1 states "The signature on a Token is
generated by the BI using a private key employed only for
this purpose." Step 2 states "The signature (SignatureValue
of SignerInfo) is generated using the BI's private signature
key, corresponding to the public key present in the BI's
certificate. (Note that this certificate is just a certificate
suitable for use with TLS, and is NOT the split-key certificate
used to verify a TAC.)" May the BI use the same private key
and certificate to sign Tokens and for TLS authentication? If
not (as stated in Step 1), then why is it necessary for the
certificate corresponding to the Token signing key to be
"suitable for use with TLS"? Many other places in the document
state that certificates used to verify signatures on CMS
messages should be "suitable for use with TLS".

There are several questions here:

- We recommend use of different keys for TLS authentication and for
Token signing, as you noted above. Our advice is conservative,
following the principle that one should use distinct keys for
distinct purposes. Key generation is not so expensive as to warrant
reuse of keys for these two purposes.

- we use the phrase "suitable for use with TLS" to distinguish the
certificates used for CMS message verification as distinct from the
split-key certificates, as a shorthand. If you have a preferred
wording for EE certificates being used in these cases, I think we
would be happy to use that wording instead.

- Section 5.1, Step 2 (and Appendix A) states
"Token ::= SignedData". However, according to Appendix C,
a Token is a CMS message. That is, a Token is a ContentInfo
with a contentType of id-signedData and a content that holds
a SignedData. Writing "Token ::= SignedData" suggests that
there is no ContentInfo wrapper. In order to avoid confusion,
the Token should always include the ContentInfo wrapper.

Good point, We will make the suggested change to show the ContentInfo wrapper.

- Section 5.1, Step 4: Why does the AI need to sign the
Token and BlindedCertificateHash when they are being sent to
the BI over a two-way authenticated secure channel? Even
if CMS is used, that doesn't mean that the content has to be
signed. The CMS message sent by the AI to the BI could
simply be:

ContentInfo ::= SEQUENCE {
contentType ContentType, -- id-data
content [0] EXPLICIT ANY DEFINED BY contentType }
-- the content is the DER encoded SEQUENCE
-- of the Token and BlindedCertificateHash

When we elected to use CMS we assumed that we had to use one of the
secured message types (signed, enveloped, encrypted digested, etc.).
But, you're right that we could define a new OID and have a very
simple payload. The downside is that existing code probably would not
be able to parse this top-level contentType, but we will consider
this proposed simplification.

- Section 5.1, Step 5: Same as Step 4? Why does the response
need to be signed?

See the reply above.

- Section 5.1, Step 6 states:
The AI then "un-blinds" the blindHashValue, using the other
key from the key pair employed Step 4. This reveals the
partially-signed certificate hash. The AI then applies its
part of the split private key to complete the signature of
the certificate for the user.

Has it been verified that this will always yield the correct
result? My guess is that it will for RSA, but I would need
to be convinced that for DSA one could perform the unblinding
operation on a partial signature, then complete the signing
operation, and be guaranteed to get the correct result. The
safer alternative would be for the AI to complete the signing
operation and then perform the unblinding operation. (Since
I have not seen the paper, I am not even certain that a DSA
signature on a blinded hash is performed in the exact same way
as a normal DSA signature. If not, then the split-signing
protocol may not work on a blinded hash.)

DSA-based approaches will work but require some changes to the
protocols between AI and BI. In this version of document, we'll make
suggested changes to go just with RSA.

- Section 5.1, Step 6 states:
Note that the user should be prepared to accommodate delays
in the certificate issuance process. For example, a
connection between the user and the AI might fail sometime
after the user submits a certificate request at the end of
Step 3 and before the AI returns the certificate at the end
of Step 6. If this happens, the user should resubmit the
request. The AI and BI retain sufficient state to be able to
match the resubmitted request to the original request, and
respond accordingly.

This seem appropriate, but it is contradicted by the following
text in Section 5.1, Step 4:
Next, the AI compares the received Token against a cache of
recent (i.e., not "timed out"), validated Tokens. If a
duplicate is detected, the certificate request is rejected as
a replay.

The comments in step 4 are design guidance; they don't impose
specific constraints on how long an AI holds onto a Token. We can
revise the step 6 text to note that although the AI and BI maintain
state, they do not do so forever.

In addition, only the AI should be able to "match the
resubmitted request to the original request".

Yes, you're right. We'll revise the text here to say that only AI is
involved in matching the resubmitted request.

- Section 5.2, Step A states that "we propose creating a second
CA, under the TAC CA and have it be the CRL issuer for the EE
certificates issued by the TAC CA." However, the actual
proposal is to create a second (CRL signing only) key for the
CA, not to create a second CA.

Sorry if this is not clear enough. The other CRL is issued using a
private key known to the AI unilaterally. Since the key is distinct,
but we want the CRL Issuer name to be the same, we elected to have a
new CA, represented by a new CA certificate issued under the jointly
managed CA certificate.

- Section 5.2, Step A states that "Each EE TAC certificate MUST
contain a CRLDP that points to the CRL issued by this CA, to
ensure that RPs know to check this CRL vs. the CRL that covers
only the CRL CA." This is not sufficient. If the CRL that is
signed using the CA's split certificate-signing key does not
include an issuingDistributionPoint extension then RPs may
use this CRL to determine the status of any certificates issued
by the CA. So, the self-issued certificate including the CRL
signing key MUST include a CRLDP extension and the corresponding
CRL MUST include an IDP extension to ensure that this CRL will
not be used to verify the status of any other certificates.
Inclusion of a CRLDP in the EE TAC certificates is useful, but
does not ensure that RPs will use the correct CRL.

Thanks for noticing this omission. We'll add the requirement for the
CRL to contain the CRLDP extension to match against the IDP extension.

- Section 5.2, Step A states that "If the AI uses OCSP [14] or
SCVP [15] to convey the revocation status of TACs, an equivalent
procedure is employed." SCVP cannot be used by a CA to convey
status information in the same way that CRLs and OCSP can, and
so it should not be mentioned here.

SCVP responses are more encompassing than OCSP and CRLs, but they
can still provide an RP with an indication of whether a given
certificate has been revoked, or not. So, I'm not sure why you feel
that SCVP ought not be mentioned here.

- Section 5.3.1, Subject begins "If present, ...." The subject
field in CertificationRequestInfo is not OPTIONAL and so must
be present.

Thanks for catching that. We'll fix this.

- Section 5.3.1, Subject continues with "value of this field
[subject] SHOULD be empty". However, section 5.1, Step 3 says
"The Subject field of the certificate contains a pseudonym
generated by the user." There is no suggestion in section 5.1,
Step 3 that the user may leave the subject field empty rather
than including a proposed pseudonym for the subject name. These
two sections should be made consistent.

We will reconcile the text in the two sections.

- Section 5.3.1, Attributes: "This attribute contains
X509v3 Certificate Extensions." Which attribute? Not the
id-kisa-tac attribute mentioned in the previous sentence? Is
inclusion of extension in the PKCS10 optional or are there
certain extensions that must be included?

Whether extensions are required, optional, or permitted is a function
of the CP for the TAC CA. However, We can add a note that, in
general, it is a bad idea to allow users to include extensions in a
cert request because that probably will allow the BI to match the
issued cert to the user.

- Section 5.3.1 says:
This profile applies the following additional constraints to
fields that MAY appear in a CertificationRequest Object:

signatureAlgorithm
This field specifies the signature algorithm.

What does this mean? The signatureAlgorithm is mandatory and
this text does not impose any constraints on the field.

We'll fix the text to reflect the fact that this is a mandatory field.

- Section 5.3.2, Subject: "If present, the value of this
field SHOULD be empty, ...." As with Section 5.3.1, this text
need to be consistent with section 5.1.

We'll fix that text to be consistent.

- Section 5.3.2, Extensions: Is inclusion of extension optional
or are there certain extensions that must be included?

See the reply above for 5.3.1.

General:

- In many places in the document seem to include the wrong
references. For example, Section 5 refers to [18] for
implementing threshold signatures using DSA rather than [16].

We'll review the document and fix the citation errors.

- The protocol messages defined in this document all use the
same basic format: a CMS signed data object. For all of these
messages, the eContentType is specified as id-data and
(presumably) the MIME type is application/pkcs7-mime, perhaps
with the parameter smime-type=signed-data. Each of the
protocol messages should have its own MIME type and/or
eContentType. Otherwise, there is no way for the recipient to
know how to process the data.

We adopted use of CMS to move the data between the AI and BI via our
TLS-protected channel because Jim Schaad noted that we needed to have
some way to carry the data that is already known and accepted by the
application ADs, and CMS satisfies this criteria. Presumably we can
use a new content type, w/o encryption and still keep them happy,
even though this is NOT a content type that is generally supported.

- Referring to the certificates issued using this protocol as
anonymous rather than pseudonymous is confusing. The editors
note in the Introduction that pseudonymous is the correct term,
but still choose to use the misleading term "anonymous". I do
not agree that the terms are commonly used interchangeably, and
believe that the use of the correct term, pseudonymous, would
make the privacy properties of the certificates more clear.
People already understand the idea of using different names
(pseudonyms) in different contexts in order to increase privacy.
Anonymity is achieved by not identifying (authenticating)
oneself at all, not by identifying oneself using a pseudonym.

It is true that the terms are not equivalent, even though many folks
do use them interchangeably. However, the term pseudonymous isn't
ideal here as it suggests that only RPs don't know the true identity
of the Subject. TACs do provide a form of conditional anonymity,
hence the name.

- The protocol should allow for the possibility of rekey. In many
cases, users will want to use the same pseudonym for an
extended period of time. For example, many people use a
pseudonym when posting to message boards or when selling items
on-line (e.g., on eBay). People who earn good reputations as
sellers would not want to have to periodically change
pseudonyms. A TAC for these users would allow them perform
strong authentication to prevent others from accessing their
accounts. The TAC would allow the sellers to keep their true
identities a secret while at the same time reassuring buyers
that sellers' true identities could be determined in case a
seller committed fraud. While this type of scenario may not
have been the original motivation for TAC, is there any reason
that it should not be supported?

I agree that the ability to retain the same pseudonym would have
advantages in the contexts you cite above, but we dropped support for
rekey as it added complexity (as noted by Jim) that we didn't want to
address at this stage.

Let us know if these responses address your comments.

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

TAC I-D comments and responses

Dave,

Thanks for your careful review of the TAC
I-D.  Here are responses to your comments,

Section 1 (Introduction

- The final paragraph begins:

The conditional traceability offered by this
model assumes

strong separation between the RA and CA
roles, and employs

technical means (threshold cryptography and
"blinded"

signatures), to enforce that separation.

The threshold cryptography and "blinded" signatures
do not

enforce separation, as they actually require the RA and CA
roles

to work more closely together than if these techniques were
not

used.  The use of the Token provides a technical means
to

*permit* the separation of the RA and CA roles, but does
not

enforce it.  The TAC protocol cannot prevent the RA and CA
from

sharing identity information (either by exchanging the

information in non-TAC messages or by the RA encoding the
user's

identity in the UserKey of the Token.  A more
appropriate

statement would be:

The conditional traceability offered by this
model assumes

strong separation between the RA and CA
roles, and employs

technical means to facilitate that
separation.

You are absolutely right!  The use of these crypto mechanisms
facilitates separation, but does not enforce it.  We will make
your recommended change.

Section 3 (Requirements):

- This section begins by stating that the "document describes
a

new separation-of-authority model".  How does the
model in this

document differ from the one in
[13], "An Architecture for

Pseudonymous e-Commerce"?  What properties does the
protocol

in this document have that the
protocol in [13] does not?

In the architecture for Pseudonymous
e-Commerce, a CA can link the pseudonym in the subject field to the
real identity unilaterally, which can lead to a potential 'big brother
problem'. In order to address this issue, this document proposes the
separation of authority concepts (two CAs to issue TAC, which tries to
prevent one CA from linking pseudonym to real identity
unilaterally).

- The document explains the need to be able to learn the true

identity of the holder of a TAC, but not the need to learn

a user's pseudonym given the user's true identity, yet this

section states that the solution must enable determining
the

TAC from the true identity?  Why is this a requirement?
What

protocol messages support this
capability?

Mapping from a true identity to a
pseudonym is a holdover from an early version of the document and can
be removed as a requirement.

Section 5 (Issuing a TAC):

- The protocol involves a complicated scheme involving split

signatures and blind signatures.  The use of split
signatures

complicates the issuance of both certificates and CRLs, yet

the need for this scheme is not clear.  It was
previously

argued that the split signature scheme prevents the CA from

issuing a certificate to a user by itself, which could

result in a non-traceable certificate.  However, the
CA

could still create a non-traceable certificate by simply

not maintaining the link between the TAC and the Token.

An untrustworthy CA could even use a Token issued by the BI

to one user as the basis for issuing a certificate to a

different user.  Similarly, a BI could issue a Token to
a

user without first identifying that user.  Since both the
AI

and BI need to cooperate to identify the user associated
with

a TAC, there is no benefit in trying to prevent the AI from

issuing a non-traceable certificate, as there is no way to

force the AI (or BI) from cooperating in the tracing of a

certificate if the AI (or BI) simply chooses not the store

the information required to perform the trace.

It's fair to say that use of the mechanisms mandated by the
protocol is not a technical guarantee of the split between the RA and
CA functions, e.g., for the reasons you note. However, use of these
mechanisms probably makes it easier to conduct an audit that verifies
the desired separation of duties. One could define a TAC system that
did not specify these mechanistic details. However, verifying that
such a system provides the desired separation would be more difficult,
on a case-by-case basis. Since you work at NIST, I think a reasonable
analogy here is with some of the specs used for FIPS 140-n compliance.
For example, there is a spec for a PRNG because it makes it easy for a
lab to evaluate a product claiming compliance with 140, not because
that PRNG is the only good way to generate random values for use in
crypto algorithms.

- The document says that "The reader is referred to [17] and
[18]

where procedures for implementing RSA and DSA threshold

signatures are described, respectively." I am assuming
that this

text intended to refer to [16], "Two-Party Generation of
DSA

Signature", for DSA rather than [18].  However, [16]
specifies

protocols that require either 4 or 8 messages, but the
protocol

in this paper only allows for a single round trip between the
AI

and BI when performing the split signing operation.  This
seems

to suggest that the current protocol cannot support split

signing using DSA.

DSA-based approaches works but require
some changes to the protocols between AI and BI. We'll make a future
version of the TAC spec incorporate the necessary changes,but stick
with just RSA for now.

- Section 5 says that "Blinding is also defined for
signature

algorithms like DSA, but the explanation is more complex,
since

DSA does not natively encrypt data."  Can a reference
be

provided?  I can only find references to papers that
propose

blinding schemes for variants of
DSA.

You can refer to the blind DSA signature
based on MacKenzie and Reiter,
http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf.

- Section 5.1, Step 1 states "The signature on a Token is

generated by the BI using a private key employed only for

this purpose."  Step 2 states "The signature
(SignatureValue

of SignerInfo) is generated using the BI's private
signature

key, corresponding to the public key present in the BI's

certificate. (Note that this certificate is just a
certificate

suitable for use with TLS, and is NOT the split-key
certificate

used to verify a TAC.)"  May the BI use the same
private key

and certificate to sign Tokens and for TLS authentication?
If

not (as stated in Step 1), then why is it necessary for the

certificate corresponding to the Token signing key to be

"suitable for use with TLS"?  Many other places
in the document

state that certificates used to verify signatures on CMS

messages should be "suitable for use with TLS".

There are several questions here:

- We recommend use of different keys for TLS authentication and for
Token signing, as you noted above. Our advice is conservative,
following the principle that one should use distinct keys for distinct
purposes. Key generation is not so expensive as to warrant reuse of
keys for these two purposes.

-  we use the phrase "suitable for use with TLS" to
distinguish the certificates used for CMS message verification as
distinct from the split-key certificates, as a shorthand. If you have
a preferred wording for EE certificates being used in these cases, I
think we would be happy to use that wording instead.

- Section 5.1, Step 2 (and Appendix A) states

"Token ::= SignedData".  However, according to
Appendix C,

a Token is a CMS message.  That is, a Token is a
ContentInfo

with a contentType of id-signedData and a content that
holds

a SignedData.  Writing "Token ::= SignedData"
suggests that

there is no ContentInfo wrapper.  In order to avoid
confusion,

the Token should always include the ContentInfo wrapper.

Good point, We will make the suggested change to show the
ContentInfo wrapper.

- Section 5.1, Step 4: Why does the AI need to sign the

Token and BlindedCertificateHash when they are being sent
to

the BI over a two-way authenticated secure channel?
Even

if CMS is used, that doesn't mean that the content has to
be

signed.  The CMS message sent by the AI to the BI
could

simply be:

ContentInfo ::= SEQUENCE {

contentType
ContentType, -- id-data

content [0]
EXPLICIT ANY DEFINED BY contentType }

-- the content is the DER encoded
SEQUENCE

-- of the Token and
BlindedCertificateHash

When we elected to use CMS we assumed that we had to use one
of the secured message types (signed, enveloped, encrypted digested,
etc.).  But, you're right that we could define a new OID and have
a very simple payload. The downside is that existing code probably
would not be able to parse this top-level contentType, but we will
consider this proposed simplification.

- Section 5.1, Step 5: Same as Step
4?  Why does the response

need to be signed?

See the reply above.

- Section 5.1, Step 6 states:

The AI then "un-blinds" the
blindHashValue, using the other

key from the key pair employed Step 4.
This reveals the

partially-signed certificate hash. The AI
then applies its

part of the split private key to complete the
signature of

the certificate for the user.

Has it been verified that this will always yield the
correct

result?  My guess is that it will for RSA, but I would
need

to be convinced that for DSA one could perform the
unblinding

operation on a partial signature, then complete the signing

operation, and be guaranteed to get the correct result.
The

safer alternative would be for the AI to complete the
signing

operation and then perform the unblinding operation.
(Since

I have not seen the paper, I am not even certain that a DSA

signature on a blinded hash is performed in the exact same
way

as a normal DSA signature.  If not, then the
split-signing

protocol may not work on a blinded hash.)

DSA-based approaches will work but
require some changes to the protocols between AI and BI. In this
version of document, we'll make suggested changes to go just with
RSA.

- Section 5.1, Step 6 states:

Note that the user should be prepared to
accommodate delays

in the certificate issuance process. For
example, a

connection between the user and the AI might
fail sometime

after the user submits a certificate request
at the end of

Step 3 and before the AI returns the
certificate at the end

of Step 6. If this happens, the user should
resubmit the

request. The AI and BI retain sufficient
state to be able to

match the resubmitted request to the original
request, and

respond accordingly.

This seem appropriate, but it is contradicted by the
following

text in Section 5.1, Step 4:

Next, the AI compares the received Token
against a cache of

recent (i.e., not "timed out"),
validated Tokens. If a

duplicate is detected, the certificate
request is rejected as

a replay.

The comments in step 4 are design guidance; they don't impose
specific constraints on how long an AI holds onto a Token.  We
can revise the step 6 text to note that although the AI and BI
maintain state, they do not do so forever.

In addition, only the AI should be able to "match
the

resubmitted request to the original request".

Yes, you're right. We'll revise the text here to say that only AI
is involved in matching the resubmitted request.

- Section 5.2, Step A states that "we propose creating a
second

CA, under the TAC CA and have it be the CRL issuer for the
EE

certificates issued by the TAC CA."  However, the
actual

proposal is to create a second (CRL signing only) key for
the

CA, not to create a second CA.

Sorry if this is not clear enough. The other CRL is issued using a
private key known to the AI unilaterally. Since the key is distinct,
but we want the CRL Issuer name to be the same, we elected to have a
new CA, represented by a new CA certificate issued under the jointly
managed CA certificate.

- Section 5.2, Step A states that "Each EE TAC certificate
MUST

contain a CRLDP that points to the CRL issued by this CA,
to

ensure that RPs know to check this CRL vs. the CRL that
covers

only the CRL CA."  This is not sufficient.  If
the CRL that is

signed using the CA's split certificate-signing key does
not

include an issuingDistributionPoint extension then RPs may

use this CRL to determine the status of any certificates
issued

by the CA.  So, the self-issued certificate including the
CRL

signing key MUST include a CRLDP extension and the
corresponding

CRL MUST include an IDP extension to ensure that this CRL
will

not be used to verify the status of any other certificates.

Inclusion of a CRLDP in the EE TAC certificates is useful,
but

does not ensure that RPs will use the correct CRL.

Thanks for noticing this omission. We'll add the requirement for
the CRL to contain the CRLDP extension to match against the IDP
extension.

- Section 5.2, Step A states that "If the AI uses OCSP [14]
or

SCVP [15] to convey the revocation status of TACs, an
equivalent

procedure is employed."  SCVP cannot be used by a CA
to convey

status information in the same way that CRLs and OCSP can,
and

so it should not be mentioned here.

SCVP responses are more  encompassing than OCSP and CRLs, but
they can still provide an RP with an indication of whether a given
certificate has been revoked, or not. So, I'm not sure why you feel
that SCVP ought not be mentioned here.

- Section 5.3.1, Subject begins "If present, ...."
The subject

field in CertificationRequestInfo is not OPTIONAL and so
must

be present.

Thanks for catching that.  We'll fix this.

- Section 5.3.1, Subject continues with "value of this
field

[subject] SHOULD be empty".  However, section 5.1,
Step 3 says

"The Subject field of the certificate contains a
pseudonym

generated by the user."  There is no suggestion in
section 5.1,

Step 3 that the user may leave the subject field empty
rather

than including a proposed pseudonym for the subject name.
These

two sections should be made consistent.

We will reconcile the text in the two sections.

- Section 5.3.1, Attributes: "This attribute contains

X509v3 Certificate Extensions."  Which attribute?
Not the

id-kisa-tac attribute mentioned in the previous sentence?
Is

inclusion of extension in the PKCS10 optional or are there

certain extensions that must be included?

Whether extensions are required, optional, or permitted is a
function of the CP for the TAC CA. However, We can add a note that, in
general, it is a bad idea to allow users to include extensions in a
cert request because that probably will allow the BI to match the
issued cert to the user.

- Section 5.3.1 says:

This profile applies the following additional
constraints to      fields that MAY appear in
a CertificationRequest Object:

signatureAlgorithm

This field specifies the signature algorithm.

What does this mean?  The signatureAlgorithm is mandatory
and

this text does not impose any constraints on the field.

We'll fix the text to reflect the fact that this is a mandatory
field.

- Section 5.3.2, Subject: "If present, the value of this

field SHOULD be empty, ...."  As with Section 5.3.1,
this text

need to be consistent with section 5.1.

We'll fix that text to be consistent.

- Section 5.3.2, Extensions: Is inclusion of extension
optional

or are there certain extensions that must be
included?

See the reply above for 5.3.1.

General:

- In many places in the document seem to include the wrong

references.  For example, Section 5 refers to [18] for

implementing threshold signatures using DSA rather than
[16].

We'll review the document and fix the citation errors.

- The protocol messages defined in this document all use the

same basic format: a CMS signed data object.  For all of
these

messages, the eContentType is specified as id-data and

(presumably) the MIME type is application/pkcs7-mime,
perhaps

with the parameter smime-type=signed-data.  Each of
the

protocol messages should have its own MIME type and/or

eContentType.  Otherwise, there is no way for the
recipient to

know how to process the
data.

We adopted use of CMS to move the data between the AI and BI
via our TLS-protected channel because Jim Schaad noted that we needed
to have some way to carry the data that is already known and accepted
by the application ADs, and CMS satisfies this criteria. Presumably we
can use a new content type, w/o encryption and still keep them happy,
even though this is NOT a content type that is generally
supported.

- Referring to the certificates
issued using this protocol as

anonymous rather than pseudonymous is confusing.  The
editors

note in the Introduction that pseudonymous is the correct
term,

but still choose to use the misleading term
"anonymous".  I do

not agree that the terms are commonly used interchangeably,
and

believe that the use of the correct term, pseudonymous,
would

make the privacy properties of the certificates more
clear.

People already understand the idea
of using different names

(pseudonyms) in different contexts in order to increase
privacy.

Anonymity is achieved by not identifying (authenticating)

oneself at all, not by identifying oneself using a
pseudonym.

It is true that the terms are not equivalent, even though many
folks do use them interchangeably. However, the term pseudonymous
isn't ideal here as it suggests that only RPs don't know the true
identity of the Subject. TACs do provide a form of conditional
anonymity, hence the name.

- The protocol should allow for the possibility of rekey.  In
many

cases, users will want to use the same pseudonym for an

extended period of time.  For example, many people use
a

pseudonym when posting to message boards or when selling
items

on-line (e.g., on eBay).  People who earn good reputations
as

sellers would not want to have to periodically change

pseudonyms.  A TAC for these users would allow them
perform

strong authentication to prevent others from accessing
their

accounts.  The TAC would allow the sellers to keep their
true

identities a secret while at the same time reassuring
buyers

that sellers' true identities could be determined in case a

seller committed fraud.  While this type of scenario may
not

have been the original motivation for TAC, is there any
reason

that it should not be supported?

I agree that the ability to retain the
same pseudonym would have advantages in the contexts you cite above,
but we dropped support for rekey as it added complexity (as noted by
Jim) that we didn't want to address at this stage.

Let us know if these responses address
your comments.

Steve

--============_-977065565==_ma============--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1GGU5ZW033097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 09:30:05 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GGU5oH033096; Mon, 16 Feb 2009 09:30:05 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n1GGU4rU033090 for ; Mon, 16 Feb 2009 09:30:04 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 25667 invoked from network); 16 Feb 2009 16:30:04 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 16 Feb 2009 16:30:04 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: WGLC results
Date: Mon, 16 Feb 2009 11:30:19 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: WGLC results
Thread-Index: AcmK84rAu89xupwZTCSfwfg910vmWQFXxvlA
References:
From: "Carl Wallace"
To:
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

> 2. New ASN.1: A number of comments here. Most comments=20
> suggested that the new ASN.1 not be adopted in lieu of the=20
> 1988 version, and that it would be nice to have a tutorial to=20
> help folks understand how to map between the two. So, I think=20
> this ca proceed, with the provision that the ASN.1 here is=20
> being specified as a peer, alternative to the 1988 syntax in=20
> the extant specs. Jim & Paul, are you comfortable with this=20
> way forward? Carl, you offered to help write the tutorial.=20
> We'll make it a PKIX work item when you create the first version.

OK. We'll submit the tutorial as a PKIX I-D, hopefully before the -00
deadline.

I have a (late) comment on the ASN.1 draft. In the new module for RFC
5055, the structure for ReplyStatus is now extensible. In RFC 5055 it
was not extensible. I don't think this draft should introduce a change
like this and suggest the extension marker be removed.

>From RFC 5055
ReplyStatus ::=3D ENUMERATED {
success (0),
malformedPKC (1),
malformedAC (2),
unavailableValidationTime (3),
referenceCertHashFail (4),
certPathConstructFail (5),
certPathNotValid (6),
certPathNotValidNow (7),
wantBackUnsatisfied (8) }

>From new ASN.1 I-D
ReplyStatus ::=3D ENUMERATED {
success (0),
malformedPKC (1),
malformedAC (2),
unavailableValidationTime (3),
referenceCertHashFail (4),
certPathConstructFail (5),
certPathNotValid (6),
certPathNotValidNow (7),
wantBackUnsatisfied (8),
...
}

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1FM4WI9087263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Feb 2009 15:04:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1FM4WHe087262; Sun, 15 Feb 2009 15:04:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from argus.ritlabs.com (argus.ritlabs.com [91.198.236.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1FM4KeI087247 for ; Sun, 15 Feb 2009 15:04:31 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (89-28-100-245.starnet.md [89.28.100.245]) (authenticated bits=0) by argus.ritlabs.com (8.14.2/8.14.2) with ESMTP id n1FM4ICS004221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 Feb 2009 00:04:19 +0200
Date: Mon, 16 Feb 2009 00:03:46 +0200
From: "Maxim Masiutin"
MIME-Version: 1.0
Message-ID: <[email-masked]>
Reply-To: "Maxim Masiutin"
Subject: q and j parameters for DH
To: [email-masked]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on argus.ritlabs.com
X-Virus-Status: Clean
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hello,

I'm using Diffie-Hellman implementation from OpenSSL 0.9.8j and it only generates p and g parameters, without setting q and j.

RFC 2459 defines q as a mandatory parameter of DomainParameters.

I would be greatful for the help of how can I update the DH_generate_parameters_ex in crypto\dh\dh_gen.c(or any other suitable place), or if the qualified person will update OpenSSL to fully support q in DomainParameters and I will get the new OpenSSL, or any other advise of how can I implement DomainParameters with OpenSSL.

--
Best regards,
Maxim Masiutin
Ritlabs SRL
http://www.ritlabs.com/

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1F7vLc6060498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Feb 2009 00:57:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1F7vLpt060496; Sun, 15 Feb 2009 00:57:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1F7v98V060484; Sun, 15 Feb 2009 00:57:20 -0700 (MST) (envelope-from [email-masked])
Received: from AndersPC (81.232.45.215) by pne-smtpout2-sn2.hy.skanova.net (7.3.129) id 4873CA9503628EEE; Sun, 15 Feb 2009 08:57:09 +0100
Message-ID:
From: "Anders Rundgren"
To: ,
Subject: Invention Disclosure: Attested Key-Pair Generation with "Key Escrow"
Date: Sun, 15 Feb 2009 08:57:10 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01C98F4B.633581E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6000.20661
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------=_NextPart_000_0098_01C98F4B.633581E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The following public posting is intended to function as a record of an =
invention disclosure where the inventor gives up any IPR claims as well =
as hoping that the described invention is not already filed as a patent =
application.

A PDF version is currently available at:
http://webpki.org/papers/keygen2/keygen2-key-escrow.pdf

Attested Key-Pair Generation with Key "Escrow"

Occasionally credential issuers want (or require) that encryption =
private keys are backuped in order to be able to restore data (AKA "key =
escrow") in case an encryption-key is lost or is replaced.

This document shows how KeyGen2's key-attestation scheme has been =
augmented by an end-to-end-secured escrow mechanism as well. The concept =
is as follows: An issuer sends a key-generation request to a client =
presumably having an SE (Security Element) for keeping user-keys in. The =
SE responds with attested public keys where each attest consists of a =
signature over the generated public key, key-usage, key-exportability, =
and a nonce, using an embedded SE device-key as an attestation signature =
key.

By also including a key-escrow public key (supplied by the issuer during =
the request), in the attest signature hash, the issuer gets a =
cryptographically strong evidence enabling it to detect if something in =
the transport layer or in the SE middleware temporarily swapped the =
escrow-key in order to steal the private key and then changed it back to =
cover-up the operation.

A prerequisite for this to be trustworthy is that the entire operation =
(key-pair generation, private-key escrow-key encryption, and device-key =
attest-signing) is carried out inside of the SE in a fully atomic =
fashion. In addition to successful signature validation, the issuer (of =
course) also has to recognize and trust the SE device type identified by =
the public key certificate received in the response.

For details on the original key-attestation scheme see:
http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf

Note that although the referred document exploits KeyGen2's DIAS (Device =
Internal Attestation Signature) single device-key scheme, the core =
principle is equally applicable to designs relying on separate =
device-keys for attestations, authentications, and encryptions performed =
by an SE.

Request Phase

The following is a slightly simplified version of a KeyGen2 key =
generation request where the issuer asks for two keys; an encryption key =
with escrow and an authentication without escrow (actually KeyGen2 only =
allows escrow for encryption keys).

MIIB2 ... FLlck8SX

Response Phase

Below is a condensed version of the anticipated KeyGen2 response. The =
only thing that differs from a regular KeyGen2 response is the element =
EncryptedPrivateKey which contains a copy of the generated private key =
in PKCS #8 PrivateKeyInfo format, wrapped by a 128-bit random AES key, =
which in turn is wrapped by the issuer-supplied escrow public key. The =
EndorsementKey contains the device public key as well as an enveloped =
signature over the entire response.

AKu4uVZ8 ... 4mjS422CqxwAt
AQAB

Key.1.Private

mWi94IJ ... Xk/HbWM2o=3D

RbDx5WbN ... =
D3GjL7qIhD59s=3D

Key.1.Private

AIOwQTj ... Dfi2WeJLQ2k=3D
AQAB

.
.

The following public posting is =
intended to=20
function as a record of an invention disclosure where the inventor gives =

up any IPR claims as well as hoping that the described invention is =
not=20
already filed as a patent application.

A PDF version is currently =

available at:
http://webpki.org/papers/keygen2/keygen2-key-escrow.pdf

Attested Key-Pair Generation with =
Key=20
"Escrow"

Occasionally credential issuers want (or require) =
that=20
encryption private keys are backuped in order to be able to restore data =
(AKA=20
"key escrow") in case an encryption-key is lost or is =
replaced.

This document shows how KeyGen2's =
key-attestation=20
scheme has been augmented by an end-to-end-secured escrow mechanism =
as=20
well. The concept is as follows: An issuer sends a key-generation =
request to a=20
client presumably having an SE (Security Element) for keeping user-keys =
in. The=20
SE responds with attested public keys where each attest consists of a =
signature=20
over the generated public key, key-usage,=20
key-exportability, and a nonce, using an embedded SE=20
device-key as an attestation signature key.

By also including a=20
key-escrow public key (supplied by the issuer during the request), in =
the attest=20
signature hash, the issuer gets a cryptographically strong evidence =
enabling it=20
to detect if something in the transport layer or in the SE middleware=20
temporarily swapped the escrow-key in order to steal the private key and =
then=20
changed it back to cover-up the operation.

A prerequisite for =
this to be=20
trustworthy is that the entire operation (key-pair generation,=20
private-key escrow-key encryption, and device-key=20
attest-signing) is carried out inside of the SE in a fully =
atomic=20
fashion. In addition to successful signature validation, the issuer =
(of=20
course) also has to recognize and trust the SE device=20
type identified by the public key certificate received in =
the=20
response.

For details on the original key-attestation scheme=20
see:
http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf

Note that although the referred =
document exploits=20
KeyGen2's DIAS (Device Internal Attestation Signature) single device-key =
scheme,=20
the core principle is equally applicable to designs relying on separate=20
device-keys for attestations, authentications, and encryptions performed =
by an=20
SE.

Request Phase

The =
following is a=20
slightly simplified version of a KeyGen2 key generation request where =
the issuer=20
asks for two keys; an encryption key with escrow and an =
authentication=20
without escrow (actually KeyGen2 only allows escrow for encryption=20
keys).

<KeyOperationRequest ...=20
<CreateObject>

=
<KeyPair=20
ID=3D"Key.1" =
KeyUsage=3D"encryption">
<RSA=20
KeySize=3D"2048"/>
=20
<EscrowKey>
=20
<ds:X509Data>
&n=
bsp;=20
<ds:X509Certificate>MIIB2 ...=20
FLlck8SX</ds:X509Certificate>
&nbs=
p; =20
</ds:X509Data>
=20
</EscrowKey>
</KeyPair>

&nb=
sp;  =20
<KeyPair ID=3D"Key.2"=20
KeyUsage=3D"authentication">
=
<RSA=20
KeySize=3D"2048"/>
=
</KeyPair>

=20
</CreateObject>
</KeyOperationRequest>

Response=20
Phase

Below is a condensed version of the anticipated =
KeyGen2=20
response. The only thing that differs from a regular KeyGen2 =
response is=20
the element EncryptedPrivateKey which =
contains a=20
copy of the generated private key in PKCS #8 PrivateKeyInfo format, =
wrapped by a=20
128-bit random AES key, which in turn is wrapped by the issuer-supplied =
escrow=20
public key.  The EndorsementKey =
contains=20
the device public key as well as an enveloped signature over the entire=20
response.

<KeyOperationResponse =
... =20

<GeneratedPublicKey ID=3D"Key.1" =
KeyAttestation=3D"H8USg ...=20
ZixaYVw=3D=3D">
=20
<ds:KeyInfo>
=20
<ds:KeyValue>
=20
<ds:RSAKeyValue>
=
; =20
<ds:Modulus>AKu4uVZ8 ...=20
4mjS422CqxwAt</ds:Modulus>
&=
nbsp;  =20
<ds:Exponent>AQAB</ds:Exponent>
&n=
bsp;  =20
</ds:RSAKeyValue>
=20
</ds:KeyValue>
=20
</ds:KeyInfo>
<EncryptedPrivateKey=20
Format=3D"http://xmlns.webpki.org/keygen2/1.0#format.pkcs8">
=20
<xenc:EncryptedKey>
=20
<xenc:EncryptionMethod Algorithm=3D"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
=20
<ds:KeyInfo>
&nb=
sp;=20
<ds:KeyName>Key.1.Private</ds:KeyName>
&=
nbsp;   =20
</ds:KeyInfo>
=20
<xenc:CipherData>
&nbs=
p;  <xenc:CipherValue>mWi94IJ=20
...=20
Xk/HbWM2o=3D</xenc:CipherValue>
&n=
bsp;  </xenc:CipherData>
=
; </xenc:EncryptedKey>
=
<xenc:EncryptedKey>
=20
<xenc:EncryptionMethod Algorithm=3D"http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
=20
<xenc:CipherData>
&nbs=
p; =20
<xenc:CipherValue>RbDx5WbN ...=20
D3GjL7qIhD59s=3D</xenc:CipherValue>
&nbs=
p;  =20
</xenc:CipherData>
=20
<xenc:CarriedKeyName>Key.1.Private</xenc:CarriedKeyName>
&=
nbsp;    =20
</xenc:EncryptedKey>
</EncryptedPriva=
teKey>
</GeneratedPublicKey>

=20
<GeneratedPublicKey ID=3D"Key.2" KeyAttestation=3D"k6QN ...=20
dUpyTA=3D=3D">
=20
<ds:KeyInfo>
=20
<ds:KeyValue>
=20
<ds:RSAKeyValue>
=
; =20
<ds:Modulus>AIOwQTj ...=20
Dfi2WeJLQ2k=3D</ds:Modulus>
=
=20
<ds:Exponent>AQAB</ds:Exponent>
&n=
bsp;  =20
</ds:RSAKeyValue>
=20
</ds:KeyValue>
</ds:KeyInfo>
&n=
bsp;=20
</GeneratedPublicKey>

<EndorsementKey=20
KeyAttestationAlgorithm=3D"=
http://xmlns.webpki.org/keygen2/1.0#algorithm.key-attestation-1<=
/FONT>">
=20
<ds:Signature>
&=
nbsp;=20
.
=20
.
</ds:Signature>
=20
</EndorsementKey>

</KeyOperationResponse

Anders =
Rundgren

------=_NextPart_000_0098_01C98F4B.633581E0--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1BGXrpY049963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 09:33:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1BGXrkE049962; Wed, 11 Feb 2009 09:33:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1BGXfUU049938 for ; Wed, 11 Feb 2009 09:33:52 -0700 (MST) (envelope-from [email-masked])
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id A29255D; Wed, 11 Feb 2009 17:33:38 +0100 (CET)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2009021117333770:344478 ; Wed, 11 Feb 2009 17:33:37 +0100
Message-ID: <[email-masked]>
Date: Wed, 11 Feb 2009 17:33:38 +0100
From: Peter Sylvester
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: [email-masked]
Cc: owner-ietf-pkix , ietf-pkix
Subject: Re: this document may of interest to PKIX members
References:
In-Reply-To:
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 02/11/2009 05:33:37 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 02/11/2009 05:33:38 PM, Serialize complete at 02/11/2009 05:33:38 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Just taking two specific things (mimetype and filename)
into a fixed structure seem rather restricted ... while
at the same time allowing an extendable choice of validity
assertions.

The author had been asked whether the intended purpose cannot be
achieved using a technique based in RFC 4073
using

ContentWithAttributes ::= SEQUENCE {
content ContentInfo,
attrs SEQUENCE SIZE (1..MAX) OF Attribute }

as a base construct. All what would be needed are a definition
of attributes concerning mimetype, filename and timestamp.
It could be but there was no intent to follow the idea.

RFC 4073's goal is to eliminate MIME encapsulations. One may
argue that it is in fact not 100% successful,
since useful mime headers cannot be easily transformed.
For example a Mime-type or a part of a Content-Description
which may have a filename but also a more useful description
of the data.

I am not sure whether a generic attribute to map a 'Mimeheader'
into some small ASN1 structure is necessary.

SEQUENCE {
header IA5TEXT,
params SEQUENCE OF
param SEQUENCE {key IA5TEXT, value}

(with maybe some constraints about IA5TEXT so that one
can easily map this into
header: p1=v1 ; p2= v2 ...

To Denis: registering a content-type is not necessarily
related to the nature of the document.

Besides that one can ask the question whether a mimetype
would not be an important part of the data to be timestamped,
similar to the content-type which is included as an attribute
in a signed-data.

Peter

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1ANoIQn005360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 16:50:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1ANoIAh005359; Tue, 10 Feb 2009 16:50:18 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.94.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1ANo51j005353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Feb 2009 16:50:17 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 2048 invoked from network); 10 Feb 2009 23:50:14 -0000
Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Feb 2009 23:50:14 -0000
Received: (qmail 79405 invoked from network); 10 Feb 2009 23:50:04 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Feb 2009 23:50:04 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Wed, 11 Feb 2009 00:50:03 +0100
Subject: Affiliation change
From: Stefan Santesson
To: "[email-masked]"
Message-ID:
Thread-Topic: Affiliation change
Thread-Index: AcmL2krAUuFHTWEL/UOqi1Z0DQQf7g==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3317158204_29496292"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

--B_3317158204_29496292
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

As of Thursday this week (February 12) my affiliation will change and I wil=
l
no longer be an employee of Microsoft.
As you may have noticed. I=B9m now sending mail to this list from a new e-mai=
l
address: [email-masked]

If you reply to any of my old mails using my Microsoft address, I will not
receive them. So please try to make sure that any e-mails to me are sent to
my current new address [email-masked]

>From an IETF/PKIX perspective nothing will change. I will continue to serve
as PKIX co-chair as long as the Security ADs are happy with me and I will
remain active in the IETF work.
>From now on I will be present as independent consultant.

/Stefan

--B_3317158204_29496292
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Affiliation change

All,

As of Thursday this week (February 12) my affiliation will change and I wil=
l no longer be an employee of Microsoft.

As you may have noticed. I’m now sending mail to this list from a new=
e-mail address: [email-masked]

If you reply to any of my old mails using my Microsoft address, I will not =
receive them. So please try to make sure that any e-mails to me are sent to =
my current new address [email-masked]

>From an IETF/PKIX perspective nothing will change. I will continue to serve=
as PKIX co-chair as long as the Security ADs are happy with me and I will r=
emain active in the IETF work.

>From now on I will be present as independent consultant.

/Stefan

--B_3317158204_29496292--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1AJdiaP095672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 12:39:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AJdiP4095671; Tue, 10 Feb 2009 12:39:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1AJdWmV095641 for ; Tue, 10 Feb 2009 12:39:43 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[67.52.141.198]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LWySB-00006j-D8; Tue, 10 Feb 2009 14:39:31 -0500
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Tue, 10 Feb 2009 14:39:22 -0500
To: "Santosh Chokhani"
From: Stephen Kent
Subject: RE: Comments on CA clearance constraints
Cc: "Stefan Santesson" , , "Sean Turner"
Content-Type: multipart/alternative; boundary="============_-977827725==_ma============"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

At 9:18 AM -0500 2/10/09, Santosh Chokhani wrote:
>Stefan,
>
>I am ok with your suggestion. Thanks for thinking of it.
>
>Sean and Steve,
>
>Let me know. If you agree, I will update the draft.

yes, please update the draft and publish it.

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

RE: Comments on CA clearance
constraints

At 9:18 AM -0500 2/10/09, Santosh Chokhani wrote:

Stefan,

I am ok with your suggestion.  Thanks for
thinking of it.

Sean and Steve,

Let me know.  If you agree, I will update the
draft.

yes, please update the draft and publish it.

Steve

--============_-977827725==_ma============--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1AHWJHY089950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 10:32:19 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AHWJHI089949; Tue, 10 Feb 2009 10:32:19 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.94.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1AHW6F2089929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Feb 2009 10:32:18 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 31996 invoked from network); 10 Feb 2009 17:32:12 -0000
Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Feb 2009 17:32:12 -0000
Received: (qmail 47364 invoked from network); 10 Feb 2009 17:32:05 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Feb 2009 17:32:05 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Tue, 10 Feb 2009 18:32:04 +0100
Subject: Re: WGLC results
From: Stefan Santesson
To: Paul Hoffman
CC:
Message-ID:
Thread-Topic: WGLC results
Thread-Index: AcmLpX0DsYwQf9qUzEmQTSn1bPVmEQ==
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Paul,

I want to have it noted as part of summarizing the workgroup consensus.
That is, even if I did not send a message during WGLC, note that my problem
with the document is unresolved.

I do not expect the document to change.

/Stefan

On 2/10/09 5:16 PM, "Paul Hoffman" wrote:

> At 8:26 AM +0100 2/10/09, Stefan Santesson wrote:
>> I would like to
>> have noted that there is one issue with this document that I have raised
>> repeatedly that I don't think is settled to my satisfaction.
>
> It seemed like you were the only one raising the issue, and that you did it
> not wearing your co-chair hat. Do you feel that your lone, repeated voice
> should cause the document to change? If so, why?
>
> --Paul Hoffman, Director
> --VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1AGHbuN085352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 09:17:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AGHbD8085351; Tue, 10 Feb 2009 09:17:37 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [172.17.139.184] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1AGGKVt085285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 09:16:21 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Tue, 10 Feb 2009 08:16:15 -0800
To: Stefan Santesson
From: Paul Hoffman
Subject: Re: WGLC results
Cc:
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 8:26 AM +0100 2/10/09, Stefan Santesson wrote:
>I would like to
>have noted that there is one issue with this document that I have raised
>repeatedly that I don't think is settled to my satisfaction.

It seemed like you were the only one raising the issue, and that you did it not wearing your co-chair hat. Do you feel that your lone, repeated voice should cause the document to change? If so, why?

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1AEIvbu077746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 07:18:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AEIvma077745; Tue, 10 Feb 2009 07:18:57 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n1AEIi6G077738 for ; Tue, 10 Feb 2009 07:18:55 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 4522 invoked from network); 10 Feb 2009 14:18:52 -0000
Received: from [email-masked] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;10 Feb 2009 14:18:52 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 10 Feb 2009 14:18:51 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98B8A.7CFA4DD9"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Comments on CA clearance constraints
Date: Tue, 10 Feb 2009 09:18:47 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on CA clearance constraints
Thread-Index: AcmLals4XDm1pJuHn0Wdb1Z5THUPfgAIAhrQ
References:
From: "Santosh Chokhani"
To: "Stefan Santesson" , , "Sean Turner"
Cc: "Stephen Kent"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This is a multi-part message in MIME format.

------_=_NextPart_001_01C98B8A.7CFA4DD9
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan,
=20
I am ok with your suggestion. Thanks for thinking of it.
=20
Sean and Steve,=20
=20
Let me know. If you agree, I will update the draft.

________________________________

From: Stefan Santesson [mailto:[email-masked]]=20
Sent: Tuesday, February 10, 2009 5:29 AM
To: [email-masked]; Sean Turner; Santosh Chokhani
Cc: Stephen Kent
Subject: Comments on CA clearance constraints
=09
=09
=09
1) Nit
=09
Second paragraph of section 1. Introduction says:
=09
Clearance attribute may be placed in the Subject Directory
extension
of a PKC or may be placed in a separate attribute certificate
(AC).
=09
=09
It should say:
=09
Clearance attribute may be placed in the Subject Directory
Attributes=20
extension of a PKC or may be placed in a separate attribute
certificate (AC).
=09
=09
Also, the different occurrences of this extension name use
different capitalizations.
=09
=09
2) Path Processing requirements for TA PKC extensions
=09
Section 4, second para:
Authority Clearance
Constraints certificate extension in the TA and in each PKC
up to but
not including the end PKC in a PKC certification path impact
the
effective-clearance.
=09
Section 4, Para after numbered bullet list:
Assuming a certification path consisting of n PKCs, the
effective-
clearance for the subject of the end PKC is the intersection
of
Clearance attribute in the subject PKC, Authority Clearance
Constraints, if present, in trust anchor and all Authority
Clearance
Constraints present in intermediate PKCs.
=09
These examples clearly defines clearance information in a TA
certificate to be part of the clearance processing. There is no room to
treat this as optional information as is the case for Root extensions in
standard path processing.
Technically this is not in conflict with RFC 5280 simply because
this draft does not define path validation or any changes to it. It just
defines a new type of certificate content and states the rules for
processing it.
=09
However, I'm a bit concerned that this may cause integration
problems with current RFC 5280 compliant path processing engines and the
APIs used to invoke them. Some implementations may strip all information
but the essential variables from the root certificate but more
seriously, some environments use a mix of extension information and
locally configured parameters to determine the initial state variables
for path processing. A solid practice worth preserving in some cases.
=09
The golden principle for PKI is that the relying party
ultimately decides the initial state variables and determines in the end
if the certificate is valid for their intended use.
=09
I do not suggest any material changes but I'm considering if the
following small adjustments would improve the document.
=09

1. Make a clear note that this standard requires processing
of TA information beyond the initial state variables of RFC 5280.=20
2. Add a section/paragraph about initial state variables
and TA information. In this section state that the default input to the
initial state is any CA clearance extension in the TA certificate of the
path but that this may further be restricted by local policy at the
discretion of the relying party.=20
3. Following this paragraph/section, only refer to the TA
initial state variables defined above, and not to specific data in the
TA certificate.
=09

=09
=09
=09
=09
=09
=09
=09
=09
=09

------_=_NextPart_001_01C98B8A.7CFA4DD9
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Comments on CA clearance constraints

Stefan,

I am ok with your suggestion.  Thanks for =
thinking of=20
it.

Sean and Steve,

Let me know.  If you agree, I will update =
the=20
draft.

From: Stefan Santesson=20
[mailto:[email-masked]]
Sent: Tuesday, February 10, =
2009 5:29=20
AM
To: [email-masked]; Sean Turner; Santosh=20
Chokhani
Cc: Stephen Kent
Subject: Comments on CA=20
clearance constraints

1) Nit

Second =
paragraph of=20
section 1. Introduction says:

Clearance attribute may be =
placed in the=20
Subject Directory extension
of a PKC or may be =
placed in=20
a separate attribute certificate (AC).

It=20
should say:

Clearance attribute may be =
placed in the=20
Subject Directory Attributes
extension of a PKC =
or may=20
be placed in a separate attribute
certificate=20
(AC).

Also, the different occurrences of =
this=20
extension name use different capitalizations.

2) Path =

Processing requirements for TA PKC =
extensions

Section 4,=20
second =
para:
Authority =
Clearance
Constraints=20
certificate extension in the TA and in each PKC up to=20
but
not including the end PKC in a PKC =
certification path=20
impact=20
=
the
effective-clearance.

Section 4, Para after numbered bullet=20
list:
Assuming a certification path =
consisting=20
of n PKCs, the effective-
clearance for the =
subject of=20
the end PKC is the intersection of
Clearance =
attribute in=20
the subject PKC, Authority Clearance
Constraints, =
if=20
present, in trust anchor and all Authority=20
Clearance
Constraints present in intermediate=20
PKCs.

These examples clearly defines clearance =

information in a TA certificate to be part of the clearance =
processing. There=20
is no room to treat this as optional information as is the case for =
Root=20
extensions in standard path processing.
Technically this is not in =
conflict=20
with RFC 5280 simply because this draft does not define path =
validation or any=20
changes to it. It just defines a new type of certificate content and =
states=20
the rules for processing it.

However, I’m a bit concerned =
that this may=20
cause integration problems with current RFC 5280 compliant path =
processing=20
engines and the APIs used to invoke them. Some implementations may =
strip all=20
information but the essential variables from the root certificate but =
more=20
seriously, some environments use a mix of extension information and =
locally=20
configured parameters to determine the initial state variables for =
path=20
processing. A solid practice worth preserving in some =
cases.

The golden=20
principle for PKI is that the relying party ultimately decides the =
initial=20
state variables and determines in the end if the certificate is valid =
for=20
their intended use.

I do not suggest any material changes but =
I’m=20
considering if the following small adjustments would improve the=20
document.

Make a clear note that this standard =
requires=20
processing of TA information beyond the initial state variables of =
RFC 5280.=20

Add a section/paragraph about initial =
state=20
variables and TA information. In this section state that the default =
input=20
to the initial state is any CA clearance extension in the TA =
certificate of=20
the path but that this may further be restricted by local policy at =
the=20
discretion of the relying party.

Following this paragraph/section, only =
refer to the=20
TA initial state variables defined above, and not to specific data =
in the TA=20
certificate.

<=
/HTML>

------_=_NextPart_001_01C98B8A.7CFA4DD9--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1AAT3Pv066000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 03:29:03 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AAT3fm065999; Tue, 10 Feb 2009 03:29:03 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.94.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1AASol8065987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Feb 2009 03:29:02 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 73811 invoked from network); 10 Feb 2009 10:28:52 -0000
Received: from s34.loopia.se (HELO s60.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Feb 2009 10:28:52 -0000
Received: (qmail 50433 invoked from network); 10 Feb 2009 10:28:49 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Feb 2009 10:28:49 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Tue, 10 Feb 2009 11:28:47 +0100
Subject: Comments on CA clearance constraints
From: Stefan Santesson
To: "[email-masked]" , Sean Turner , Santosh Chokhani
CC: Stephen Kent
Message-ID:
Thread-Topic: Comments on CA clearance constraints
Thread-Index: AcmLals4XDm1pJuHn0Wdb1Z5THUPfg==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3317110129_26620827"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

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

--B_3317110129_26620827
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

1) Nit

Second paragraph of section 1. Introduction says:

Clearance attribute may be placed in the Subject Directory extension
of a PKC or may be placed in a separate attribute certificate (AC).

It should say:

Clearance attribute may be placed in the Subject Directory Attributes
extension of a PKC or may be placed in a separate attribute
certificate (AC).

Also, the different occurrences of this extension name use different
capitalizations.

2) Path Processing requirements for TA PKC extensions

Section 4, second para:
Authority Clearance
Constraints certificate extension in the TA and in each PKC up to but
not including the end PKC in a PKC certification path impact the
effective-clearance.

Section 4, Para after numbered bullet list:
Assuming a certification path consisting of n PKCs, the effective-
clearance for the subject of the end PKC is the intersection of
Clearance attribute in the subject PKC, Authority Clearance
Constraints, if present, in trust anchor and all Authority Clearance
Constraints present in intermediate PKCs.

These examples clearly defines clearance information in a TA certificate to
be part of the clearance processing. There is no room to treat this as
optional information as is the case for Root extensions in standard path
processing.
Technically this is not in conflict with RFC 5280 simply because this draft
does not define path validation or any changes to it. It just defines a new
type of certificate content and states the rules for processing it.

However, I=B9m a bit concerned that this may cause integration problems with
current RFC 5280 compliant path processing engines and the APIs used to
invoke them. Some implementations may strip all information but the
essential variables from the root certificate but more seriously, some
environments use a mix of extension information and locally configured
parameters to determine the initial state variables for path processing. A
solid practice worth preserving in some cases.

The golden principle for PKI is that the relying party ultimately decides
the initial state variables and determines in the end if the certificate is
valid for their intended use.

I do not suggest any material changes but I=B9m considering if the following
small adjustments would improve the document.
1. Make a clear note that this standard requires processing of TA
information beyond the initial state variables of RFC 5280.
2. Add a section/paragraph about initial state variables and TA information=
.
In this section state that the default input to the initial state is any CA
clearance extension in the TA certificate of the path but that this may
further be restricted by local policy at the discretion of the relying
party.=20
3. Following this paragraph/section, only refer to the TA initial state
variables defined above, and not to specific data in the TA certificate.

--B_3317110129_26620827
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Comments on CA clearance constraints

1) Nit

Second paragraph of section 1. Introduction says:

Clearance attribute may be placed in the Subje=
ct Directory extension

of a PKC or may be placed in a separate attribute certifi=
cate (AC).

It should say:

Clearance attribute may be placed in the Subje=
ct Directory Attributes

extension of a PKC or may be placed in a separate attribu=
te

certificate (AC).

Also, the different occurrences of this extension name use different capita=
lizations.

2) Path Processing requirements for TA PKC extensions

Section 4, second para:

Authority Clearan=
ce

Constraints certificate extension in the TA and in=
each PKC up to but

not including the end PKC in a PKC certification path imp=
act the

effective-clearance.

Section 4, Para after numbered bullet list:

Assuming a certification path consisting of n =
PKCs, the effective-

clearance for the subject of the end PKC is the intersect=
ion of

Clearance attribute in the subject PKC, Authority Clearan=
ce

Constraints, if present, in trust anchor and all A=
uthority Clearance

Constraints present in intermediate PKCs.

These examples clearly defines clearance information in a TA certificate to=
be part of the clearance processing. There is no room to treat this as opti=
onal information as is the case for Root extensions in standard path process=
ing.

Technically this is not in conflict with RFC 5280 simply because this draft=
does not define path validation or any changes to it. It just defines a new=
type of certificate content and states the rules for processing it.

However, I’m a bit concerned that this may cause integration problems=
with current RFC 5280 compliant path processing engines and the APIs used t=
o invoke them. Some implementations may strip all information but the essent=
ial variables from the root certificate but more seriously, some environment=
s use a mix of extension information and locally configured parameters to de=
termine the initial state variables for path processing. A solid practice wo=
rth preserving in some cases.

The golden principle for PKI is that the relying party ultimately decides t=
he initial state variables and determines in the end if the certificate is v=
alid for their intended use.

I do not suggest any material changes but I’m considering if the foll=
owing small adjustments would improve the document.

Make a clear note that this standard requires proces=
sing of TA information beyond the initial state variables of RFC 5280.

Add a section/paragraph about initial state variables an=
d TA information. In this section state that the default input to the initia=
l state is any CA clearance extension in the TA certificate of the path but =
that this may further be restricted by local policy at the discretion of the=
relying party.

Following this paragraph/section, only refer to the TA i=
nitial state variables defined above, and not to specific data in the TA cer=
tificate.

--B_3317110129_26620827--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1A7R44I056010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 00:27:04 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1A7R4tb056009; Tue, 10 Feb 2009 00:27:04 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from s87.loopia.se (s87.loopia.se [194.9.94.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1A7QpKb056000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Feb 2009 00:27:03 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 7523 invoked from network); 10 Feb 2009 07:26:52 -0000
Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Feb 2009 07:26:52 -0000
Received: (qmail 49118 invoked from network); 10 Feb 2009 07:26:50 -0000
Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) ([email-masked]@[90.229.233.249]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Feb 2009 07:26:50 -0000
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Tue, 10 Feb 2009 08:26:48 +0100
Subject: Re: WGLC results
From: Stefan Santesson
To: Stephen Kent ,
Message-ID:
Thread-Topic: WGLC results
Thread-Index: AcmLUO79ES+PTzLAKkW25K9rsXVedw==
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Steve,

On the TA requirements document I'm not sure in what way the WGLC impacts
its status as we are keeping this document in draft form. I would like to
have noted that there is one issue with this document that I have raised
repeatedly that I don't think is settled to my satisfaction.

I would like the scope of the requirements to be clarified. I have no
problems with these requirements, I just don't think they are generally
applicable and the document should be more clear about when they are.

On the CA Clearance Constraints I made a last pass and found some nit and a
comment that I think merits a discussion. I think the result of these
comments will be pure editorial, but I think they could benefit from some
discussion. If they are too late I can provide them as IETF last call
comments instead.

I'll post them in a separate mail.

/Stefan

On 2/9/09 8:59 PM, "Stephen Kent" wrote:

>
> Folks,
>
> The WGLC on 5 documents closed on 2/6, so it's time to assess status.
>
> 1. 3281 Update: Alfred suggested a few changes. I think Sean
> will need to address these in a new version, which can then be sent
> to the IESG.
>
> 2. New ASN.1: A number of comments here. Most comments
> suggested that the new ASN.1 not be adopted in lieu of the 1988
> version, and that it would be nice to have a tutorial to help folks
> understand how to map between the two. So, I think this ca proceed,
> with the provision that the ASN.1 here is being specified as a peer,
> alternative to the 1988 syntax in the extant specs. Jim & Paul, are
> you comfortable with this way forward? Carl, you offered to help
> write the tutorial. We'll make it a PKIX work item when you create
> the first version.
>
> 3. Authority Clearance Constraints: no comments during this
> last call period, so we'll consider this approved.
>
> 4. PRQP: no comments, so I think we're ready to move this to
> Experimental status.
>
> 5. Trust Anchor Management Requirements: I didn't see any
> messages on the requirements document, so I will assume that this doc
> is suitable for use as the basis for requirements for the rest of the
> trust anchor document work.
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n19K0FuW029081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2009 13:00:15 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n19K0F3U029080; Mon, 9 Feb 2009 13:00:15 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n19K04Nw029068 for ; Mon, 9 Feb 2009 13:00:15 -0700 (MST) (envelope-from [email-masked])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[67.52.141.198]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LWcIV-0006Fm-EI for [email-masked]; Mon, 09 Feb 2009 15:00:04 -0500
Mime-Version: 1.0
Message-Id:
Date: Mon, 9 Feb 2009 14:59:57 -0500
To: [email-masked]
From: Stephen Kent
Subject: WGLC results
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Folks,

The WGLC on 5 documents closed on 2/6, so it's time to assess status.

1. 3281 Update: Alfred suggested a few changes. I think Sean
will need to address these in a new version, which can then be sent
to the IESG.

2. New ASN.1: A number of comments here. Most comments
suggested that the new ASN.1 not be adopted in lieu of the 1988
version, and that it would be nice to have a tutorial to help folks
understand how to map between the two. So, I think this ca proceed,
with the provision that the ASN.1 here is being specified as a peer,
alternative to the 1988 syntax in the extant specs. Jim & Paul, are
you comfortable with this way forward? Carl, you offered to help
write the tutorial. We'll make it a PKIX work item when you create
the first version.

3. Authority Clearance Constraints: no comments during this
last call period, so we'll consider this approved.

4. PRQP: no comments, so I think we're ready to move this to
Experimental status.

5. Trust Anchor Management Requirements: I didn't see any
messages on the requirements document, so I will assume that this doc
is suitable for use as the basis for requirements for the rest of the
trust anchor document work.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n16Lj5CV068920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 14:45:05 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n16Lj5c6068919; Fri, 6 Feb 2009 14:45:05 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n16Lj4sv068912 for ; Fri, 6 Feb 2009 14:45:04 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 6FE583A6C0A; Fri, 6 Feb 2009 13:45:01 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc3161bis-01.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Fri, 6 Feb 2009 13:45:01 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

--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 Time-Stamp Protocol (TSP)
Author(s) : D. Pinkas
Filename : draft-ietf-pkix-rfc3161bis-01.txt
Pages : 30
Date : 2009-2-6

This document describes the format of a request sent to a Time
Stamping Unit (TSU) in order to get a time-stamp token and of the
response that is returned. It also establishes several security-
relevant requirements for the operation of a time-stamping service,
with regards to processing requests to generate responses.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
name="draft-ietf-pkix-rfc3161bis-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

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

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13MMF0a041798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 15:22:15 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n13MMFNs041797; Tue, 3 Feb 2009 15:22:15 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from argus.ritlabs.com (argus.ritlabs.com [91.198.236.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13MMDYn041791 for ; Tue, 3 Feb 2009 15:22:14 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (89-28-100-245.starnet.md [89.28.100.245]) (authenticated bits=0) by argus.ritlabs.com (8.14.2/8.14.2) with ESMTP id n13MMDtg014491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 4 Feb 2009 00:22:13 +0200
Date: Wed, 4 Feb 2009 00:21:58 +0200
From: "Maxim Masiutin"
MIME-Version: 1.0
Message-ID: <[email-masked]>
Reply-To: "Maxim Masiutin"
Subject: Need samples of CMS with Ephemeral-Static Diffie-Hellman and Static-Static Diffie-Hellman
To: [email-masked]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on argus.ritlabs.com
X-Virus-Status: Clean
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Hello All,

Could you please help to find a sample Diffie-Hellman certificate (for Key Agreement EnryptOnly key usage) or help to find a toolkit to generate one, and suggest where can I find a sample Ephemeral-Static Diffie-Hellman and Static-Static Diffie-Hellman message of RFC 3370 format? Thank you in advance.

--
Best regards,
Maxim Masiutin
Ritlabs SRL
http://www.ritlabs.com/

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13Flhcr022305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 08:47:43 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n13Flhl5022304; Tue, 3 Feb 2009 08:47:43 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n13FlWIJ022278 for ; Tue, 3 Feb 2009 08:47:42 -0700 (MST) (envelope-from [email-masked])
Message-Id: <[email-masked]>
Received: (qmail 9726 invoked by uid 0); 3 Feb 2009 15:47:28 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.24) by woodstock.binhost.com with SMTP; 3 Feb 2009 15:47:28 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 03 Feb 2009 10:28:29 -0500
To: [email-masked]
From: Russ Housley
Subject: Re: this document may of interest to PKIX members
Cc: [email-masked]
In-Reply-To:
References:
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

This document is a direct submission to the RFC Editor as part of the
Independent Submission Stream.  It is not a product of the
IETF.  The role of the IESG in such documents is to ensure that they
are not en end-run around the IETF Standards Process.  This one is
not.

Please send technical comments to the RFC Editor directly at
[email-masked].

Russ

At 05:03 AM 2/3/2009, Denis Pinkas wrote:

I have some concerns to publish draft-santoni-timestampeddata-04.txt as
an Informational RFC.

At present, the document has several major problems:

a) it does not contains any ASN.1 module at the end for the definition of
TimeStampedData,

b) the definition of TimeStampedData does not allow a compiler to process
it correctly

(i.e. Evidence cannot compile correctly).

c) the definition of TimeStampedData should be modifed to allow the
inclusion

of the possible locations of the time-stamped file
(i.e. hints about the location).

d) its scope should be targeted to time-stamp tokens and not be extended
to

"additional types of evidences to be registred
with the IETF".

e) extending the validity of TimeStampedData should be addressed or
discussed.

This document should also be redirected on the standard track, since it
defines a new smime type

and thus should  be discussed at the WG level.

If it is agreed to consider the document at the standard track level,

I would consider to co-edit the document.

Denis

----- Message reçu -----

De :
owner-ietf-pkix

À : ietf-pkix

Date : 2009-01-23, 22:38:42

Sujet : this document may of interest to PKIX members

>The IESG has no problem with the publication of 'Syntax for
binding

>documents with time stamps'
<draft-santoni-timestampeddata-04.txt> as an

>Informational RFC.

>The IESG would also like the IRSG or RFC-Editor to review the
comments in

>the datatracker

>(
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16302&rfc_flag=0
)

>related to this document and determine whether or not they
merit

>incorporation into the document. Comments may exist in both the
ballot

>and the comment log.

>The IESG contact person is Tim Polk.

>A URL of this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-santoni-timestampeddata-04.txt

>The process for such documents is described at

http://www.rfc-editor.org/indsubs.html.

>Thank you,

>The IESG Secretary

>Technical Summary

> This document describes a syntax which can be used to bind a
generic

> document (or any set of data, not necessarily protected by means
of

> cryptographic techniques) to one or more time-stamp tokens
obtained

> for that document, where "time-stamp token" has the
meaning defined

> in RFC 3161. Additional types of temporal evidence are also

> supported.

>Working Group Summary

> This document is not the product of any IETF WG.

>Protocol Quality

> The documents were reviewed by Tim Polk for the IESG. Carl
Wallace

> also reviewed the document for conflicts with the LTANS working
group.

>RFC Editor Note

> The IESG thinks that this work is related to IETF work done in
the

> Long-Term Archive and Notary Services (ltans) WG, but this does
not

> prevent publishing.

>IESG Note

> This RFC is not a candidate for any level of Internet
Standard.

> The IETF disclaims any knowledge of the fitness of this RFC
for

> any purpose and notes that the decision to publish is not based
on

> IETF review apart from IESG review for conflict with IETF work.
The

> standards track specification RFC 4998, Evidence Record Syntax
(ERS),

> specifies an alternative mechanism. Readers are encouraged to
also

> review RFC 4998 when evaluating the suitability of this
mechanism.

> The RFC Editor has chosen to publish this document at its

> discretion. See RFC 3932 for more information.

>_______________________________________________

>IETF-Announce mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ietf-announce

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13A3HA9004895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 03:03:17 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n13A3HrO004894; Tue, 3 Feb 2009 03:03:17 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13A34G0004871 for ; Tue, 3 Feb 2009 03:03:16 -0700 (MST) (envelope-from [email-masked])
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id F2A219032; Tue, 3 Feb 2009 10:55:19 +0100 (CET)
Received: from FRCLS4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2009020311030199:25872 ; Tue, 3 Feb 2009 11:03:01 +0100
Reply-To: [email-masked]
From: "Denis Pinkas"
To: "owner-ietf-pkix", "ietf-pkix"
Subject: Re: this document may of interest to PKIX members
Date: Tue, 3 Feb 2009 11:03:01 +0100
Message-Id:
References:
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 03/02/2009 11:03:01, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 03/02/2009 11:03:03, Serialize complete at 03/02/2009 11:03:03
Content-Type: multipart/alternative; boundary="----=_NextPart_09020311030110806624733_002"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

------=_NextPart_09020311030110806624733_002
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

I have some concerns to publish draft-santoni-timestampeddata-04.txt as a=
n Informational RFC.

At present, the document has several major problems:

a) it does not contains any ASN.1 module at the end for the definition of=
TimeStampedData,=20

b) the definition of TimeStampedData does not allow a compiler to process=
it correctly=20
(i.e. Evidence cannot compile correctly).

c) the definition of TimeStampedData should be modifed to allow the inclu=
sion=20
of the possible locations of the time-stamped file (i.e. hints about =
the location).

d) its scope should be targeted to time-stamp tokens and not be extended =
to=20
"additional types of evidences to be registred with the IETF".

e) extending the validity of TimeStampedData should be addressed or discu=
ssed.
=20
This document should also be redirected on the standard track, since it d=
efines a new smime type=20
and thus should be discussed at the WG level.

If it is agreed to consider the document at the standard track level,=20
I would consider to co-edit the document.

Denis

----- Message re=E7u -----=20
De : owner-ietf-pkix=20
=C0 : ietf-pkix=20
Date : 2009-01-23, 22:38:42
Sujet : this document may of interest to PKIX members

>
>
>The IESG has no problem with the publication of 'Syntax for binding
>documents with time stamps' as an
>Informational RFC.
>
>The IESG would also like the IRSG or RFC-Editor to review the comments i=
n
>
>the datatracker
>(https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dT=
ag=3D16302&rfc_flag=3D0)
>related to this document and determine whether or not they merit
>incorporation into the document. Comments may exist in both the ballot
>and the comment log.
>
>The IESG contact person is Tim Polk.
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-santoni-timestampeddata-04.txt
>
>
>The process for such documents is described at
>http://www.rfc-editor.org/indsubs.html.
>
>Thank you,
>
>The IESG Secretary
>
>Technical Summary
>
> This document describes a syntax which can be used to bind a generic
> document (or any set of data, not necessarily protected by means of
> cryptographic techniques) to one or more time-stamp tokens obtained
> for that document, where "time-stamp token" has the meaning defined
> in RFC 3161. Additional types of temporal evidence are also
> supported.
>
>Working Group Summary
>
> This document is not the product of any IETF WG.
>
>Protocol Quality
>
> The documents were reviewed by Tim Polk for the IESG. Carl Wallace
> also reviewed the document for conflicts with the LTANS working group.
>
>RFC Editor Note
>
> The IESG thinks that this work is related to IETF work done in the
> Long-Term Archive and Notary Services (ltans) WG, but this does not
> prevent publishing.
>
>IESG Note
>
> This RFC is not a candidate for any level of Internet Standard.
> The IETF disclaims any knowledge of the fitness of this RFC for
> any purpose and notes that the decision to publish is not based on
> IETF review apart from IESG review for conflict with IETF work. The
> standards track specification RFC 4998, Evidence Record Syntax (ERS),
> specifies an alternative mechanism. Readers are encouraged to also
> review RFC 4998 when evaluating the suitability of this mechanism.
> The RFC Editor has chosen to publish this document at its
> discretion. See RFC 3932 for more information.
>
>_______________________________________________
>IETF-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf-announce

------=_NextPart_09020311030110806624733_002
Content-Type: text/html;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

I have some concerns to publish draft-santoni-timestampeddata-04.txt=
as an=20
Informational RFC.

At present, the document has several major problems:

a) it does not contains any ASN.1 module at the end for the definiti=
on of=20
TimeStampedData,

b) the definition of TimeStampedData does not allow a compiler to pr=
ocess=20
it correctly
(i.e. Evidence cannot compile=20
correctly).

c) the definition of TimeStampedData should be modifed to allow the=20
inclusion
of the possible locations of the time-st=
amped=20
file (i.e. hints about the location).

d) its scope should be targeted to time-stamp tokens and not be exte=
nded to=20

"additional types of evidences to be registred wit=
h the=20
IETF".

e) extending the validity of TimeStampedData should be addressed or=20
discussed.

This document should also be redirected on the standard track, since=
it=20
defines a new smime type
and thus should  be discussed at the WG=
=20
level.

If it is agreed to consider the document at the standard track level=
,
I=20
would consider to co-edit the document.

Denis

----- Message re=E7u -----

De=20
: owner-ietf-pkix<=
/A>=20

=C0=20
: ietf-pkix

Date=20
: 2009-01-23, 22:38:42

Sujet=20
: this document may of interest to PKIX members

>
>
>The IESG has no problem with the publication o=
f=20
'Syntax for binding
>documents with time stamps'=20
<draft-santoni-timestampeddata-04.txt> as an
>Informational=
=20
RFC.
>
>The IESG would also like the IRSG or RFC-Editor to =
review=20
the comments in
>
>the datatracker
>(https://datatracker.ietf.org/pub=
lic/pidtracker.cgi?command=3Dview_id&dTag=3D16302&rfc_flag=3D0)
>related=20
to this document and determine whether or not they merit
>incorpo=
ration=20
into the document. Comments may exist in both the ballot
>and the=
=20
comment log.
>
>The IESG contact person is Tim=20
Polk.
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-santoni-timestampedd=
ata-04.txt
>The=20
process for such documents is described at
>http://www.rfc-editor.=
org/indsubs.html.
>Thank=20
you,
>The IESG Secretary
>Technical=20
Summary
>
> This document describes a syntax which can be u=
sed to=20
bind a generic
> document (or any set of data, not necessarily pr=
otected=20
by means of
> cryptographic techniques) to one or more time-stamp=
tokens=20
obtained
> for that document, where "time-stamp token" has the me=
aning=20
defined
> in RFC 3161. Additional types of temporal evidence are=20
also
> supported.
>Working Group Summary
>>=20
This document is not the product of any IETF WG.
>Protoco=
l=20
Quality
>
> The documents were reviewed by Tim Polk for the=
IESG.=20
Carl Wallace
> also reviewed the document for conflicts with the =
LTANS=20
working group.
>RFC Editor Note
> The IESG =
thinks=20
that this work is related to IETF work done in the
> Long-Term Ar=
chive=20
and Notary Services (ltans) WG, but this does not
> prevent=20
publishing.
>IESG Note
> This RFC is not a=20
candidate for any level of Internet Standard.
> The IETF disclaim=
s any=20
knowledge of the fitness of this RFC for
> any purpose and notes =
that=20
the decision to publish is not based on
> IETF review apart from =
IESG=20
review for conflict with IETF work. The
> standards track specifi=
cation=20
RFC 4998, Evidence Record Syntax (ERS),
> specifies an alternativ=
e=20
mechanism. Readers are encouraged to also
> review RFC 4998 when=20
evaluating the suitability of this mechanism.
> The RFC Editor ha=
s=20
chosen to publish this document at its
> discretion. See RFC 3932=
for=20
more=20
information.
>
>___________________________________________=
____
>IETF-Announce=20
mailing list
>[email-masked]
&=
gt;https://ww=
w.ietf.org/mailman/listinfo/ietf-announce

------=_NextPart_09020311030110806624733_002--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12HErSS056697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 10:14:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12HErFN056696; Mon, 2 Feb 2009 10:14:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12HEdvI056676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 10:14:40 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Mon, 2 Feb 2009 09:14:38 -0800
To: Alfred =?hp-roman8?B?SM5uZXM=?= , [email-masked], [email-masked], [email-masked]
From: Paul Hoffman
Subject: Re: SignatureAlgorithms in draft-ietf-pkix-3281update-03
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

At 11:17 AM +0100 2/2/09, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
>During my ongoing review of the New ASN.1 drafts, I had to revisit
>RFC 3281 and draft-ietf-pkix-3281update.
>
>Section 4.2.4 says ...
>
>|4.2.4. Signature
>|
>| Contains the algorithm identifier used to validate the AC signature.
>|
>| This MUST be one of the signing algorithms defined in [PKIXALGS].
>| Conforming implementations MUST honor all MUST/SHOULD/MAY signing
>| algorithm statements specified in [PKIXALGS].
>
>... and 10.1 (Normative References) contains:
>
>| [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and
>| Identifiers for the Internet X.509 Public Key Infrastructure
>| Certificate and Certificate Revocation Lists CRL Profile",
>| RFC 3279, April 2002.
>
>However, RFC 3279 has been Updated substantially in the meantime --
>by RFC 4055, RFC 4491, and RFC-to-be 5480 (I-D.ecc-subpubkeyinfo).

Good catch, Alfred!

>IMO, the set of signature algorithms in 3281update should be based
>on the currently reached evolutionary state of what we understand
>as [PKIXALGS].
>
>To this end, I suggest that, in the same way as the S/MIME v3.2 drafts
>contain 'collective references', the 3281update section 10.1 entry
>[PKIXALGS] should be extended by adding citations to the
>abovementioned three RFCs. (I-D.ecc-subpubkeyinfo / RFC-to-be 5480
>currently is in AUTH48, so the next draft version could already be
>written refering to RFC 5480.)

I disagree that simply changing the mapping of [PKIXALGS] to include the *current* set up updates is sufficient. Doing so certainly does not have algorithm agility for future updates.

Instead, I think that 4.2.4 should say "This MUST be one of the signing algorithms defined in [PKIXALGS] or defined in any IETF-approved update to [PKIXALGS]."

--Paul Hoffman, Director
--VPN Consortium

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12EAMZS044830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 07:10:22 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12EAMob044829; Mon, 2 Feb 2009 07:10:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n12EAA5X044803 for ; Mon, 2 Feb 2009 07:10:21 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 70067 invoked from network); 2 Feb 2009 14:10:10 -0000
Received: from unknown (HELO ?192.168.1.2?) ([email-masked] with plain) by smtp106.biz.mail.re2.yahoo.com with SMTP; 2 Feb 2009 14:10:09 -0000
X-YMail-OSG: fNOVDSoVM1nnE4_FpaOy_NHPB8npuKIW964NVF0mjpN39pKe7Z_oJHb3aXzGjU9u9LKXFMwKpyrep1aBes2hG8jxc8C_eG.b8fJGnz.8IUhvdYbWGXqkR6YX2gt0oXwsFgs2pyXiV2qBluFz.RE2dS5R1l2lvbBras456Kw5DbKMOePRp9Y7UpJ22h5F.g--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <[email-masked]>
Date: Mon, 02 Feb 2009 09:10:57 -0500
From: Sean Turner
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: =?UTF-8?B?QWxmcmVkIO+/vQ==?=
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: SignatureAlgorithms in draft-ietf-pkix-3281update-03
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

Alfred ï¿½ wrote:
> During my ongoing review of the New ASN.1 drafts, I had to revisit
> RFC 3281 and draft-ietf-pkix-3281update.
>
> Section 4.2.4 says ...
>
> |4.2.4. Signature
> |
> | Contains the algorithm identifier used to validate the AC signature.
> |
> | This MUST be one of the signing algorithms defined in [PKIXALGS].
> | Conforming implementations MUST honor all MUST/SHOULD/MAY signing
> | algorithm statements specified in [PKIXALGS].
>
> ... and 10.1 (Normative References) contains:
>
> | [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and
> | Identifiers for the Internet X.509 Public Key Infrastructure
> | Certificate and Certificate Revocation Lists CRL Profile",
> | RFC 3279, April 2002.
>
> However, RFC 3279 has been Updated substantially in the meantime --
> by RFC 4055, RFC 4491, and RFC-to-be 5480 (I-D.ecc-subpubkeyinfo).
>
> I'm in serious doubt whether draft-ietf-pkix-3281update indeed
> should want to exclude these extensions / updates / restrictions.
> (Note that RFC-to-be 5480 *excludes* some of the ECC options present
> in RFC 3279!)
> I suspect that the text in Section 4.2.4 simply has been carried over
> literally from RFC 3281 (where it was consistent state-of-the-art),
> without reconsidering the signature algorithms in detail.
>
> IMO, the set of signature algorithms in 3281update should be based
> on the currently reached evolutionary state of what we understand
> as [PKIXALGS].
>
> To this end, I suggest that, in the same way as the S/MIME v3.2 drafts
> contain 'collective references', the 3281update section 10.1 entry
> [PKIXALGS] should be extended by adding citations to the
> abovementioned three RFCs. (I-D.ecc-subpubkeyinfo / RFC-to-be 5480
> currently is in AUTH48, so the next draft version could already be
> written refering to RFC 5480.)

The only thing I'd add to the list is the update to RFC 4055.

Replace:

[PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation Lists CRL Profile",
RFC 3279, April 2002.

With:

[PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation Lists CRL Profile",
RFC 3279, April 2002.

Turner, S., Polk, W., Housley, R., Yiu, K., D. Brown,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, February 2009.

Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 4055, June
2005.

Turner, S., Polk, W., Housley, R., Yiu, K., D. Brown,
"Update for RSAES-OAEP Algorithm Parameters",
draft-ietf-pkix-rfc4055-update-01.txt, work-in-progress.

spt

> Note that draft-ietf-pkix-new-asn1-02 already contains a New ASN.1
> modules for RFC 3279 that corresponds to the unified Old ASN.1 module
> in RFC-to-be 5480.
>
> Kind regards,
> Alfred.
>
>
> P.S.: Another typo in draft-ietf-pkix-3281update, Appendix B:
> s/attribe/attribute/ .
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12AJLwn031569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 03:19:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12AJL78031568; Mon, 2 Feb 2009 03:19:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12AJ7ue031562 for ; Mon, 2 Feb 2009 03:19:18 -0700 (MST) (envelope-from [email-masked])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA060979835; Mon, 2 Feb 2009 11:17:15 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA22857; Mon, 2 Feb 2009 11:17:10 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?=
Message-Id: <[email-masked]>
Subject: SignatureAlgorithms in draft-ietf-pkix-3281update-03
To: [email-masked], [email-masked], [email-masked]
Date: Mon, 2 Feb 2009 11:17:09 +0100 (MEZ)
Cc: [email-masked]
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:

During my ongoing review of the New ASN.1 drafts, I had to revisit
RFC 3281 and draft-ietf-pkix-3281update.

Section 4.2.4 says ...

|4.2.4. Signature
|
| Contains the algorithm identifier used to validate the AC signature.
|
| This MUST be one of the signing algorithms defined in [PKIXALGS].
| Conforming implementations MUST honor all MUST/SHOULD/MAY signing
| algorithm statements specified in [PKIXALGS].

... and 10.1 (Normative References) contains:

| [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and
| Identifiers for the Internet X.509 Public Key Infrastructure
| Certificate and Certificate Revocation Lists CRL Profile",
| RFC 3279, April 2002.

However, RFC 3279 has been Updated substantially in the meantime --
by RFC 4055, RFC 4491, and RFC-to-be 5480 (I-D.ecc-subpubkeyinfo).

I'm in serious doubt whether draft-ietf-pkix-3281update indeed
should want to exclude these extensions / updates / restrictions.
(Note that RFC-to-be 5480 *excludes* some of the ECC options present
in RFC 3279!)
I suspect that the text in Section 4.2.4 simply has been carried over
literally from RFC 3281 (where it was consistent state-of-the-art),
without reconsidering the signature algorithms in detail.

IMO, the set of signature algorithms in 3281update should be based
on the currently reached evolutionary state of what we understand
as [PKIXALGS].

To this end, I suggest that, in the same way as the S/MIME v3.2 drafts
contain 'collective references', the 3281update section 10.1 entry
[PKIXALGS] should be extended by adding citations to the
abovementioned three RFCs. (I-D.ecc-subpubkeyinfo / RFC-to-be 5480
currently is in AUTH48, so the next draft version could already be
written refering to RFC 5480.)

Note that draft-ietf-pkix-new-asn1-02 already contains a New ASN.1
modules for RFC 3279 that corresponds to the unified Old ASN.1 module
in RFC-to-be 5480.

Kind regards,
Alfred.

P.S.: Another typo in draft-ietf-pkix-3281update, Appendix B:
s/attribe/attribute/ .

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: [email-masked] |
+------------------------+--------------------------------------------+