Subject: Renew/Rekey/Modification

From: Stephen Wilson <[email-masked]>
Date: Wed, 01 Apr 2009 13:41:58 +1100

Colleagues,

There are a few things about certificate "renewal" and "re-key" that 
have long confounded me.  Things only seem to have got more convoluted 
in RFC 3647 and -- no offence! -- in newer Certificate Policies like the 
US FPKI Policy Authority document.   Can anyone help me understand the 
rationale for the some of the following scenarios?  Thanks in advance!

Re-key is said (in the FPKI CP) to be a good idea because the older a 
key gets, the more susceptible it is to loss and compromise.  Fair 
enough, but why wouldn't that consideration be factored into the chosen 
certificate validity period?

Is there ever a real world scenario when a Subject would of their own 
accord request re-key because they feel the key is getting old?  If so, 
why wouldn't they revoke as well?  The FPKI CA says that after re-key 
"The old certificate may or may not be revoked".  Why would you not 
revoke, given the possibility that the key has got too old?  I don't 
think it would ever be sensible to keep using an old original key and a 
fresh key.  And if I were a Relying Party, I might like to know about 
this possible quality difference, yet there would be nothing in a CRL or 
anywhere else to mark the fact that the Subscriber has re-keyed.

The FPKI CA goes on to say that after re-key "The old certificate ... 
must not be further re-keyed, renewed, or modified".  This seems almost 
oxymoronic.  Consider that I have certificate A and then I re-key A to 
create certificate B.  And then I re-key B to create certificate C.  I 
would say that C is indistinguishable from a re-keyed A since A, B and C 
will only differ by key value.  So how is it meaningful to forbid 
re-keying A more than once? 

Finally, why does RFC 3647 bother to describe "Certificate Modification" 
at all?  The term is inherently confusing since one of the most obvious 
characteristics of a digital certificate is that it cannot be tampered 
with.  I question the need for a special bit of counter intuitive jargon 
(and a whole slab of the RFC) to cover what is really a mundane 
scenario; viz a certificate Subject needs a certificate with different 
details in it.  That is, it's just a new certificate.  Why is it treated 
any differently from an original certificate application?

Cheers,

Stephen Wilson
Lockstep Technologies
www.lockstep.com.au/technologies.

Date: Wed, 01 Apr 2009 13:41:58 +1100
From: Stephen Wilson <[email-masked]>
Reply-To: [email-masked]
Organization: Lockstep
To: [email-masked]
Subject: Renew/Rekey/Modification
Sender: [email-masked]

Colleagues,

There are a few things about certificate "renewal" and "re-key" that 
have long confounded me.  Things only seem to have got more convoluted 
in RFC 3647 and -- no offence! -- in newer Certificate Policies like the 
US FPKI Policy Authority document.   Can anyone help me understand the 
rationale for the some of the following scenarios?  Thanks in advance!

Re-key is said (in the FPKI CP) to be a good idea because the older a 
key gets, the more susceptible it is to loss and compromise.  Fair 
enough, but why wouldn't that consideration be factored into the chosen 
certificate validity period?

Is there ever a real world scenario when a Subject would of their own 
accord request re-key because they feel the key is getting old?  If so, 
why wouldn't they revoke as well?  The FPKI CA says that after re-key 
"The old certificate may or may not be revoked".  Why would you not 
revoke, given the possibility that the key has got too old?  I don't 
think it would ever be sensible to keep using an old original key and a 
fresh key.  And if I were a Relying Party, I might like to know about 
this possible quality difference, yet there would be nothing in a CRL or 
anywhere else to mark the fact that the Subscriber has re-keyed.

The FPKI CA goes on to say that after re-key "The old certificate ... 
must not be further re-keyed, renewed, or modified".  This seems almost 
oxymoronic.  Consider that I have certificate A and then I re-key A to 
create certificate B.  And then I re-key B to create certificate C.  I 
would say that C is indistinguishable from a re-keyed A since A, B and C 
will only differ by key value.  So how is it meaningful to forbid 
re-keying A more than once? 

Finally, why does RFC 3647 bother to describe "Certificate Modification" 
at all?  The term is inherently confusing since one of the most obvious 
characteristics of a digital certificate is that it cannot be tampered 
with.  I question the need for a special bit of counter intuitive jargon 
(and a whole slab of the RFC) to cover what is really a mundane 
scenario; viz a certificate Subject needs a certificate with different 
details in it.  That is, it's just a new certificate.  Why is it treated 
any differently from an original certificate application?

Cheers,

Stephen Wilson
Lockstep Technologies
www.lockstep.com.au/technologies.

Content-class: urn:content-classes:message
Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1
Date: Tue, 31 Mar 2009 12:51:25 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Massimiliano Pala" <[email-masked]>, "IETF-pkix" <[email-masked]>
Sender: [email-masked]

Max,

I do not see where and what extension we need to add for other digest
algorithm.

For key id, we need to enhance or broaden the options.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Massimiliano Pala
> Sent: Tuesday, March 31, 2009 1:37 PM
> To: IETF-pkix
> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
>=20
> Hi all,
>=20
> as I said during last meeting - as the use of SHA-1 does not=20
> have any security implication in the OCSP, another viable way=20
> would be to define an extension where other digest algorithms=20
> can be added to the request/responses.
>=20
> It is a simple addition and does not require any change in=20
> the RFC, it can be done as a separate document for those who=20
> what to use other digest algorithms.
>=20
> After all, isn't this an example of why we allow extensions=20
> to the messages ?
>=20
> Later,
> Max
>=20
>=20
> Santosh Chokhani wrote:
> > Tom,
> >=20
> > Adding a new choice and aligning it with 5280 SKID is fine.
> >=20
> > I would not add anything about matching this field with=20
> anything since=20
> > RFC 2560 does not say anything about it.
> >=20
> > If one were to add something, one should describe how this=20
> field can=20
> > be used to select from multiple Responder certificates.
> >=20
> >> -----Original Message-----
> >> From: Tom Gindin [mailto:[email-masked]]
> >> Sent: Monday, March 30, 2009 7:46 PM
> >> To: Santosh Chokhani
> >> Cc: IETF-pkix
> >> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
> >>
> >>         Santosh:
> >>
> >>         The RFC 5280 method just describes "two common methods for=20
> >> generating key identifiers from the public key"
> >> and says that other methods are acceptable.  The comment=20
> to KeyHash=20
> >> in RFC 2560 4.2.1 is not as permissive.  Of course, it's the same=20
> >> field as SKID, and I would support either stating "if the=20
> KeyHash is=20
> >> not precisely 20 octets long, it should be matched against the=20
> >> Subject Key Identifier extension of the signing certificate" or=20
> >> adding another choice like byID [3] OCTET STRING --=20
> matches the value=20
> >> of SKID.
> >>
> >>                 Tom Gindin
> >>
> >> P.S. - The above opinions are mine, and not necessarily=20
> those of my=20
> >> employer
> >>
> >>
> >>
> >>
> >> "Santosh Chokhani" <[email-masked]> Sent by:=20
> >> [email-masked]
> >> 03/26/2009 10:39 PM
> >>
> >> To
> >> "IETF-pkix" <[email-masked]>
> >> cc
> >>
> >> Subject
> >> OCSP RFC (RFC 2560) Dependence on SHA-1
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> RFC 2560 dependence on SHA-1 does not appear to be=20
> difficult to deal=20
> >> with.
> >>
> >> Section 4.3 lists SHA-1 as mandatory and RSA as optional.  We can=20
> >> update this to add SHA-2 series as optional.
> >>
> >> The Responder ID has SHA-1 hardwired.  But, that is no=20
> different than=20
> >> key ID extensions in RFC 5280.  Here are some options in order of
> >> preference:
> >>
> >> 1.  Align the language with subject key ID language in RFC 5280.
> >>
> >> 2.  Keep on using SHA-1.  This field is not security=20
> relevant.  RFC=20
> >> 2560 does not even describe how to use this field.  So,=20
> having SHA-1=20
> >> and accidental or intentional collisions will not hurt the=20
> security=20
> >> of the protocol.
> >>
> >> 3.  If you do not believe in KISS principle, you can=20
> define another=20
> >> response type and enhance the key ID ASN.1 syntax so that hash=20
> >> algorithm is identified.
> >>
> >> 4.  Another option is for the Responder to use the same hashing=20
> >> algorithm as the one in the first certID entry.
> >>
> >>
> >> Santosh Chokhani
> >> CygnaCom Solutions
> >>
> >>
> >>
> >>
> >=20
> >=20
>=20
>=20
> --=20
>=20
> Best Regards,
>=20
> 	Massimiliano Pala
>=20
> --o-----------------------------------------------------------
> -------------
> Massimiliano Pala [OpenCA Project Manager] =20
> [email-masked]
>                                                  =20
> [email-masked]
>=20
> Dartmouth Computer Science Dept               Home Phone: +1=20
> (603) 369-9332
> PKI/Trust Laboratory                          Work Phone: +1=20
> (603) 646-9179
> --o-----------------------------------------------------------
> -------------
>=20
> People who think they know everything are a great annoyance=20
> to those of us who do.
> 							   --=20
> Isaac Asimov
>=20

Date: Tue, 31 Mar 2009 13:37:07 -0400
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: IETF-pkix <[email-masked]>
Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090900050008070406030401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

as I said during last meeting - as the use of SHA-1 does not have
any security implication in the OCSP, another viable way would be
to define an extension where other digest algorithms can be added
to the request/responses.

It is a simple addition and does not require any change in the RFC,
it can be done as a separate document for those who what to use
other digest algorithms.

After all, isn't this an example of why we allow extensions to the
messages ?

Later,
Max

Santosh Chokhani wrote:
> Tom,
> 
> Adding a new choice and aligning it with 5280 SKID is fine.
> 
> I would not add anything about matching this field with anything since
> RFC 2560 does not say anything about it.
> 
> If one were to add something, one should describe how this field can be
> used to select from multiple Responder certificates.
> 
>> -----Original Message-----
>> From: Tom Gindin [mailto:[email-masked]] 
>> Sent: Monday, March 30, 2009 7:46 PM
>> To: Santosh Chokhani
>> Cc: IETF-pkix
>> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
>>
>>         Santosh:
>>
>>         The RFC 5280 method just describes "two common 
>> methods for generating key identifiers from the public key" 
>> and says that other methods are acceptable.  The comment to 
>> KeyHash in RFC 2560 4.2.1 is not as permissive.  Of course, 
>> it's the same field as SKID, and I would support either 
>> stating "if the KeyHash is not precisely 20 octets long, it 
>> should be matched against the Subject Key Identifier 
>> extension of the signing certificate" or adding another 
>> choice like byID [3] OCTET STRING -- matches the value of SKID.
>>
>>                 Tom Gindin
>>
>> P.S. - The above opinions are mine, and not necessarily those 
>> of my employer
>>
>>
>>
>>
>> "Santosh Chokhani" <[email-masked]> 
>> Sent by: [email-masked]
>> 03/26/2009 10:39 PM
>>
>> To
>> "IETF-pkix" <[email-masked]>
>> cc
>>
>> Subject
>> OCSP RFC (RFC 2560) Dependence on SHA-1
>>
>>
>>
>>
>>
>>
>>
>> RFC 2560 dependence on SHA-1 does not appear to be difficult to deal
>> with.
>>
>> Section 4.3 lists SHA-1 as mandatory and RSA as optional.  We 
>> can update
>> this to add SHA-2 series as optional.
>>
>> The Responder ID has SHA-1 hardwired.  But, that is no different than
>> key ID extensions in RFC 5280.  Here are some options in order of
>> preference:
>>
>> 1.  Align the language with subject key ID language in RFC 5280.
>>
>> 2.  Keep on using SHA-1.  This field is not security 
>> relevant.  RFC 2560
>> does not even describe how to use this field.  So, having SHA-1 and
>> accidental or intentional collisions will not hurt the security of the
>> protocol.
>>
>> 3.  If you do not believe in KISS principle, you can define another
>> response type and enhance the key ID ASN.1 syntax so that 
>> hash algorithm
>> is identified.
>>
>> 4.  Another option is for the Responder to use the same hashing
>> algorithm as the one in the first certID entry.
>>
>>
>> Santosh Chokhani
>> CygnaCom Solutions
>>
>>
>>
>>
> 
> 

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

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

--------------ms090900050008070406030401--

Content-class: urn:content-classes:message
Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1
Date: Tue, 31 Mar 2009 09:29:02 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: "IETF-pkix" <[email-masked]>
Sender: [email-masked]

Tom,

Adding a new choice and aligning it with 5280 SKID is fine.

I would not add anything about matching this field with anything since
RFC 2560 does not say anything about it.

If one were to add something, one should describe how this field can be
used to select from multiple Responder certificates.

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]=20
> Sent: Monday, March 30, 2009 7:46 PM
> To: Santosh Chokhani
> Cc: IETF-pkix
> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
>=20
>         Santosh:
>=20
>         The RFC 5280 method just describes "two common=20
> methods for generating key identifiers from the public key"=20
> and says that other methods are acceptable.  The comment to=20
> KeyHash in RFC 2560 4.2.1 is not as permissive.  Of course,=20
> it's the same field as SKID, and I would support either=20
> stating "if the KeyHash is not precisely 20 octets long, it=20
> should be matched against the Subject Key Identifier=20
> extension of the signing certificate" or adding another=20
> choice like byID [3] OCTET STRING -- matches the value of SKID.
>=20
>                 Tom Gindin
>=20
> P.S. - The above opinions are mine, and not necessarily those=20
> of my employer
>=20
>=20
>=20
>=20
> "Santosh Chokhani" <[email-masked]>=20
> Sent by: [email-masked]
> 03/26/2009 10:39 PM
>=20
> To
> "IETF-pkix" <[email-masked]>
> cc
>=20
> Subject
> OCSP RFC (RFC 2560) Dependence on SHA-1
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> RFC 2560 dependence on SHA-1 does not appear to be difficult to deal
> with.
>=20
> Section 4.3 lists SHA-1 as mandatory and RSA as optional.  We=20
> can update
> this to add SHA-2 series as optional.
>=20
> The Responder ID has SHA-1 hardwired.  But, that is no different than
> key ID extensions in RFC 5280.  Here are some options in order of
> preference:
>=20
> 1.  Align the language with subject key ID language in RFC 5280.
>=20
> 2.  Keep on using SHA-1.  This field is not security=20
> relevant.  RFC 2560
> does not even describe how to use this field.  So, having SHA-1 and
> accidental or intentional collisions will not hurt the security of the
> protocol.
>=20
> 3.  If you do not believe in KISS principle, you can define another
> response type and enhance the key ID ASN.1 syntax so that=20
> hash algorithm
> is identified.
>=20
> 4.  Another option is for the Responder to use the same hashing
> algorithm as the one in the first certID entry.
>=20
>=20
> Santosh Chokhani
> CygnaCom Solutions
>=20
>=20
>=20
>=20

To: "Santosh Chokhani" <[email-masked]>
Cc: "IETF-pkix" <[email-masked]>
Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
From: Tom Gindin <[email-masked]>
Date: Mon, 30 Mar 2009 19:46:25 -0400
Sender: [email-masked]

        Santosh:

        The RFC 5280 method just describes "two common methods for 
generating key identifiers from the public key" and says that other 
methods are acceptable.  The comment to KeyHash in RFC 2560 4.2.1 is not 
as permissive.  Of course, it's the same field as SKID, and I would 
support either stating "if the KeyHash is not precisely 20 octets long, it 
should be matched against the Subject Key Identifier extension of the 
signing certificate" or adding another choice like
byID [3] OCTET STRING -- matches the value of SKID.

                Tom Gindin

P.S. - The above opinions are mine, and not necessarily those of my 
employer

"Santosh Chokhani" <[email-masked]> 
Sent by: [email-masked]
03/26/2009 10:39 PM

To
"IETF-pkix" <[email-masked]>
cc

Subject
OCSP RFC (RFC 2560) Dependence on SHA-1

RFC 2560 dependence on SHA-1 does not appear to be difficult to deal
with.

Section 4.3 lists SHA-1 as mandatory and RSA as optional.  We can update
this to add SHA-2 series as optional.

The Responder ID has SHA-1 hardwired.  But, that is no different than
key ID extensions in RFC 5280.  Here are some options in order of
preference:

1.  Align the language with subject key ID language in RFC 5280.

2.  Keep on using SHA-1.  This field is not security relevant.  RFC 2560
does not even describe how to use this field.  So, having SHA-1 and
accidental or intentional collisions will not hurt the security of the
protocol.

3.  If you do not believe in KISS principle, you can define another
response type and enhance the key ID ASN.1 syntax so that hash algorithm
is identified.

4.  Another option is for the Responder to use the same hashing
algorithm as the one in the first certID entry.

Santosh Chokhani
CygnaCom Solutions

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-pkix-3281update (An Internet Attribute  Certificate Profile for Authorization) to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Fri, 27 Mar 2009 13:47:31 -0700 (PDT)
Sender: [email-masked]

The IESG has received a request from the Public-Key Infrastructure 
(X.509) WG (pkix) to consider the following document:

- 'An Internet Attribute Certificate Profile for Authorization '
   <draft-ietf-pkix-3281update-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-04-10. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-3281update-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17786&rfc_flag=0

The following IPR Declarations may be related to this I-D:

Content-class: urn:content-classes:message
Subject: OCSP RFC (RFC 2560) Dependence on SHA-1
Date: Thu, 26 Mar 2009 22:39:56 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "IETF-pkix" <[email-masked]>
Sender: [email-masked]

RFC 2560 dependence on SHA-1 does not appear to be difficult to deal
with.

Section 4.3 lists SHA-1 as mandatory and RSA as optional.  We can update
this to add SHA-2 series as optional.

The Responder ID has SHA-1 hardwired.  But, that is no different than
key ID extensions in RFC 5280.  Here are some options in order of
preference:

1.  Align the language with subject key ID language in RFC 5280.

2.  Keep on using SHA-1.  This field is not security relevant.  RFC 2560
does not even describe how to use this field.  So, having SHA-1 and
accidental or intentional collisions will not hurt the security of the
protocol.

3.  If you do not believe in KISS principle, you can define another
response type and enhance the key ID ASN.1 syntax so that hash algorithm
is identified.

4.  Another option is for the Responder to use the same hashing
algorithm as the one in the first certID entry.

Santosh Chokhani
CygnaCom Solutions

To: Sean Turner <[email-masked]>
Cc: [email-masked], Jan Vilhuber <[email-masked]>
Subject: Re: Nitpicking between CMS and CMC
From: Tom Gindin <[email-masked]>
Date: Thu, 26 Mar 2009 20:18:11 -0400
Sender: [email-masked]

        The definition of "sid" in CMS section 5.3 says, in part "When 
other certificate formats are referenced, the documents that specify the 
certificate format and their use with the CMS must include details on 
matching the key identifier to the appropriate certificate field."  Except 
for the fact that the certification request is not a certificate, this is 
met by CMC.
        A PKCS #10 certification request and a self-signed certificate are 
not that different in semantics or in trustworthiness.  Since a 
self-signed certificate has issuer == subject by definition and signature 
== signatureAlgorithm by RFC 5280 section 4.1.2.3, the only mandatory 
fields in a self-signed certificate whose value couldn't be derived from a 
certification request are serialNumber and validity.  The signature comes 
from the subject in both cases, and is only trusted through out-of-band 
procedures.
        Should the wording in section 5 change from "uniquely identifies 
the certificate containing" to "uniquely identifies the certificate or 
certification request containing"?  If so, another sentence about 
certification requests gets added to 5.3, like "When certification request 
formats are referenced, the documents that specify the request format and 
their use with the CMS must include details on matching the key identifier 
to the appropriate request field."

                Tom Gindin

Sean Turner <[email-masked]> 
Sent by: [email-masked]
03/26/2009 05:57 PM

To
Jan Vilhuber <[email-masked]>
cc
[email-masked]
Subject
Re: Nitpicking between CMS and CMC

I think mandating a self-signed certificates is not the way to go.

spt

Jan Vilhuber wrote:
> I noticed the following discrepancy between CMC and CMS, which could 
> very accurately be described as nitpicking (but them isn't that what 
> standards are about?):
> 
> CMS RFC, section 5. Signed-data Content Type:
> <quote>
> 
>    A recipient independently computes the message digest.  This message
>    digest and the signer's public key are used to verify the signature
>    value.  The signer's public key is referenced either by an issuer
>    distinguished name along with an issuer-specific serial number or by
>    a subject key identifier that uniquely identifies the certificate
>    containing the public key.  The signer's certificate can be included
>    in the SignedData certificates field.
> 
> </quote>
> 
> Specifically: "... or by a subject key identifier that uniquely 
identifies the certificate containing the public key".
> 
> CMC RFC, Section 3.2.  Full PKI Request
> 
> <quote>
> If SignedData is used, the signature can be generated using either the 
> private key material of an embedded signature certification request 
> (i.e., included in the TaggedRequest tcr or crm fields) or a previously 
> certified signature key. If the private key of a signature certification 

> request is used, then:
> 
> a.  The certification request containing the corresponding public key
>        MUST include a Subject Key Identifier extension
> 
>  b.  The subjectKeyIdentifier form of the signerIdentifier in
>        SignerInfo MUST be used.
> 
> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>        the Subject Key Identifier specified in the corresponding
>        certification request.  (The subjectKeyIdentifier form of
>        SignerInfo is used here because no certificates have yet been
>        issued for the signing key.)  If the request key is used for
>        signing, there MUST be only one SignerInfo in the SignedData.
> 
> </quote>
> 
> So CMC allows the SignedData to use the SubjectKeyIdentifier, but 
pointing to the certificate request it is encapsulating. While I don't 
mind this usage, the CMS rfc specifically mentions that the 
SubjectKeyIdentifier "uniquely identifies the certificate containing the 
public key".
> 
> So if we want to be nitpicky about it, then the CMC rfc is asking for 
something which is illegal as per the CMS RFC. This can be cleaned up in 
either place, i.e. either mandating in CMC that a self-signed certificate 
be included when no previous certificate has been issued (thus making it 
conform to CMS), or modify CMS to allow a more liberal application of 
where to find the public key in question.
> Thoughts?
> jan

Date: Thu, 26 Mar 2009 16:02:34 -0700
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-authorityclearanceconstraints-02.txt
Sender: [email-masked]

This version puts the correct OID for clearance (2.5.4.55) in the 
document (Kurt thanks for catching this), updates references/dates, and 
that's it.

spt

[email-masked] wrote:
> 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		: Clearance Attribute and Authority Clearance Constraints 
> Certificate Extension
> 	Author(s)	: S. Chokhani, S. Turner
> 	Filename	: draft-ietf-pkix-authorityclearanceconstraints-02.txt
> 	Pages		: 19
> 	Date		: 2009-3-26
> 	
> This document defines the syntax and semantics for the Clearance 
>    attribute and the Authority Clearance Constraints extension in X.509 
>    certificates.  The Clearance attribute is used to indicate the 
>    clearance held by the subject.  The Clearance attribute may appear in 
>    the subject directory attributes extension of a public key 
>    certificate or in the attributes field of an attribute certificate.  
>    The Authority Clearance Constraints certificate extension values in a 
>    Trust Anchor (TA), CA public key certificates, and an Attribute 
>    Authority (AA) public key certificate in a public key certification 
>    path constrain the effective Clearance of the subject.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-authorityclearanceconstraints-02.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.

Cc: Carl Wallace <[email-masked]>, [email-masked], [email-masked]
From: Jan Vilhuber <[email-masked]>
To: Sean Turner <[email-masked]>
Subject: Re: Nitpicking between CMS and CMC
Date: Thu, 26 Mar 2009 17:02:36 -0600
Sender: [email-masked]

Sounds good then.

Thanks!
jan

On Mar 26, 2009, at 4:59 PM, Sean Turner wrote:

> I agree an errata is better/quicker.
>
> spt
>
> Carl Wallace wrote:
>> This can be addressed with an errata report:
>> http://www.rfc-editor.org/errata.php. -----Original Message-----
>> From: Jan Vilhuber [mailto:[email-masked]] Sent: Thursday,  
>> March 26, 2009 3:43 PM
>> To: Carl Wallace
>> Cc: Sean Turner; [email-masked]
>> Subject: Re: Nitpicking between CMS and CMC
>> Hi Carl!
>> Works for me. Is this something that needs fixed in a new CMS   
>> revision? How does this work?
>> jan
>> On Mar 26, 2009, at 4:12 PM, Carl Wallace wrote:
>>> The "uniquely identifies" clause really only applies to the
>>> issDN/serialNum bit.  Moving it gives:
>>>
>>> A recipient independently computes the message digest.  This message
>>> digest and the signer's public key are used to verify the signature
>>> value.  The signer's public key is referenced either by an issuer
>>> distinguished name along with an issuer-specific serial number
>>> that uniquely identifies the certificate containing the public  
>>> key  or by
>>> a subject key identifier.
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>> [mailto:[email-masked]
>>> ]
>>> On Behalf Of Sean Turner
>>> Sent: Thursday, March 26, 2009 2:58 PM
>>> To: Jan Vilhuber
>>> Cc: [email-masked]
>>> Subject: Re: Nitpicking between CMS and CMC
>>>
>>>
>>> I think mandating a self-signed certificates is not the way to go.
>>>
>>> spt
>>>
>>> Jan Vilhuber wrote:
>>>> I noticed the following discrepancy between CMC and CMS, which  
>>>> could
>>>> very accurately be described as nitpicking (but them isn't that  
>>>> what
>>>> standards are about?):
>>>>
>>>> CMS RFC, section 5. Signed-data Content Type:
>>>> <quote>
>>>>
>>>>  A recipient independently computes the message digest.  This
>>> message
>>>>  digest and the signer's public key are used to verify the  
>>>> signature
>>>>  value.  The signer's public key is referenced either by an issuer
>>>>  distinguished name along with an issuer-specific serial number or
>>> by
>>>>  a subject key identifier that uniquely identifies the certificate
>>>>  containing the public key.  The signer's certificate can be
>>> included
>>>>  in the SignedData certificates field.
>>>>
>>>> </quote>
>>>>
>>>> Specifically: "... or by a subject key identifier that uniquely
>>> identifies the certificate containing the public key".
>>>> CMC RFC, Section 3.2.  Full PKI Request
>>>>
>>>> <quote>
>>>> If SignedData is used, the signature can be generated using  
>>>> either  the
>>>> private key material of an embedded signature certification request
>>>> (i.e., included in the TaggedRequest tcr or crm fields) or a
>>> previously
>>>> certified signature key. If the private key of a signature
>>> certification
>>>> request is used, then:
>>>>
>>>> a.  The certification request containing the corresponding public  
>>>> key
>>>>      MUST include a Subject Key Identifier extension
>>>>
>>>> b.  The subjectKeyIdentifier form of the signerIdentifier in
>>>>      SignerInfo MUST be used.
>>>>
>>>> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST  
>>>> be
>>>>      the Subject Key Identifier specified in the corresponding
>>>>      certification request.  (The subjectKeyIdentifier form of
>>>>      SignerInfo is used here because no certificates have yet been
>>>>      issued for the signing key.)  If the request key is used for
>>>>      signing, there MUST be only one SignerInfo in the SignedData.
>>>>
>>>> </quote>
>>>>
>>>> So CMC allows the SignedData to use the SubjectKeyIdentifier, but
>>> pointing to the certificate request it is encapsulating. While I  
>>> don't
>>> mind this usage, the CMS rfc specifically mentions that the
>>> SubjectKeyIdentifier "uniquely identifies the certificate  
>>> containing  the
>>> public key".
>>>> So if we want to be nitpicky about it, then the CMC rfc is asking  
>>>> for
>>> something which is illegal as per the CMS RFC. This can be  
>>> cleaned  up in
>>> either place, i.e. either mandating in CMC that a self-signed
>>> certificate be included when no previous certificate has been issued
>>> (thus making it conform to CMS), or modify CMS to allow a more  
>>> liberal
>>> application of where to find the public key in question.
>>>> Thoughts?
>>>>
>>>> jan
>>>>
>>>>
>>>>

Date: Thu, 26 Mar 2009 15:59:00 -0700
From: Sean Turner <[email-masked]>
To: Carl Wallace <[email-masked]>
CC: Jan Vilhuber <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Nitpicking between CMS and CMC
Sender: [email-masked]

I agree an errata is better/quicker.

spt

Carl Wallace wrote:
> This can be addressed with an errata report:
> http://www.rfc-editor.org/errata.php. 
> 
> -----Original Message-----
> From: Jan Vilhuber [mailto:[email-masked]] 
> Sent: Thursday, March 26, 2009 3:43 PM
> To: Carl Wallace
> Cc: Sean Turner; [email-masked]
> Subject: Re: Nitpicking between CMS and CMC
> 
> Hi Carl!
> 
> Works for me. Is this something that needs fixed in a new CMS  
> revision? How does this work?
> 
> jan
> 
> On Mar 26, 2009, at 4:12 PM, Carl Wallace wrote:
> 
>> The "uniquely identifies" clause really only applies to the
>> issDN/serialNum bit.  Moving it gives:
>>
>> A recipient independently computes the message digest.  This message
>> digest and the signer's public key are used to verify the signature
>> value.  The signer's public key is referenced either by an issuer
>> distinguished name along with an issuer-specific serial number
>> that uniquely identifies the certificate containing the public key  
>> or by
>> a subject key identifier.
>>
>> -----Original Message-----
>> From: [email-masked]
> [mailto:[email-masked] 
>> ]
>> On Behalf Of Sean Turner
>> Sent: Thursday, March 26, 2009 2:58 PM
>> To: Jan Vilhuber
>> Cc: [email-masked]
>> Subject: Re: Nitpicking between CMS and CMC
>>
>>
>> I think mandating a self-signed certificates is not the way to go.
>>
>> spt
>>
>> Jan Vilhuber wrote:
>>> I noticed the following discrepancy between CMC and CMS, which could
>>> very accurately be described as nitpicking (but them isn't that what
>>> standards are about?):
>>>
>>> CMS RFC, section 5. Signed-data Content Type:
>>> <quote>
>>>
>>>   A recipient independently computes the message digest.  This
>> message
>>>   digest and the signer's public key are used to verify the signature
>>>   value.  The signer's public key is referenced either by an issuer
>>>   distinguished name along with an issuer-specific serial number or
>> by
>>>   a subject key identifier that uniquely identifies the certificate
>>>   containing the public key.  The signer's certificate can be
>> included
>>>   in the SignedData certificates field.
>>>
>>> </quote>
>>>
>>> Specifically: "... or by a subject key identifier that uniquely
>> identifies the certificate containing the public key".
>>> CMC RFC, Section 3.2.  Full PKI Request
>>>
>>> <quote>
>>> If SignedData is used, the signature can be generated using either  
>>> the
>>> private key material of an embedded signature certification request
>>> (i.e., included in the TaggedRequest tcr or crm fields) or a
>> previously
>>> certified signature key. If the private key of a signature
>> certification
>>> request is used, then:
>>>
>>> a.  The certification request containing the corresponding public key
>>>       MUST include a Subject Key Identifier extension
>>>
>>> b.  The subjectKeyIdentifier form of the signerIdentifier in
>>>       SignerInfo MUST be used.
>>>
>>> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>>>       the Subject Key Identifier specified in the corresponding
>>>       certification request.  (The subjectKeyIdentifier form of
>>>       SignerInfo is used here because no certificates have yet been
>>>       issued for the signing key.)  If the request key is used for
>>>       signing, there MUST be only one SignerInfo in the SignedData.
>>>
>>> </quote>
>>>
>>> So CMC allows the SignedData to use the SubjectKeyIdentifier, but
>> pointing to the certificate request it is encapsulating. While I don't
>> mind this usage, the CMS rfc specifically mentions that the
>> SubjectKeyIdentifier "uniquely identifies the certificate containing  
>> the
>> public key".
>>> So if we want to be nitpicky about it, then the CMC rfc is asking for
>> something which is illegal as per the CMS RFC. This can be cleaned  
>> up in
>> either place, i.e. either mandating in CMC that a self-signed
>> certificate be included when no previous certificate has been issued
>> (thus making it conform to CMS), or modify CMS to allow a more liberal
>> application of where to find the public key in question.
>>> Thoughts?
>>>
>>> jan
>>>
>>>
>>>
> 
> 

Content-class: urn:content-classes:message
Subject: RE: Nitpicking between CMS and CMC
Date: Thu, 26 Mar 2009 18:48:09 -0400
From: "Carl Wallace" <[email-masked]>
To: "Jan Vilhuber" <[email-masked]>
Cc: "Sean Turner" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This can be addressed with an errata report:
http://www.rfc-editor.org/errata.php.=20

-----Original Message-----
From: Jan Vilhuber [mailto:[email-masked]]=20
Sent: Thursday, March 26, 2009 3:43 PM
To: Carl Wallace
Cc: Sean Turner; [email-masked]
Subject: Re: Nitpicking between CMS and CMC

Hi Carl!

Works for me. Is this something that needs fixed in a new CMS =20
revision? How does this work?

jan

On Mar 26, 2009, at 4:12 PM, Carl Wallace wrote:

> The "uniquely identifies" clause really only applies to the
> issDN/serialNum bit.  Moving it gives:
>
> A recipient independently computes the message digest.  This message
> digest and the signer's public key are used to verify the signature
> value.  The signer's public key is referenced either by an issuer
> distinguished name along with an issuer-specific serial number
> that uniquely identifies the certificate containing the public key =20
> or by
> a subject key identifier.
>
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]=20
> ]
> On Behalf Of Sean Turner
> Sent: Thursday, March 26, 2009 2:58 PM
> To: Jan Vilhuber
> Cc: [email-masked]
> Subject: Re: Nitpicking between CMS and CMC
>
>
> I think mandating a self-signed certificates is not the way to go.
>
> spt
>
> Jan Vilhuber wrote:
>> I noticed the following discrepancy between CMC and CMS, which could
>> very accurately be described as nitpicking (but them isn't that what
>> standards are about?):
>>
>> CMS RFC, section 5. Signed-data Content Type:
>> <quote>
>>
>>   A recipient independently computes the message digest.  This
> message
>>   digest and the signer's public key are used to verify the signature
>>   value.  The signer's public key is referenced either by an issuer
>>   distinguished name along with an issuer-specific serial number or
> by
>>   a subject key identifier that uniquely identifies the certificate
>>   containing the public key.  The signer's certificate can be
> included
>>   in the SignedData certificates field.
>>
>> </quote>
>>
>> Specifically: "... or by a subject key identifier that uniquely
> identifies the certificate containing the public key".
>>
>> CMC RFC, Section 3.2.  Full PKI Request
>>
>> <quote>
>> If SignedData is used, the signature can be generated using either =20
>> the
>
>> private key material of an embedded signature certification request
>> (i.e., included in the TaggedRequest tcr or crm fields) or a
> previously
>> certified signature key. If the private key of a signature
> certification
>> request is used, then:
>>
>> a.  The certification request containing the corresponding public key
>>       MUST include a Subject Key Identifier extension
>>
>> b.  The subjectKeyIdentifier form of the signerIdentifier in
>>       SignerInfo MUST be used.
>>
>> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>>       the Subject Key Identifier specified in the corresponding
>>       certification request.  (The subjectKeyIdentifier form of
>>       SignerInfo is used here because no certificates have yet been
>>       issued for the signing key.)  If the request key is used for
>>       signing, there MUST be only one SignerInfo in the SignedData.
>>
>> </quote>
>>
>> So CMC allows the SignedData to use the SubjectKeyIdentifier, but
> pointing to the certificate request it is encapsulating. While I don't
> mind this usage, the CMS rfc specifically mentions that the
> SubjectKeyIdentifier "uniquely identifies the certificate containing =20
> the
> public key".
>>
>> So if we want to be nitpicky about it, then the CMC rfc is asking for
> something which is illegal as per the CMS RFC. This can be cleaned =20
> up in
> either place, i.e. either mandating in CMC that a self-signed
> certificate be included when no previous certificate has been issued
> (thus making it conform to CMS), or modify CMS to allow a more liberal
> application of where to find the public key in question.
>>
>> Thoughts?
>>
>> jan
>>
>>
>>
>

Cc: "Sean Turner" <[email-masked]>, <[email-masked]>
From: Jan Vilhuber <[email-masked]>
To: Carl Wallace <[email-masked]>
Subject: Re: Nitpicking between CMS and CMC
Date: Thu, 26 Mar 2009 16:42:51 -0600
Sender: [email-masked]

Hi Carl!

Works for me. Is this something that needs fixed in a new CMS  
revision? How does this work?

jan

On Mar 26, 2009, at 4:12 PM, Carl Wallace wrote:

> The "uniquely identifies" clause really only applies to the
> issDN/serialNum bit.  Moving it gives:
>
> A recipient independently computes the message digest.  This message
> digest and the signer's public key are used to verify the signature
> value.  The signer's public key is referenced either by an issuer
> distinguished name along with an issuer-specific serial number
> that uniquely identifies the certificate containing the public key  
> or by
> a subject key identifier.
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked] 
> ]
> On Behalf Of Sean Turner
> Sent: Thursday, March 26, 2009 2:58 PM
> To: Jan Vilhuber
> Cc: [email-masked]
> Subject: Re: Nitpicking between CMS and CMC
>
>
> I think mandating a self-signed certificates is not the way to go.
>
> spt
>
> Jan Vilhuber wrote:
>> I noticed the following discrepancy between CMC and CMS, which could
>> very accurately be described as nitpicking (but them isn't that what
>> standards are about?):
>>
>> CMS RFC, section 5. Signed-data Content Type:
>> <quote>
>>
>>   A recipient independently computes the message digest.  This
> message
>>   digest and the signer's public key are used to verify the signature
>>   value.  The signer's public key is referenced either by an issuer
>>   distinguished name along with an issuer-specific serial number or
> by
>>   a subject key identifier that uniquely identifies the certificate
>>   containing the public key.  The signer's certificate can be
> included
>>   in the SignedData certificates field.
>>
>> </quote>
>>
>> Specifically: "... or by a subject key identifier that uniquely
> identifies the certificate containing the public key".
>>
>> CMC RFC, Section 3.2.  Full PKI Request
>>
>> <quote>
>> If SignedData is used, the signature can be generated using either  
>> the
>
>> private key material of an embedded signature certification request
>> (i.e., included in the TaggedRequest tcr or crm fields) or a
> previously
>> certified signature key. If the private key of a signature
> certification
>> request is used, then:
>>
>> a.  The certification request containing the corresponding public key
>>       MUST include a Subject Key Identifier extension
>>
>> b.  The subjectKeyIdentifier form of the signerIdentifier in
>>       SignerInfo MUST be used.
>>
>> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>>       the Subject Key Identifier specified in the corresponding
>>       certification request.  (The subjectKeyIdentifier form of
>>       SignerInfo is used here because no certificates have yet been
>>       issued for the signing key.)  If the request key is used for
>>       signing, there MUST be only one SignerInfo in the SignedData.
>>
>> </quote>
>>
>> So CMC allows the SignedData to use the SubjectKeyIdentifier, but
> pointing to the certificate request it is encapsulating. While I don't
> mind this usage, the CMS rfc specifically mentions that the
> SubjectKeyIdentifier "uniquely identifies the certificate containing  
> the
> public key".
>>
>> So if we want to be nitpicky about it, then the CMC rfc is asking for
> something which is illegal as per the CMS RFC. This can be cleaned  
> up in
> either place, i.e. either mandating in CMC that a self-signed
> certificate be included when no previous certificate has been issued
> (thus making it conform to CMS), or modify CMS to allow a more liberal
> application of where to find the public key in question.
>>
>> Thoughts?
>>
>> jan
>>
>>
>>
>

Content-class: urn:content-classes:message
Subject: RE: Nitpicking between CMS and CMC
Date: Thu, 26 Mar 2009 18:12:49 -0400
From: "Carl Wallace" <[email-masked]>
To: "Sean Turner" <[email-masked]>, "Jan Vilhuber" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

The "uniquely identifies" clause really only applies to the
issDN/serialNum bit.  Moving it gives:

A recipient independently computes the message digest.  This message
digest and the signer's public key are used to verify the signature
value.  The signer's public key is referenced either by an issuer
distinguished name along with an issuer-specific serial number=20
that uniquely identifies the certificate containing the public key or by
a subject key identifier. =20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sean Turner
Sent: Thursday, March 26, 2009 2:58 PM
To: Jan Vilhuber
Cc: [email-masked]
Subject: Re: Nitpicking between CMS and CMC

I think mandating a self-signed certificates is not the way to go.

spt

Jan Vilhuber wrote:
> I noticed the following discrepancy between CMC and CMS, which could=20
> very accurately be described as nitpicking (but them isn't that what=20
> standards are about?):
>=20
> CMS RFC, section 5. Signed-data Content Type:
> <quote>
>=20
>    A recipient independently computes the message digest.  This
message
>    digest and the signer's public key are used to verify the signature
>    value.  The signer's public key is referenced either by an issuer
>    distinguished name along with an issuer-specific serial number or
by
>    a subject key identifier that uniquely identifies the certificate
>    containing the public key.  The signer's certificate can be
included
>    in the SignedData certificates field.
>=20
> </quote>
>=20
> Specifically: "... or by a subject key identifier that uniquely
identifies the certificate containing the public key".
>=20
> CMC RFC, Section 3.2.  Full PKI Request
>=20
> <quote>
> If SignedData is used, the signature can be generated using either the

> private key material of an embedded signature certification request=20
> (i.e., included in the TaggedRequest tcr or crm fields) or a
previously=20
> certified signature key. If the private key of a signature
certification=20
> request is used, then:
>=20
> a.  The certification request containing the corresponding public key
>        MUST include a Subject Key Identifier extension
>=20
>  b.  The subjectKeyIdentifier form of the signerIdentifier in
>        SignerInfo MUST be used.
>=20
> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>        the Subject Key Identifier specified in the corresponding
>        certification request.  (The subjectKeyIdentifier form of
>        SignerInfo is used here because no certificates have yet been
>        issued for the signing key.)  If the request key is used for
>        signing, there MUST be only one SignerInfo in the SignedData.
>=20
> </quote>
>=20
> So CMC allows the SignedData to use the SubjectKeyIdentifier, but
pointing to the certificate request it is encapsulating. While I don't
mind this usage, the CMS rfc specifically mentions that the
SubjectKeyIdentifier "uniquely identifies the certificate containing the
public key".
>=20
> So if we want to be nitpicky about it, then the CMC rfc is asking for
something which is illegal as per the CMS RFC. This can be cleaned up in
either place, i.e. either mandating in CMC that a self-signed
certificate be included when no previous certificate has been issued
(thus making it conform to CMS), or modify CMS to allow a more liberal
application of where to find the public key in question.
>=20
> Thoughts?
>=20
> jan
>=20
>=20
>=20

Date: Thu, 26 Mar 2009 14:57:37 -0700
From: Sean Turner <[email-masked]>
To: Jan Vilhuber <[email-masked]>
CC: [email-masked]
Subject: Re: Nitpicking between CMS and CMC
Sender: [email-masked]

I think mandating a self-signed certificates is not the way to go.

spt

Jan Vilhuber wrote:
> I noticed the following discrepancy between CMC and CMS, which could 
> very accurately be described as nitpicking (but them isn't that what 
> standards are about?):
> 
> CMS RFC, section 5. Signed-data Content Type:
> <quote>
> 
>    A recipient independently computes the message digest.  This message
>    digest and the signer's public key are used to verify the signature
>    value.  The signer's public key is referenced either by an issuer
>    distinguished name along with an issuer-specific serial number or by
>    a subject key identifier that uniquely identifies the certificate
>    containing the public key.  The signer's certificate can be included
>    in the SignedData certificates field.
> 
> </quote>
> 
> Specifically: "... or by a subject key identifier that uniquely identifies the certificate containing the public key".
> 
> CMC RFC, Section 3.2.  Full PKI Request
> 
> <quote>
> If SignedData is used, the signature can be generated using either the 
> private key material of an embedded signature certification request 
> (i.e., included in the TaggedRequest tcr or crm fields) or a previously 
> certified signature key. If the private key of a signature certification 
> request is used, then:
> 
> a.  The certification request containing the corresponding public key
>        MUST include a Subject Key Identifier extension
> 
>  b.  The subjectKeyIdentifier form of the signerIdentifier in
>        SignerInfo MUST be used.
> 
> c.  The value of the subjectKeyIdentifier form of SignerInfo MUST be
>        the Subject Key Identifier specified in the corresponding
>        certification request.  (The subjectKeyIdentifier form of
>        SignerInfo is used here because no certificates have yet been
>        issued for the signing key.)  If the request key is used for
>        signing, there MUST be only one SignerInfo in the SignedData.
> 
> </quote>
> 
> So CMC allows the SignedData to use the SubjectKeyIdentifier, but pointing to the certificate request it is encapsulating. While I don't mind this usage, the CMS rfc specifically mentions that the SubjectKeyIdentifier "uniquely identifies the certificate containing the public key".
> 
> So if we want to be nitpicky about it, then the CMC rfc is asking for something which is illegal as per the CMS RFC. This can be cleaned up in either place, i.e. either mandating in CMC that a self-signed certificate be included when no previous certificate has been issued (thus making it conform to CMS), or modify CMS to allow a more liberal application of where to find the public key in question.
> 
> Thoughts?
> 
> jan
> 
> 
> 

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-authorityclearanceconstraints-02.txt 
Date: Thu, 26 Mar 2009 14:45:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

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

	Title		: Clearance Attribute and Authority Clearance Constraints 
Certificate Extension
	Author(s)	: S. Chokhani, S. Turner
	Filename	: draft-ietf-pkix-authorityclearanceconstraints-02.txt
	Pages		: 19
	Date		: 2009-3-26
	
This document defines the syntax and semantics for the Clearance 
   attribute and the Authority Clearance Constraints extension in X.509 
   certificates.  The Clearance attribute is used to indicate the 
   clearance held by the subject.  The Clearance attribute may appear in 
   the subject directory attributes extension of a public key 
   certificate or in the attributes field of an attribute certificate.  
   The Authority Clearance Constraints certificate extension values in a 
   Trust Anchor (TA), CA public key certificates, and an Attribute 
   Authority (AA) public key certificate in a public key certification 
   path constrain the effective Clearance of the subject.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-authorityclearanceconstraints-02.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-authorityclearanceconstraints-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

From: Jan Vilhuber <[email-masked]>
To: [email-masked]
Subject: Nitpicking between CMS and CMC
Date: Thu, 26 Mar 2009 15:14:38 -0600
Sender: [email-masked]

--Apple-Mail-28--50643191
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

I noticed the following discrepancy between CMC and CMS, which could  
very accurately be described as nitpicking (but them isn't that what  
standards are about?):

CMS RFC, section 5. Signed-data Content Type:
<quote>
A recipient independently computes the message digest. This message  
digest and the signer's public key are used to verify the signature  
value. The signer's public key is referenced either by an issuer  
distinguished name along with an issuer-specific serial number or by a  
subject key identifier that uniquely identifies the certificate  
containing the public key. The signer's certificate can be included in  
the SignedData certificates field.
</quote>
Specifically: "... or by a subject key identifier that uniquely  
identifies the certificate containing the public key".
CMC RFC, Section 3.2. Full PKI Request
<quote>
If SignedData is used, the signature can be generated using either the  
private key material of an embedded signature certification request  
(i.e., included in the TaggedRequest tcr or crm fields) or a  
previously certified signature key. If the private key of a signature  
certification request is used, then:
a. The certification request containing the corresponding public key  
MUST include a Subject Key Identifier extension
  b. The subjectKeyIdentifier form of the signerIdentifier in  
SignerInfo MUST be used.
c. The value of the subjectKeyIdentifier form of SignerInfo MUST be  
the Subject Key Identifier specified in the corresponding  
certification request. (The subjectKeyIdentifier form of SignerInfo is  
used here because no certificates have yet been issued for the signing  
key.) If the request key is used for signing, there MUST be only one  
SignerInfo in the SignedData.
</quote>
So CMC allows the SignedData to use the SubjectKeyIdentifier, but  
pointing to the certificate request it is encapsulating. While I don't  
mind this usage, the CMS rfc specifically mentions that the  
SubjectKeyIdentifier "uniquely identifies the certificate containing  
the public key".
So if we want to be nitpicky about it, then the CMC rfc is asking for  
something which is illegal as per the CMS RFC. This can be cleaned up  
in either place, i.e. either mandating in CMC that a self-signed  
certificate be included when no previous certificate has been issued  
(thus making it conform to CMS), or modify CMS to allow a more liberal  
application of where to find the public key in question.
Thoughts?
jan

--Apple-Mail-28--50643191
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I noticed the following =
discrepancy between CMC and CMS, which could very accurately be =
described as nitpicking (but them isn't that what standards are =
about?):<div><br></div><div>CMS RFC, section&nbsp;5.  Signed-data =
Content Type:</div><div>&lt;quote><br></div><div><pre><font =
class=3D"Apple-style-span" size=3D"4" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"font-size: 16px; white-space: =
normal;">   A recipient independently computes the message digest.  This =
message
   digest and the signer's public key are used to verify the signature
   value.  The signer's public key is referenced either by an issuer
   distinguished name along with an issuer-specific serial number or by
   a subject key identifier that uniquely identifies the certificate
   containing the public key.  The signer's certificate can be included
   in the SignedData certificates field.
</span></font><font class=3D"Apple-style-span" size=3D"4" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"font-size: =
16px; white-space: normal;">
</span></font></pre><pre><font class=3D"Apple-style-span" size=3D"4" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"font-size: =
16px; white-space: normal;">&lt;/quote></span></font></pre><pre><font =
class=3D"Apple-style-span" size=3D"4" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"font-size: 16px; white-space: =
normal;"><pre><span class=3D"Apple-style-span" style=3D"font-family: =
Helvetica; white-space: normal; ">Specifically: "...&nbsp;or by a =
subject key identifier that uniquely identifies the certificate =
containing the public key".</span></pre></span></font></pre><pre><span =
class=3D"Apple-style-span" style=3D"font-size: 16px; white-space: =
normal; font-family: Helvetica; ">CMC RFC, Section&nbsp;3.2.  Full PKI =
Request</span></pre><pre><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 16px; white-space: =
normal;"><div>&lt;quote></div><div>If SignedData is used, the signature =
can be generated using either
   the private key material of an embedded signature certification
   request (i.e., included in the TaggedRequest tcr or crm fields) or a
   previously certified signature key.  If the private key of a
   signature certification request is used, then:</div><pre><font =
class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: normal;">a.  The =
certification request containing the corresponding public key
       MUST include a Subject Key Identifier =
extension</span></font></pre><pre><font class=3D"Apple-style-span" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"white-space: =
normal;">&nbsp;b.  The subjectKeyIdentifier form of the signerIdentifier =
in
       SignerInfo MUST be used.</span></font></pre><pre><font =
class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: normal;">c.  The value =
of the subjectKeyIdentifier form of SignerInfo MUST be
       the Subject Key Identifier specified in the corresponding
       certification request.  (The subjectKeyIdentifier form of
       SignerInfo is used here because no certificates have yet been
       issued for the signing key.)  If the request key is used for
       signing, there MUST be only one SignerInfo in the SignedData.
</span></font><font class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: normal;">
</span></font></pre><pre><font class=3D"Apple-style-span" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"white-space: =
normal;"><pre><font class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: =
normal;">&lt;/quote></span></font></pre><pre><font =
class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: normal;">So CMC allows =
the SignedData to use the SubjectKeyIdentifier, but pointing to the =
certificate request it is encapsulating. While I don't mind this usage, =
the CMS rfc specifically mentions that the SubjectKeyIdentifier =
"uniquely identifies the certificate containing the public =
key".</span></font></pre><pre><font class=3D"Apple-style-span" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"white-space: =
normal;">So if we want to be nitpicky about it, then the CMC rfc is =
asking for something which is illegal as per the CMS RFC. This can be =
cleaned up in either place, i.e. either mandating in CMC that a =
self-signed certificate be included when no previous certificate has =
been issued (thus making it conform to CMS), or modify CMS to allow a =
more liberal application of where to find the public key in =
question.</span></font></pre><pre><font class=3D"Apple-style-span" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"white-space: =
normal;">Thoughts?</span></font></pre><pre><font =
class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: =
normal;">jan</span></font></pre><pre><font class=3D"Apple-style-span" =
face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"white-space: =
normal;"><br></span></font></pre></span></font></pre><pre><font =
class=3D"Apple-style-span" face=3D"Helvetica"><span =
class=3D"Apple-style-span" style=3D"white-space: =
normal;"><br></span></font></pre></span></font></pre></div></body></html>=

--Apple-Mail-28--50643191--

Date: Wed, 25 Mar 2009 22:36:43 -0700
From: Sean Turner <[email-masked]>
To: Massimiliano Pala <[email-masked]>
CC: Stefan Santesson <[email-masked]>, Paul Hoffman <[email-masked]>, pkix <[email-masked]>
Subject: Re: PRQP - Split document in two ?
Sender: [email-masked]

+1

Stefan Santesson wrote:
> I tend to agree with Paul. Unless there is a compelling reason to split the
> document, then having one is better.
> 
> /Stefan
> 
> On 3/25/09 5:06 PM, "Massimiliano Pala" <[email-masked]>
> wrote:
> 
>> Thanks Paul, that's a good point... :D
>>
>> If nobody says anything in favor of the opposite solution.. we'll go with
>> one document only (I do agree that from an implementer's point of view it
>> might be confusing having multiple docs...).
>>
>> Later,
>> Max
>>
>> Paul Hoffman wrote:
>> [...]
>>> Please don't. It just causes implementers to look for two RFCs. It is not a
>>> big deal to
>>> update part of an RFC.
> 
> 
> 

Date: Wed, 25 Mar 2009 19:18:31 -0700
Subject: Re: PRQP - Split document in two ?
From: Stefan Santesson <[email-masked]>
To: Massimiliano Pala <[email-masked]>, Paul Hoffman <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

I tend to agree with Paul. Unless there is a compelling reason to split the
document, then having one is better.

/Stefan

On 3/25/09 5:06 PM, "Massimiliano Pala" <[email-masked]>
wrote:

> Thanks Paul, that's a good point... :D
> 
> If nobody says anything in favor of the opposite solution.. we'll go with
> one document only (I do agree that from an implementer's point of view it
> might be confusing having multiple docs...).
> 
> Later,
> Max
> 
> Paul Hoffman wrote:
> [...]
>> Please don't. It just causes implementers to look for two RFCs. It is not a
>> big deal to
>> update part of an RFC.

Date: Wed, 25 Mar 2009 17:06:38 -0700
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: Paul Hoffman <[email-masked]>, pkix <[email-masked]>
Subject: Re: PRQP - Split document in two ?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms020408080305020702030805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks Paul, that's a good point... :D

If nobody says anything in favor of the opposite solution.. we'll go with
one document only (I do agree that from an implementer's point of view it
might be confusing having multiple docs...).

Later,
Max

Paul Hoffman wrote:
[...]
> Please don't. It just causes implementers to look for two RFCs. It is not a big deal to
> update part of an RFC.

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

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

--------------ms020408080305020702030805--

Date: Wed, 25 Mar 2009 16:15:37 -0700
To: Massimiliano Pala <[email-masked]>, pkix <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: PRQP - Split document in two ?
Sender: [email-masked]

At 11:37 AM -0700 3/25/09, Massimiliano Pala wrote:
>Hi all,
>
>thinking about the document I think that there might be good reasons to
>split the document in two. In particular it would be worth considering
>splitting the document in:
>- Specification of the Protocol
>- List of service/repositories OIDs and their description
>In this way the two different part of the document can be updated independently.
>More specifically, I see the list of OIDs to be more subject to changes than
>the PRQP core itself.
>
>What does the WG and the WG Chairs think about it ? Worth exploring or it is
>better to go with what we have now and proceed as decided in the meeting ?

Please don't. It just causes implementers to look for two RFCs. It is not a big deal to update part of an RFC.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 25 Mar 2009 11:37:03 -0700
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: pkix <[email-masked]>
Subject: PRQP - Split document in two ?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms070103090808090100030905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

thinking about the document I think that there might be good reasons to
split the document in two. In particular it would be worth considering
splitting the document in:
- Specification of the Protocol
- List of service/repositories OIDs and their description
In this way the two different part of the document can be updated independently.
More specifically, I see the list of OIDs to be more subject to changes than
the PRQP core itself.

What does the WG and the WG Chairs think about it ? Worth exploring or it is
better to go with what we have now and proceed as decided in the meeting ?

Later,
Max

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

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

--------------ms070103090808090100030905--

Date: Tue, 24 Mar 2009 09:37:17 -0700
From: "David A. Cooper" <[email-masked]>
To: Bill Russell <[email-masked]>
CC: [email-masked], PKIX <[email-masked]>
Subject: Re: [x500standard] Re: User certificates
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1252"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bill,<br>
<br>
Here is the definition from X.509:<br>
<blockquote type="cite">A user may obtain one or more public-key
certificates from one or more
CAs. The userCertificate attribute type contains the public-key
certificates a user has obtained from one or more CAs.</blockquote>
So, it cannot be used to hold attribute certificates.  There is a
separate set of attributes to hold attribute certificates.  For
example, attributeCertificateAttribute:<br>
<blockquote type="cite">The [attributeCertificateAttribute] contains
attribute certificates issued to a specific holder and is stored in the
directory entry of that holder. </blockquote>
<br>
But, I am surprised to hear that most applications assume only one
certificate in the userCertificate attribute.  In most directory
entries that I see for end users, there are two certificates in the
userCertificate attribute: a digital signature certificate and a key
management certificate.<br>
<br>
Dave<br>
<br>
<br>
Bill Russell wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <style>@font-face {
	font-family: Helvetica;
}
@font-face {
	font-family: Times;
}
@page Section1 {margin: 72.0pt 90.0pt 72.0pt 90.0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
H3 {
	FONT-SIZE: 10pt; MARGIN: 9.05pt 0cm 6pt; FONT-FAMILY: Times; TEXT-ALIGN: justify
}
P.MsoToc4 {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt 87.9pt; TEXT-INDENT: -45.35pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
LI.MsoToc4 {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt 87.9pt; TEXT-INDENT: -45.35pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
DIV.MsoToc4 {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt 87.9pt; TEXT-INDENT: -45.35pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
P.MsoToc5 {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 48pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoToc5 {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 48pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoToc5 {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt 48pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
P.ASN1 {
	FONT-WEIGHT: bold; FONT-SIZE: 9pt; MARGIN: 6.8pt 0cm 0pt; FONT-FAMILY: Helvetica
}
LI.ASN1 {
	FONT-WEIGHT: bold; FONT-SIZE: 9pt; MARGIN: 6.8pt 0cm 0pt; FONT-FAMILY: Helvetica
}
DIV.ASN1 {
	FONT-WEIGHT: bold; FONT-SIZE: 9pt; MARGIN: 6.8pt 0cm 0pt; FONT-FAMILY: Helvetica
}
SPAN.EmailStyle20 {
	COLOR: windowtext; FONT-FAMILY: Arial
}
DIV.Section1 {
	
}
  </style>
  <meta content="MSHTML 6.00.6001.18203" name="GENERATOR">
  <style title="owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
  </style>
  <div dir="ltr"><font color="#000000" face="Tahoma" size="2">I believe
the directory attribute userCertificate is a multivalue attribute. I
see no reason why it cannot be used to store an attribute certificate.
However, some applications may get confused. I think in practice, most
apps assume only one certificate in the userCertificate.</font></div>
  <div dir="ltr"> </div>
  <div dir="ltr"><font face="tahoma" size="2">The term "user" has
proved ambiguous; so, I'd agree that there would be some value in
defining it. However, I would not define it to exclude attribute
certificates.</font></div>
  <div id="divRpF623000" style="direction: ltr;">
  <hr tabindex="-1"><font face="Tahoma" size="2"><b><br>
  </b></font></div>
</blockquote>
<br>
</body>
</html>

From: "Moudrick M. Dadashov" <[email-masked]>
Reply-to: "Moudrick M. Dadashov" <[email-masked]>
To: "Erik Andersen" <[email-masked]>
Cc: "Directory list" <[email-masked]>, "PKIX" <[email-masked]>
Subject: RE: User certificates
Date: Tue, 24 Mar 2009 16:05:16 +0200
Sender: [email-masked]

Is 'user certificate' the same as 'end entity' certificate used more =
often?

M.D.
Cell: +370-699-26662=20

-original message-
Subject: User certificates
From: "Erik Andersen" <[email-masked]>
Date: 24.03.2009 16:00

The term "user certificate" is used in X.509 (and X.511) without =
being
defined. I assume that a user certificate is a public-key certificate =
issued
to  an end-user. There is an attribute type called userCertificate, =
which
has the syntax of public-key certificates. It seems therefore clear that =
a
user certificate cannot be an attribute certificate.

=20

In the "8.6.2.7 AA Issuing Distribution Point extension" the term =
user
certificate is mentioned in last the paragraph just before the three =
notes.
Is that correct?

=20

The term "user certificate" should be defined.

=20

Any comments?

=20

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

From: "Erik Andersen" <[email-masked]>
To: "Directory list" <[email-masked]>, "PKIX" <[email-masked]>
Subject: User certificates
Date: Tue, 24 Mar 2009 14:39:17 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0020_01C9AC8E.55125C90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The term "user certificate" is used in X.509 (and X.511) without being
defined. I assume that a user certificate is a public-key certificate =
issued
to  an end-user. There is an attribute type called userCertificate, =
which
has the syntax of public-key certificates. It seems therefore clear that =
a
user certificate cannot be an attribute certificate.

=20

In the "8.6.2.7 AA Issuing Distribution Point extension" the term user
certificate is mentioned in last the paragraph just before the three =
notes.
Is that correct?

=20

The term "user certificate" should be defined.

=20

Any comments?

=20

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

------=_NextPart_000_0020_01C9AC8E.55125C90
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h3
	{margin-top:9.05pt;
	margin-right:0cm;
	margin-bottom:6.0pt;
	margin-left:0cm;
	text-align:justify;
	page-break-after:avoid;
	font-size:10.0pt;
	font-family:Times;}
p.MsoToc4, li.MsoToc4, div.MsoToc4
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:87.9pt;
	margin-bottom:.0001pt;
	text-align:justify;
	text-indent:-45.35pt;
	font-size:10.0pt;
	font-family:"Times New Roman";}
p.MsoToc5, li.MsoToc5, div.MsoToc5
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:48.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.ASN1, li.ASN1, div.ASN1
	{margin-top:6.8pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:0cm;
	margin-bottom:.0001pt;
	punctuation-wrap:simple;
	text-autospace:none;
	font-size:9.0pt;
	font-family:Helvetica;
	font-weight:bold;}
span.EmailStyle20
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The term &#8220;user certificate&#8221; is =
used in
X.509 (and X.511) without being defined. I assume that a user =
certificate is a
public-key certificate issued to &nbsp;an end-user. There is an =
attribute type called
userCertificate, which has the syntax of public-key certificates. It =
seems therefore
clear that a user certificate cannot be an attribute =
certificate.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>In the <a =
name=3D"_Toc209430490">&#8220;8.6.2.7 AA
Issuing Distribution Point extension</a>&#8221; the term user =
certificate is
mentioned in last the paragraph just before the three notes. Is that =
correct?</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>The term &#8220;user certificate&#8221; should =
be defined.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Any comments?</span></font></p>

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

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Erik Andersen</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Andersen's L-Service</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Elsevej 48, DK-3500 Vaerloese</span></font></p>

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

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>Mobile: +45 2097 1490</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>email: </span></font><font size=3D2 =
face=3DArial><span
 lang=3DEN-GB =
style=3D'font-size:10.0pt;font-family:Arial'>[email-masked]</span></font></p=

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span lang=3DEN-GB =
style=3D'font-size:
10.0pt;font-family:Arial'>www.x500.eu</span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>www.x500standard.com</span></font></p>

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

</div>

</body>

</html>

------=_NextPart_000_0020_01C9AC8E.55125C90--

Date: Tue, 24 Mar 2009 11:56:26 +0000
From: Nuno Ponte <[email-masked]>
Organization: MULTICERT - =?ISO-8859-1?Q?Servi=E7os_de_Certifica=E7=E3?= =?ISO-8859-1?Q?o_Electr=F3nica=2C_S=2EA=2E?=
To: "David A. Cooper" <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: Need help finding implementations of certain RFC 5280 features
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms080800010409080007000707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Em 05-03-2009 22:55, David A. Cooper escreveu:
>
> All,
>
> I have been asked to work on finding two independent implementations=20
> of every feature in RFC 5280 in order to support the process of=20
> advancing RFC 5280 to Draft Standard.  I have been fairly successful=20
> so far, but there are a lot of features in RFC 5280 that need to be=20
> covered.  So, this will likely be the first of many emails requesting=20
> help in finding implementations of certain features.
>
> So, please let me know if you are aware of any certificates that=20
> satisfy either of the following requirements:
>
> 1) From Section 4.2.1.4 (Certificate Policies):
>
>      An explicitText field includes the textual statement directly in
>      the certificate.  The explicitText field is a string with a
>      maximum size of 200 characters.  Conforming CAs SHOULD use the
>      UTF8String encoding for explicitText, but MAY use IA5String.
>      Conforming CAs MUST NOT encode explicitText as VisibleString or
>      BMPString.  The explicitText string SHOULD NOT include any control=

>      characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
>      the UTF8String encoding is used, all character sequences SHOULD be=

>      normalized according to Unicode normalization form C (NFC) [NFC].
>
> I have found several certificates that include a userNotice policy=20
> qualifier with explicitText, but every one of them encodes the=20
> explicitText as VisibleString.

     I think this is due to the lack of support for UserNotices in=20
UTF8String on older versions of Microsoft Internet Explorer (as far as I =

remember, IE6 still had this problem).
     As an example, the EJBCA software (http://www.ejbca.org) has a=20
configuration to choose whether the UserNotice is encoded in UTF8String=20
or BMPString.

>
> 2) From Section 4.2.2.1 (Authority Information Access):
>
>   HTTP server implementations accessed via the URI SHOULD specify the
>   media type application/pkix-cert [RFC2585] in the content-type header=

>   field of the response for a single DER encoded certificate....
>
> I have found several certificates that include an AIA extension with=20
> an id-ad-caIssuers access method with an HTTP URI that points to a=20
> single certificate, but none of the HTTP servers specify the media=20
> type as application/pkix-cert.  Most specify the media type as=20
> application/x-x509-ca-cert and a few specify the media type as=20
> text/plain.
>
>
> Thanks in advance for any help you can give me locating certificates=20
> (and HTTP servers) that can be used to demonstrate the existence of=20
> implementations of these features.
>
> Dave
>
>
>
>

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

--------------ms080800010409080007000707--

Date: Mon, 23 Mar 2009 19:47:51 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft minutes available
Sender: [email-masked]

Folks,

I have uploaded the draft minutes for today's meeting:

http://www.ietf.org/proceedings/09mar/minutes/pkix.htm

Please review and comment.  I will process the comments for the next 
few days, and then when I return from vacation on 4/13.

Thanks,

Steve

From: "Anders Rundgren" <[email-masked]>
To: "Nuno Ponte" <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Subject: Re: PKIX bar discussion: <keygen>. Re: Agenda update and slides reminder
Date: Mon, 23 Mar 2009 20:55:59 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Hi Nuno,

Yes, generateCRMFRequest () could serve as a starting point.

That it doesn't support PIN policies which for example IETF's KEYPROV
activity does for symmetric keys, indicates that generateCRMFRequest will
though unlikely suffice as an end point.

The lack of support for subject key attestations like for example specified by
the TrustedComputingGroup is IMHO a disqualifying factor for all existing
browser key-gen schemes.

Regards
Anders

----- Original Message ----- 
From: "Nuno Ponte" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>; "'IETF-pkix'" <[email-masked]>
Sent: Monday, March 23, 2009 17:12
Subject: Re: PKIX bar discussion: <keygen>. Re: Agenda update and slides reminder

     Besides the old keygen tag, Mozilla offers a more powerful method 
for key provisioning, based in Javascript:

https://developer.mozilla.org/en/JavaScript_crypto

     It may be a starting point...

     Regards,

                     Nuno Ponte

Em 23-03-2009 14:37, Anders Rundgren escreveu:
>
> I'm sorry about not being able to visit the IETF.
>
> In case there will be any interesting evening discussions may I add
> something that you could talk about?
>
> As some of you may know the <keygen> tag was dismissed from
> the HTML5 WG spec. because it was found to be inferior.
> <keygen> is currently used by Apple, Mozilla, Nokia and Google browsers.
>
> The idea of putting a key-generation mechanism in a page-description
> language was more like a patch by Netscape more than a decade ago.
>
> Microsoft's counterpart to <keygen>, CertEnroll has AFAIK not been
> proposed as the foundation for a standard.
>
> I think it is about time to create something more thought-through that
> also supports smart cards and similar crypto containers:
> http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf
>
> It is worth noting that the scheme above does not work with PKCS #11,
> JCE, or CryptoAPI for key provisioning (since they do not support
> key attestations), but for key usage.
>
> Although not exploited in the current spec., key attestations can also
> be extended to bind declared PIN policies to generated keys.   This
> potentially enables a technical security for out-in-the-field on-line
> key provisioning that is in par with in-house production.  The use-case
> for this includes:
> - Consumer PKIs
> - Spare cards for employees that are far from their homebase
> - Mobile devices with build-in crypto HW
>
> The realization of this project is not going particularly quick (it is
> not my day-job), but it is not standing completely still either.
>
> Anders
>
> Stefan Santesson wrote:
>> I have posted a hopefully final agenda to the PKIX meeting available at:
>> http://www.ietf.org/proceedings/09mar/agenda/pkix.txt
>>
>> Meeting materials received so far are available at:
>> https://datatracker.ietf.org/meeting/74/materials.html
>>
>> I need all presentations sent to me before 17.00 San Francisco time 
>> on Sunday so I can have them all posted before the meeting starts at 
>> 0900 Monday morning.
>>
>> Thank you
>>
>> *Stefan Santesson
>> *AAA-sec.com
>>
>>
>
>
>
>

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

------=_NextPart_000_0119_01C9ABF9.C4EAFA30--

Date: Mon, 23 Mar 2009 11:06:48 -0700
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: Nuno Ponte <[email-masked]>
CC: Anders Rundgren <[email-masked]>, Stefan Santesson <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Subject: Re: PKIX bar discussion: <keygen>
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010903010905040907090401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ciao,

as a practitioner in the PKI area, I have to say that we need to have a
more powerful tool than the <keygen> tag. This said, I have to underline
that as a developer *I LOVED* the <keygen> tag because it worked all the
times, for many years, it was simple and easy to support.

Supporting other solutions took me a lot of development work and supporting
them was time and resource-consuming.

We need one standard, and we need to address *USABILITY* from three point
of view:
- Users
- Developers (Browsers)
- Developers (CAs - PKI Deployers)

So.. is there going to be some discussion about this ``at the bar'', offline
or somewhere else ?

Later,
Max

Nuno Ponte wrote:
>     Besides the old keygen tag, Mozilla offers a more powerful method 
> for key provisioning, based in Javascript:
> 
> https://developer.mozilla.org/en/JavaScript_crypto
> 
>     It may be a starting point...
> 
>     Regards,
> 
>                     Nuno Ponte
> 
> Em 23-03-2009 14:37, Anders Rundgren escreveu:
>>
>> I'm sorry about not being able to visit the IETF.
>>
>> In case there will be any interesting evening discussions may I add
>> something that you could talk about?
>>
>> As some of you may know the <keygen> tag was dismissed from
>> the HTML5 WG spec. because it was found to be inferior.
>> <keygen> is currently used by Apple, Mozilla, Nokia and Google browsers.
>>
>> The idea of putting a key-generation mechanism in a page-description
>> language was more like a patch by Netscape more than a decade ago.
>>
>> Microsoft's counterpart to <keygen>, CertEnroll has AFAIK not been
>> proposed as the foundation for a standard.
>>
>> I think it is about time to create something more thought-through that
>> also supports smart cards and similar crypto containers:
>> http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf
>>
>> It is worth noting that the scheme above does not work with PKCS #11,
>> JCE, or CryptoAPI for key provisioning (since they do not support
>> key attestations), but for key usage.
>>
>> Although not exploited in the current spec., key attestations can also
>> be extended to bind declared PIN policies to generated keys.   This
>> potentially enables a technical security for out-in-the-field on-line
>> key provisioning that is in par with in-house production.  The use-case
>> for this includes:
>> - Consumer PKIs
>> - Spare cards for employees that are far from their homebase
>> - Mobile devices with build-in crypto HW
>>
>> The realization of this project is not going particularly quick (it is
>> not my day-job), but it is not standing completely still either.
>>
>> Anders
>>
>> Stefan Santesson wrote:
>>> I have posted a hopefully final agenda to the PKIX meeting available at:
>>> http://www.ietf.org/proceedings/09mar/agenda/pkix.txt
>>>
>>> Meeting materials received so far are available at:
>>> https://datatracker.ietf.org/meeting/74/materials.html
>>>
>>> I need all presentations sent to me before 17.00 San Francisco time 
>>> on Sunday so I can have them all posted before the meeting starts at 
>>> 0900 Monday morning.
>>>
>>> Thank you
>>>
>>> *Stefan Santesson
>>> *AAA-sec.com
>>>
>>>
>>
>>
>>
>>
> 
> 

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

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

--------------ms010903010905040907090401--

Date: Mon, 23 Mar 2009 16:12:05 +0000
From: Nuno Ponte <[email-masked]>
Organization: MULTICERT - =?ISO-8859-1?Q?Servi=E7os_de_Certifica=E7=E3?= =?ISO-8859-1?Q?o_Electr=F3nica=2C_S=2EA=2E?=
To: Anders Rundgren <[email-masked]>
Cc: Stefan Santesson <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Subject: Re: PKIX bar discussion: <keygen>. Re: Agenda update and slides reminder
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms020209070405050702090006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

     Besides the old keygen tag, Mozilla offers a more powerful method=20
for key provisioning, based in Javascript:

https://developer.mozilla.org/en/JavaScript_crypto

     It may be a starting point...

     Regards,

                     Nuno Ponte

Em 23-03-2009 14:37, Anders Rundgren escreveu:
>
> I'm sorry about not being able to visit the IETF.
>
> In case there will be any interesting evening discussions may I add
> something that you could talk about?
>
> As some of you may know the <keygen> tag was dismissed from
> the HTML5 WG spec. because it was found to be inferior.
> <keygen> is currently used by Apple, Mozilla, Nokia and Google browsers=
=2E
>
> The idea of putting a key-generation mechanism in a page-description
> language was more like a patch by Netscape more than a decade ago.
>
> Microsoft's counterpart to <keygen>, CertEnroll has AFAIK not been
> proposed as the foundation for a standard.
>
> I think it is about time to create something more thought-through that
> also supports smart cards and similar crypto containers:
> http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf
>
> It is worth noting that the scheme above does not work with PKCS #11,
> JCE, or CryptoAPI for key provisioning (since they do not support
> key attestations), but for key usage.
>
> Although not exploited in the current spec., key attestations can also
> be extended to bind declared PIN policies to generated keys.   This
> potentially enables a technical security for out-in-the-field on-line
> key provisioning that is in par with in-house production.  The use-case=

> for this includes:
> - Consumer PKIs
> - Spare cards for employees that are far from their homebase
> - Mobile devices with build-in crypto HW
>
> The realization of this project is not going particularly quick (it is
> not my day-job), but it is not standing completely still either.
>
> Anders
>
> Stefan Santesson wrote:
>> I have posted a hopefully final agenda to the PKIX meeting available a=
t:
>> http://www.ietf.org/proceedings/09mar/agenda/pkix.txt
>>
>> Meeting materials received so far are available at:
>> https://datatracker.ietf.org/meeting/74/materials.html
>>
>> I need all presentations sent to me before 17.00 San Francisco time=20
>> on Sunday so I can have them all posted before the meeting starts at=20
>> 0900 Monday morning.
>>
>> Thank you
>>
>> *Stefan Santesson
>> *AAA-sec.com
>>
>>
>
>
>
>

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

--------------ms020209070405050702090006--

Date: Mon, 23 Mar 2009 15:37:51 +0100
From: Anders Rundgren <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: "'IETF-pkix'" <[email-masked]>
Subject: PKIX bar discussion: <keygen>. Re: Agenda update and slides reminder
Sender: [email-masked]

I'm sorry about not being able to visit the IETF.

In case there will be any interesting evening discussions may I add
something that you could talk about?

As some of you may know the <keygen> tag was dismissed from
the HTML5 WG spec. because it was found to be inferior.
<keygen> is currently used by Apple, Mozilla, Nokia and Google browsers.

The idea of putting a key-generation mechanism in a page-description
language was more like a patch by Netscape more than a decade ago.

Microsoft's counterpart to <keygen>, CertEnroll has AFAIK not been
proposed as the foundation for a standard.

I think it is about time to create something more thought-through that
also supports smart cards and similar crypto containers:
http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf

It is worth noting that the scheme above does not work with PKCS #11,
JCE, or CryptoAPI for key provisioning (since they do not support
key attestations), but for key usage.

Although not exploited in the current spec., key attestations can also
be extended to bind declared PIN policies to generated keys.   This
potentially enables a technical security for out-in-the-field on-line
key provisioning that is in par with in-house production.  The use-case
for this includes:
- Consumer PKIs
- Spare cards for employees that are far from their homebase
- Mobile devices with build-in crypto HW

The realization of this project is not going particularly quick (it is
not my day-job), but it is not standing completely still either.

Anders

Stefan Santesson wrote:
> I have posted a hopefully final agenda to the PKIX meeting available at:
> http://www.ietf.org/proceedings/09mar/agenda/pkix.txt
>
> Meeting materials received so far are available at:
> https://datatracker.ietf.org/meeting/74/materials.html
>
> I need all presentations sent to me before 17.00 San Francisco time on 
> Sunday so I can have them all posted before the meeting starts at 0900 
> Monday morning.
>
> Thank you
>
> *Stefan Santesson
> *AAA-sec.com
>
>

Date: Fri, 20 Mar 2009 12:44:24 -0400
To: Tom Gindin <[email-masked]>, "Miller, Timothy J." <[email-masked]>
From: Michael StJohns <[email-masked]>
Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
Cc: "'Jim Schaad'" <[email-masked]>, <[email-masked]>, "'Maxim Masiutin'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Umm...

even with case insensitivity, these two email addresses don't match...

example.com vs
examples.com

I didn't parse the BASE64 in the 4.8 example (which has an email from [email-masked]) but the asn1 dump in 4.10 has the data signed by [email-masked]

Mike

At 08:44 PM 3/17/2009, Tom Gindin wrote:

>        RFC 1274 section 9.3.3 is also on Jim's side, since the syntax of 
>the rfc822Mailbox attribute is caseIgnoreIA5StringSyntax.  It's still 
>probably better to fix the example so that it doesn't raise this vexed 
>question.
>
>                Tom Gindin
>
>
>
>
>"Miller, Timothy J." <[email-masked]> 
>Sent by: [email-masked]
>03/16/2009 11:32 AM
>
>To
>"'Jim Schaad'" <[email-masked]>, "'Maxim Masiutin'" 
><[email-masked]>, "[email-masked]" <[email-masked]>
>cc
>"[email-masked]" <[email-masked]>
>Subject
>RE: RFC4134 email mismatch in examples 4.8 and 4.9
>
>
>
>
>
>
>Not correct.  Mail address local parts are *case sensitive*.
>
>RFC5322 Section 3.4.1:
>
>"""
>The local-part portion is a domain-dependent string.
>"""
>
>RFC5321:
>
>"""
>2.4.  General Syntax Principles and Transaction Model
>
>   [...]
> 
>The
>   local-part of a mailbox MUST BE treated as case sensitive.
>   Therefore, SMTP implementations MUST take care to preserve the case
>   of mailbox local-parts.  In particular, for some hosts, the user
>   "smith" is different from the user "Smith".  However, exploiting the
>   case sensitivity of mailbox local-parts impedes interoperability and
>   is discouraged.  Mailbox domains follow normal DNS rules and are
>   hence not case sensitive.
>"""
>
>Discouraged != (MUST NOT || SHOULD NOT)
>
>We went through this argument (at my instigation) last year on the S/MIME
>list:
>
>http://osdir.com/ml/ietf.smime/2007-09/msg00004.html
>
>-- Tim
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>On Behalf Of Jim Schaad
>>Sent: Saturday, March 14, 2009 4:53 PM
>>To: 'Maxim Masiutin'; [email-masked]
>>Cc: [email-masked]
>>Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
>>
>>
>>For the purposes of S/MIME all RFC822 addresses are considered to be
>>case
>>insensitive.
>>
>>Jim
>>
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:owner-ietf-
>>> [email-masked]] On Behalf Of Maxim Masiutin
>>> Sent: Saturday, March 14, 2009 2:22 PM
>>> To: [email-masked]
>>> Cc: [email-masked]
>>> Subject: RFC4134 email mismatch in examples 4.8 and 4.9
>>>
>>> Hello,
>>>
>>> I have a question about RFC4134, Examples 4.8 and 4.9.
>>>
>>> "From" line of the RFC-822 message is [email-masked], while the
>>> certificate's SubjectAlternativeName contains Rfc822Name =
>>> [email-masked]
>>>
>>> So the two emails are different in the host part.
>>>
>>> Is it OK for them to be different?
>>>
>>>
>>> --
>>> Best regards,
>>> Maxim Masiutin
>>> Ritlabs SRL
>>> http://www.ritlabs.com/

Date: Fri, 20 Mar 2009 16:18:10 +0100
Subject: Agenda update and slides reminder
From: Stefan Santesson <[email-masked]>
To: "'IETF-pkix'" <[email-masked]>
Sender: [email-masked]

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

--B_3320410691_6010694
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

I have posted a hopefully final agenda to the PKIX meeting available at:
http://www.ietf.org/proceedings/09mar/agenda/pkix.txt

Meeting materials received so far are available at:
https://datatracker.ietf.org/meeting/74/materials.html

I need all presentations sent to me before 17.00 San Francisco time on
Sunday so I can have them all posted before the meeting starts at 0900
Monday morning.

Thank you

Stefan Santesson
AAA-sec.com

--B_3320410691_6010694
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Agenda update and slides reminder</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I have posted a hopefully final agenda to the PKIX meeting available at:<B=
R>
<a href=3D"http://www.ietf.org/proceedings/09mar/agenda/pkix.txt">http://www.=
ietf.org/proceedings/09mar/agenda/pkix.txt</a><BR>
<BR>
Meeting materials received so far are available at:<BR>
<a href=3D"https://datatracker.ietf.org/meeting/74/materials.html">https://da=
tatracker.ietf.org/meeting/74/materials.html</a><BR>
<BR>
I need all presentations sent to me before 17.00 San Francisco time on Sund=
ay so I can have them all posted before the meeting starts at 0900 Monday mo=
rning.<BR>
<BR>
Thank you<BR>
</SPAN></FONT><FONT COLOR=3D"#333333"><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verd=
ana, Helvetica, Arial"><SPAN STYLE=3D'font-size:10pt'><BR>
</SPAN></FONT></FONT></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FO=
NT COLOR=3D"#008080"><FONT FACE=3D"Cambria"><B>Stefan Santesson<BR>
</B></FONT></FONT><FONT FACE=3D"Cambria">AAA-sec.com<BR>
<BR>
</FONT></SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT>
</BODY>
</HTML>

--B_3320410691_6010694--

Date: Thu, 19 Mar 2009 16:52:09 -0400
To: Peter Sylvester <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Cc: ietf-pkix <[email-masked]>
Sender: [email-masked]

Peter:

>The disaster of contentCommitment vs nonRepudiation MUST
>not be repeated.

I agree!  The PKIX specification continue to use the older name 
(nonRepudiation instead on contentCommitment) , and I strongly 
believe that is the right thing to do as Peter argues.  Gratuitous 
name changes really need to be avoided.

Russ 

Date: Thu, 19 Mar 2009 14:16:54 +0100
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Cc: ietf-pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Sender: [email-masked]

>
>
>     In 3161, a TSA is merely a technical service similar to what is
>     said in 3161bis for a TSU. A TSA in 3161bis does not really
>     have a defined technical role.
>      
>     [Denis]  The key point is that the certificate belongs to one TSU,
>     not to one TSA.
>
No. in RFC3161 a certficate belongs to a TSA. This is a technical entity
that has the authority to create time stamps.

all organisational aspects are not part of 3161.
>
>      
>     A TSU certificate may be revoked. A TSA has no certificate and
>     thus is not revoked if one of its TSUs is compromised.
>     A TSA is the administrative entity responsible for managing one or
>     more TSUs.
>
not in RFC 3161. Besides that to me the words

  "administrative entity responsible for managing"

are ambiguous.

>
>     On the other hand the field tsa in a response refers to a TSA,
>     and to a certficate that validates it. But a TSA does no longer
>     have a certificate, only TSUs.
>     [Denis]  In the proposal, I kept the same names for the fields.
>     Maybe this is not the best choice, and "tsa" should be changed
>     into "tsu" to reflect better the difference.
>
Some people use ASN.1 compilers that generate variable names
based on asn.1 types. Changing a name is  a problem even
if the bits on the wire are the same.  Furthermore, user interfaces
may also more or less directly use the names. Think
also about a XER representation which would be used as
an intermediate format.

The disaster of contentCommitment vs nonRepudiation MUST
not be repeated.

>
>     As a consequence, the following paragraph cannot mention TSA
>     but at best a TSU.
>     Besides that it should also mentiion ESSCertIDv2.)
>
>         The purpose of the tsa field is to give a hint in identifying the
>         name of the TSA. If present, it MUST correspond to one of the
>         subject names included in the certificate that is to be used to
>         verify the token. However, the actual identification of the entity
>         that signed the response will always occur through the use of the
>         certificate identifier (ESSCertID Attribute) inside a
>         SigningCertificate attribute which is part of the signerInfo
>         (See Section 5 of [ESS]).
>
>
>     Chapter 3.3 does not use the 2119 terminology in the first phrase but
>     rather the ISO terminoilogy.
>      
>     [Denis]  Do you mean "shall" should be changed into" SHALL" ?
>
As far as I remember a 'shall' in
iso terms is the same as MUST. 

But I do not know what you intend? Do you want to
prohibit organisationalUnit for example, or not?
>
>      
>     3.3 is not relevant for the function of
>     a time stamp service. (Although it is likely that TSA actually
>     have filled all the REQUIRED 'shall) attributes in the DN)
>
>     The following text is extremely fuzzy:
>
>         The name of the issuing TSU shall contain an appropriate subset of
>         the following attributes (defined in ISO 9594-6 [ISO9594-6] and
>         ITU-T Recommendation X.520 [X.520]):
>
>             - countryName;
>             - stateOrProvinceName;
>             - organizationName;
>             - commonName.
>
>     What means "appropriate subset". The text does not exclude
>     other attributs. So in fact, it says: The TSU MUST have a subjectDN?
>     It is not defined what name identifies a TSA? for example,
>     everything except
>     the common name?
>      
>     [Denis]  The text is very explicit: "organizationName shall be
>     present". Other fields are optional.
>

Right, organisation 'shall' == MUST be present. So, if nothing else, then
you would only have one TSU of this TSA?

  "It is not defined what name identifies a TSA".

>
>     4.3 :
>
>     As it had been mentioned before the socket protocol as it is defined
>     has some problems: Since it was taken texto from CMP, there are
>     some features
>     that are may require some complexity in clients:
>     Only 00, 05, and 06 seem useful to me. If a TSA/U is not able to sign
>     a response within a few milliseconds with a TCP connection kept open,
>     I wouldn't call this a service.
>      
>     [Denis]  I care for backwards compatibility first.
>     If some cases may not exist, then we can suppress them.
>     If they may exist, then we should keep them.
>
You should think at conformance. If a client implementation
claims conformance and support of the socket protocol, does it
need to implement all these polling features?

>
>     For HTTP, a server cannot return a poll indication as a comparison.
>
>     If a client does not send a pollReq, what will happen with a pending
>     response?
>
>     The protocol does not specify who terminates the connection. Is it the
>     server that closes after one exchange?
>
>     If multiple requests and responses can be exchanged over the same
>     connection,
>     what is the dialogue model? request/response, pipelining, etc?
>
>     [Denis]  If you have a proposal , please post it to the list.*
>
I care for backward compatibility. I don't know what implementations
do. A proposal existed, you may want to recover the text from
an update to cmp.

-connection usage: Typically, a client establises a connection.
Since it is not specified who terminates it, the following
cases can occur:

- a client assumes that the connection is closed by the server.
- a client closes a connection after having received a response.
- a client may maintain a connection in order to send other
  requests.

When a client uses the third variant, it should be prepared
for the connection being closed by the server.

>
>     What is a TSU message? I think it should be TSP message. Old text was
>     TSA, which was also somewhat wrong.
>     [Denis]  A TSU Message is simply a message from a TSU.
>
I wonder whether you got the point.
>
>
>     Security section point 1 seems not quite correct:
>
>     Instead of :
>     it SHALL be set either to unspecified (0), affiliationChanged (3),
>            superseded (4) or cessationOfOperation (5). In that case,
>
>     it should say
>
>     In the case when the reasonCode is set to either
>            affiliationChanged (3),
>            superseded (4) or cessationOfOperation (5)
>
>     Unspecified means that ther can be a key compromise IMO?
>     [Denis]. Good catch. Let us delete "unspecified (0)"
>      
>
The question was: "do we need all that?"

I don't think thar

To: "Miller, Timothy J." <[email-masked]>
Cc: "'Jim Schaad'" <[email-masked]>, <[email-masked]>, "'Maxim Masiutin'" <[email-masked]>, <[email-masked]>
Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
From: Tom Gindin <[email-masked]>
Date: Tue, 17 Mar 2009 20:44:05 -0400
Sender: [email-masked]

        RFC 1274 section 9.3.3 is also on Jim's side, since the syntax of 
the rfc822Mailbox attribute is caseIgnoreIA5StringSyntax.  It's still 
probably better to fix the example so that it doesn't raise this vexed 
question.

                Tom Gindin

"Miller, Timothy J." <[email-masked]> 
Sent by: [email-masked]
03/16/2009 11:32 AM

To
"'Jim Schaad'" <[email-masked]>, "'Maxim Masiutin'" 
<[email-masked]>, "[email-masked]" <[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
RE: RFC4134 email mismatch in examples 4.8 and 4.9

Not correct.  Mail address local parts are *case sensitive*.

RFC5322 Section 3.4.1:

"""
The local-part portion is a domain-dependent string.
"""

RFC5321:

"""
2.4.  General Syntax Principles and Transaction Model

   [...]
 
The
   local-part of a mailbox MUST BE treated as case sensitive.
   Therefore, SMTP implementations MUST take care to preserve the case
   of mailbox local-parts.  In particular, for some hosts, the user
   "smith" is different from the user "Smith".  However, exploiting the
   case sensitivity of mailbox local-parts impedes interoperability and
   is discouraged.  Mailbox domains follow normal DNS rules and are
   hence not case sensitive.
"""

Discouraged != (MUST NOT || SHOULD NOT)

We went through this argument (at my instigation) last year on the S/MIME
list:

http://osdir.com/ml/ietf.smime/2007-09/msg00004.html

-- Tim

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Jim Schaad
>Sent: Saturday, March 14, 2009 4:53 PM
>To: 'Maxim Masiutin'; [email-masked]
>Cc: [email-masked]
>Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
>
>
>For the purposes of S/MIME all RFC822 addresses are considered to be
>case
>insensitive.
>
>Jim
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:owner-ietf-
>> [email-masked]] On Behalf Of Maxim Masiutin
>> Sent: Saturday, March 14, 2009 2:22 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: RFC4134 email mismatch in examples 4.8 and 4.9
>>
>> Hello,
>>
>> I have a question about RFC4134, Examples 4.8 and 4.9.
>>
>> "From" line of the RFC-822 message is [email-masked], while the
>> certificate's SubjectAlternativeName contains Rfc822Name =
>> [email-masked]
>>
>> So the two emails are different in the host part.
>>
>> Is it OK for them to be different?
>>
>>
>> --
>> Best regards,
>> Maxim Masiutin
>> Ritlabs SRL
>> http://www.ritlabs.com/

Date: Tue, 17 Mar 2009 18:06:13 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[email-masked]>
To: <[email-masked]>
CC: Jim Schaad <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Sender: [email-masked]

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

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

Denis,

On your first remark    :D

On your second remark:
Good, even that level of agreement is a great step forward. I think 1 and 2
was more an agreement between me and Julien. But since the conclusion is to
allow essCertIDv2, point 1 and 2 is of less importance.

/Stefan

On 3/17/09 4:02 PM, "[email-masked]" <[email-masked]> wrote:

> Stefan wrote his e-mail during a meeting where the priority is to listen =
to
> the meeting rather than sending e-mails
>=20
> =20
> I disagree with points 1 and 2. Point 6 is one way to move forwards, but =
is
> not the single way.
> =20
> Denis
> =20
> [email-masked] wrote: -----
>=20
> To: Stefan Santesson <[email-masked]>, Jim Schaad
> <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>,
> "'IETF-pkix'" <[email-masked]>
> From: Stefan Santesson <[email-masked]>
> Sent by: [email-masked]
> Date: 03/17/2009 03:29PM
> Subject: Re: Do we need rfc 3161bis?
>=20
> I had an informal face2face meeting here in Barcelona between me, Julien =
Stern
> and Denis Pinkas.
>=20
> I will dare myself to write down some conclusion and trust Julien and Den=
is to
> correct me if they disagree.
>=20
> 1. There is no known threat for which the essCertIDv2 is needed.
> 2. It is extremely hard to prove that there will not be any threat or att=
ack
> made up in the future where essCertIDv2 would be useful
> 3. As essCertIDv2 is standardized and has been a focus for EU work in rel=
ation
> to time stamps, it is probably reasonable to allow essCertIDv2 to be used=
 with
> RFC 3161 time stamps.
> 4. For the sake of specifying the time stamp protocol, we only need one n=
amed
> entity representing the signer of the time stamp token (currently TSA in =
RFC
> 3161).=20
> 5. There is currently a disconnect between terminology in RFC 3161 and RF=
C
> 3628 (the policy document)
> 6. A solution that would satisfy all parties of this meeting would be to =
write
> an update RFC (not a replacement as current proposal). This update RFC wo=
uld
> add the option to use essCertIDv2 AND would include an informational Anne=
x
> explaining the basic difference in terminology between RFC 3161 and RFC 3=
628.
> Most importantly this informational text would explain that TSU in the po=
licy
> document corresponds to TSA in the protocol.
>=20
> I support these conclusions.
>=20
> /Stefan
>=20
>=20
>=20
> On 3/17/09 7:55 AM, "Stefan Santesson" <[email-masked]> wrote:
>=20
>> Exactly as Jim says. Maybe we should add further that this is a bout
>> substituting one valid TSA certificate with another valid TSA certificat=
e
>> since the TSA for some reason has two TSA certificates for the same publ=
ic
>> key which when hashed, have the same SHA-1 hash.
>>=20
>> /Stefan
>>=20
>>=20
>> On 3/17/09 6:26 AM, "Jim Schaad" <[email-masked]> wrote:
>>=20
>>> The attack we are looking at is a certificate substitution attack with =
the
>>> TSA certificate being changed to a different certificate.  This is not
>>> question of trusting the TSA itself.  Unless of course it is the one tr=
ying
>>> the attack for some reason.
>>> =20
>>> =20
>>>=20
>>> From: Santosh Chokhani [mailto:[email-masked]]
>>> Sent: Monday, March 16, 2009 9:25 PM
>>> To: Stefan Santesson; Jim Schaad; IETF-pkix
>>> Subject: RE: Do we need rfc 3161bis?
>>> =20
>>> I have not followed the thread well.  But, are we losing forest for the
>>> trees here?
>>> =20
>>> Do we not trust the TSA enough to not create collision attack?
>>>> =20
>>>>=20
>>>>=20
>>>> From: [email-masked] [mailto:[email-masked]=
g] On
>>>> Behalf Of Stefan Santesson
>>>> Sent: Monday, March 16, 2009 9:01 PM
>>>> To: Jim Schaad; 'IETF-pkix'
>>>> Subject: Re: Do we need rfc 3161bis?
>>>> OK,
>>>>=20
>>>> The prefix attack only works, as you say yourself, on the tbs bits to
>>>> create two certs with the same signature. This is ONLY possible if the
>>>> signature hash algorithm is broken. The hash in the essCertID is calcu=
lated
>>>> on the complete certificates (including signatures), not only the tbs =
bits.
>>>> Thus, the prefix attack is pretty useless if you have a large chunk of
>>>> random bits in the end that is bound to be different for each cert. An=
d
>>>> they will be different IF the signature algorithm of the certificates =
is
>>>> not broken.
>>>>=20
>>>> The second question, sorry for missing it, is broader than just RFC
>>>> 3161bis.
>>>>=20
>>>> I think we have many protocols, where collision resistance is not an i=
ssue,
>>>> where we don=B9t provide algorithm agility for all uses of SHA-1. I do t=
hink
>>>> there is a use of SHA-1 in OCSP that is not part of the current update
>>>> proposal and there is currently a similar discussion in TLS where stro=
ng
>>>> arguments are raised against adding algorithm negotiation complexity w=
hen
>>>> collision resistance is not a security issue. This problem is more
>>>> political than technical. But if there is any reason to do this, it
>>>> probably is for political reasons, so your point is valid.
>>>>=20
>>>> /Stefan
>>>>=20
>>>> On 3/17/09 1:20 AM, "Jim Schaad" <[email-masked]> wrote:
>>>> Stefan,
>>>> =20
>>>> First I don=B9t know that I agree.  I think that the entirety of your
>>>> protection is actually given by the leading sequence/length bytes.  Th=
e
>>>> object is to prevent a prefix attack.  One can create a prefix attack
>>>> against the TBS bytes =AD leading to identical signatures for both versi=
ons
>>>> of the certificate.  However adding the leading sequence/length octets
>>>> probably means that you need to have two different prefix attacks =AD a =
much
>>>> harder condition, but maybe doable.
>>>> =20
>>>> However I don=B9t believe that you addressed my second point at all.  Th=
at is
>>>> people completely migrate away from SHA-1 because it is considered to =
be
>>>> broken.
>>>> =20
>>>> jim
>>>> =20
>>>>=20
>>>> From: Stefan Santesson [mailto:[email-masked]]
>>>> Sent: Monday, March 16, 2009 5:09 PM
>>>> To: Jim Schaad; 'IETF-pkix'
>>>> Subject: Re: Do we need rfc 3161bis?
>>>>=20
>>>> Jim,
>>>>=20
>>>> You ask,
>>>> The question becomes can I create two certificates that can have the s=
ame
>>>> hash, NOT will it happen by chance.
>>>>=20
>>>> I totally agree. And I don=B9t think you can.
>>>>=20
>>>> Not if the two certificates are signed with a good signature algorithm=
.
>>>> If these certificates are signed with a bad signature algorithm that a=
llows
>>>> different certificates to share the same signature, then all bets are =
off
>>>> anyway.
>>>>=20
>>>> If the signature algorithms are good, then the signatures of these
>>>> certificates will be composed of a substantial amount of vastly differ=
ent
>>>> bits. As the signature algorithm is good, you can=B9t control the bits o=
f
>>>> these signatures in any meaningful way, leaving you basically with a t=
rial
>>>> and error approach. That even if SHA-1 is broken.
>>>>=20
>>>> /Stefan
>>>>=20
>>>>=20
>>>> On 3/16/09 8:17 PM, "Jim Schaad" <[email-masked]> wrote:
>>>> Stefan,
>>>> =20
>>>> The property that is being used is not the randomness property, it is =
a
>>>> collision property.  (Or more specifically resistance to collisions.) =
  The
>>>> question becomes can I create two certificates that can have the same =
hash,
>>>> NOT will it happen by chance.   If I can do so then I have a successfu=
l
>>>> attack at this point.
>>>> =20
>>>> However one needs to assume that if SHA-1 is significantly broken, peo=
ple
>>>> will be removing it from the trusted algorithm list and would then nee=
d a
>>>> migration path of what to put in place of the current SHA-1 attribute.
>>>> This is the main reason for doing the update.
>>>> =20
>>>> jim
>>>> =20
>>>>=20
>>>> From: [email-masked] [mailto:[email-masked]=
g] On
>>>> Behalf Of Stefan Santesson
>>>> Sent: Saturday, March 14, 2009 5:54 PM
>>>> To: Jim Schaad; 'IETF-pkix'
>>>> Subject: Re: Do we need rfc 3161bis?
>>>>=20
>>>> Yes, a good question indeed.
>>>>=20
>>>> Say that SHA-1 is completely broken in the sense that we can produce
>>>> collisions at will, of all sorts and forms.
>>>> Say also that we have a few valid TSA certificates issued for the same=
 key
>>>> pair, signed using good hash algorithms (or else all bets are off anyw=
ay).
>>>>=20
>>>> The randomness properties of SHA-1 will remain intact even if SHA-1 is
>>>> broken. This means that the risk/chance that two valid certificates, s=
igned
>>>> with safe signature algorithms, will by chance produce collisions, is =
still
>>>> totally negligible.
>>>>=20
>>>> Where am I thinking wrong here?
>>>>=20
>>>> /Stefan
>>>>=20
>>>>=20
>>>>=20
>>>> On 3/14/09 8:00 PM, "Jim Schaad" <[email-masked]> wrote:
>>>> Stefan,
>>>> =20
>>>> The question you need to be asking is =AD Do you believe that SHA-1 will=
 be
>>>> broken one day, and if it is broken do you want to have in place a sol=
ution
>>>> to deal with it.
>>>> =20
>>>> Jim
>>>> =20
>>>> =20
>>>>=20
>>>> From: [email-masked] [mailto:[email-masked]=
g] On
>>>> Behalf Of Stefan Santesson
>>>> Sent: Saturday, March 14, 2009 7:06 AM
>>>> To: IETF-pkix
>>>> Subject: Do we need rfc 3161bis?
>>>>=20
>>>> The more I look into this the more I get to doubt that we actually nee=
d
>>>> 3161bis.
>>>>=20
>>>> The only substantial technical change I know of is to allow the update=
d ESS
>>>> certIDv2 to be used to identify the signer=B9s certificate IF the TSA fo=
r
>>>> some reason choose to hash its certificate with another hash then SHA-=
1.
>>>>=20
>>>> The rationale for the certID identifier is given in section 5 of RFC 2=
634
>>>> and describes attacks where one valid certificate is substituted by an=
other
>>>> valid certificate (exceopt for some DoS case that I don=B9t think is rel=
evant
>>>> here).
>>>> Now I have to ask myself. How likely is it that a legitimate TSA has 2=
  or
>>>> more legitimate certificates for the same public key with conflicting
>>>> information (or information different enough to actually have a securi=
ty
>>>> impact) AND where the hash of these certificates produce a SHA-1 colli=
sion.
>>>>=20
>>>> This is not the previously discussed certificate collision attack usin=
g
>>>> weak certificate signing hash, where I may prepare a certificate reque=
st in
>>>> a way where I can fool the CA to produce two valid certificates with t=
he
>>>> same certificate signature. If I would use that technique I would have=
 to
>>>> find a way to prepare the TSA certificate requests, the TSA certificat=
e
>>>> hash need to be weak in addition to the certID hash AND In addition to=
 that
>>>> the complete certificates (not only the to be signed part) need to cre=
ate a
>>>> hash collision when computing the certID.
>>>>=20
>>>> So, my first question is if this change addresses any real security th=
reat?
>>>> Can someone provide a reasonable threat analysis?
>>>> And consequently, if there are no real threats to solve, does this upd=
ate
>>>> motivate the potential interoperability issues that might be the resul=
t of
>>>> by allowing ESS CertIDv2 in time stamp tokens?
>>>>=20
>>>>=20
>>>> If we do come to the conclusion that it is worth it, then why not just
>>>> create an update RFC updating RFC 3161 instead of replacing it?
>>>>=20
>>>> This update does not change any bits on the wire for implementations o=
f the
>>>> current protocol. The only thing it does is to add an option to use ES=
S
>>>> certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificat=
e.
>>>> This seems like a perfect thing for an update RFC. Another argument is=
 that
>>>> the old editors that rightfully should have the credit for RFC 3161 ar=
e not
>>>> part of this minor amendment but are completely erased from the update=
.
>>>> That may be reasonable if the changes are major but I=B9m not so sure in=
 this
>>>> case.
>>>>=20
>>>>=20

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

<HTML>
<HEAD>
<TITLE>Re: Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt'>Denis,<=
BR>
<BR>
On your first remark &nbsp;&nbsp;&nbsp;:D<BR>
<BR>
On your second remark:<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana, He=
lvetica, Arial">Good, even that level of agreement is a great step forward. =
I think 1 and 2 was more an agreement between me and Julien. But since the c=
onclusion is to allow essCertIDv2, point 1 and 2 is of less importance.<BR>
<BR>
</FONT><FONT FACE=3D"Verdana, Helvetica, Arial">/Stefan<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><BR>
On 3/17/09 4:02 PM, &quot;<a href=3D"[email-masked]">denis.pinkas@bull=
.net</a>&quot; &lt;<a href=3D"[email-masked]">[email-masked]</a>=
&gt; wrote:<BR>
<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Verdana,=
 Helvetica, Arial">Stefan wrote his e-mail during a meeting where the priori=
ty is to listen to the meeting rather than sending e-mails<BR>
<BR>
&nbsp;<BR>
I disagree with points 1 and 2. Point 6 is one way to move forwards, but is=
 not the single way.<BR>
&nbsp;<BR>
Denis<BR>
&nbsp;<BR>
<FONT COLOR=3D"#990099"><a href=3D"[email-masked]">-----owne=
[email-masked]</a> wrote: -----<BR>
<BR>
</FONT>To: Stefan Santesson &lt;<a href=3D"[email-masked]">stefans@exmsft=
.com</a>&gt;, Jim Schaad &lt;<a href=3D"[email-masked]">ietf@augustcel=
lars.com</a>&gt;, &quot;'Santosh Chokhani'&quot; &lt;<a href=3D"SChokhani@cygn=
acom.com">[email-masked]</a>&gt;, &quot;'IETF-pkix'&quot; &lt;<a hre=
f=3D"[email-masked]">[email-masked]</a>&gt;<BR>
From: Stefan Santesson &lt;<a href=3D"[email-masked]">[email-masked]<=
/a>&gt;<BR>
Sent by: <a href=3D"[email-masked]">[email-masked]=
g</a><BR>
Date: 03/17/2009 03:29PM<BR>
Subject: Re: Do we need rfc 3161bis?<BR>
<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">I had an informal fa=
ce2face meeting here in Barcelona between me, Julien Stern and Denis Pinkas.=
<BR>
<BR>
I will dare myself to write down some conclusion and trust Julien and Denis=
 to correct me if they disagree.<BR>
<BR>
</FONT></SPAN><OL><LI><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Ver=
dana, Helvetica, Arial">There is no known threat for which the essCertIDv2 i=
s needed.
</FONT></SPAN><LI><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana=
, Helvetica, Arial">It is extremely hard to prove that there will not be any=
 threat or attack made up in the future where essCertIDv2 would be useful
</FONT></SPAN><LI><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana=
, Helvetica, Arial">As essCertIDv2 is standardized and has been a focus for =
EU work in relation to time stamps, it is probably reasonable to allow essCe=
rtIDv2 to be used with RFC 3161 time stamps.
</FONT></SPAN><LI><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana=
, Helvetica, Arial">For the sake of specifying the time stamp protocol, we o=
nly need one named entity representing the signer of the time stamp token (c=
urrently TSA in RFC 3161).
</FONT></SPAN><LI><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana=
, Helvetica, Arial">There is currently a disconnect between terminology in R=
FC 3161 and RFC 3628 (the policy document)
</FONT></SPAN><LI><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana=
, Helvetica, Arial">A solution that would satisfy all parties of this meetin=
g would be to write an update RFC (not a replacement as current proposal). T=
his update RFC would add the option to use essCertIDv2 AND would include an =
informational Annex &nbsp;explaining the basic difference in terminology bet=
ween RFC 3161 and RFC 3628. Most importantly this informational text would e=
xplain that TSU in the policy document corresponds to TSA in the protocol. <=
BR>
</FONT></SPAN></OL><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdan=
a, Helvetica, Arial"><BR>
I support these conclusions.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/17/09 7:55 AM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefans@exmsf=
t.com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri,=
 Verdana, Helvetica, Arial">Exactly as Jim says. Maybe we should add further=
 that this is a bout substituting one valid TSA certificate with another val=
id TSA certificate since the TSA for some reason has two TSA certificates fo=
r the same public key which when hashed, have the same SHA-1 hash.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/17/09 6:26 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri,=
 Verdana, Helvetica, Arial"><FONT COLOR=3D"#1F497D">The attack we are looking =
at is a certificate substitution attack with the TSA certificate being chang=
ed to a different certificate. &nbsp;This is not &nbsp;question of trusting =
the TSA itself. &nbsp;Unless of course it is the one trying the attack for s=
ome reason.<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><B>From:</B> Santosh =
Chokhani [<a href=3D"mailto:[email-masked]">mailto:SChokhani@cygnacom.=
com</a>] <BR>
<B>Sent:</B> Monday, March 16, 2009 9:25 PM<BR>
<B>To:</B> Stefan Santesson; Jim Schaad; IETF-pkix<BR>
<B>Subject:</B> RE: Do we need rfc 3161bis?<BR>
</FONT><FONT FACE=3D"Times New Roman"> <BR>
</FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">I have not followed the thr=
ead well. &nbsp;But, are we losing forest for the trees here?<BR>
</FONT></FONT><FONT FACE=3D"Times New Roman"> <BR>
</FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">Do we not trust the TSA eno=
ugh to not create collision attack?<BR>
</FONT></FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"T=
imes New Roman">=20
</FONT></SPAN>
<P ALIGN=3DCENTER>
<SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Times New Roman"><HR ALIGN=3DCENTER =
SIZE=3D"2" WIDTH=3D"100%"></FONT></SPAN>
<P>
<SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><BR>
</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><B>From:</B> <a href=3D=
"[email-masked]">[email-masked]</a> [<a href=3D"ma=
ilto:[email-masked]">mailto:[email-masked]</a>] =
<B>On Behalf Of </B>Stefan Santesson<BR>
<B>Sent:</B> Monday, March 16, 2009 9:01 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">OK,<BR>
<BR>
The prefix attack only works, as you say yourself, on the tbs bits to creat=
e two certs with the same signature. This is ONLY possible if the signature =
hash algorithm is broken. The hash in the essCertID is calculated on the com=
plete certificates (including signatures), not only the tbs bits.<BR>
Thus, the prefix attack is pretty useless if you have a large chunk of rand=
om bits in the end that is bound to be different for each cert. And they wil=
l be different IF the signature algorithm of the certificates is not broken.=
<BR>
<BR>
The second question, sorry for missing it, is broader than just RFC 3161bis=
.<BR>
<BR>
I think we have many protocols, where collision resistance is not an issue,=
 where we don&#8217;t provide algorithm agility for all uses of SHA-1. I do =
think there is a use of SHA-1 in OCSP that is not part of the current update=
 proposal and there is currently a similar discussion in TLS where strong ar=
guments are raised against adding algorithm negotiation complexity when coll=
ision resistance is not a security issue. This problem is more political tha=
n technical. But if there is any reason to do this, it probably is for polit=
ical reasons, so your point is valid.<BR>
<BR>
/Stefan<BR>
<BR>
On 3/17/09 1:20 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
First I don&#8217;t know that I agree. &nbsp;I think that the entirety of y=
our protection is actually given by the leading sequence/length bytes. &nbsp=
;The object is to prevent a prefix attack. &nbsp;One can create a prefix att=
ack against the TBS bytes &#8211; leading to identical signatures for both v=
ersions of the certificate. &nbsp;However adding the leading sequence/length=
 octets probably means that you need to have two different prefix attacks &#=
8211; a much harder condition, but maybe doable.<BR>
&nbsp;<BR>
However I don&#8217;t believe that you addressed my second point at all. &n=
bsp;That is people completely migrate away from SHA-1 because it is consider=
ed to be broken.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><B>From:</B> Stefan S=
antesson [<a href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]=
 <BR>
<B>Sent:</B> Monday, March 16, 2009 5:09 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</FONT><FONT FACE=3D"Times New Roman"><BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">Jim,<BR>
<BR>
You ask,<BR>
<FONT COLOR=3D"#1E487C">The question becomes can I create two certificates th=
at can have the same hash, NOT will it happen by chance.<BR>
</FONT><BR>
I <B>totally</B> agree. And I don&#8217;t think you can.<BR>
<BR>
Not if the two certificates are signed with a good signature algorithm. <BR=
If these certificates are signed with a bad signature algorithm that allows=
 different certificates to share the same signature, then all bets are off a=
nyway.<BR>
<BR>
If the signature algorithms are good, then the signatures of these certific=
ates will be composed of a substantial amount of vastly different bits. As t=
he signature algorithm is good, you can&#8217;t control the bits of these si=
gnatures in any meaningful way, leaving you basically with a trial and error=
 approach. That even if SHA-1 is broken.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The property that is being used is not the randomness property, it is a col=
lision property. &nbsp;(Or more specifically resistance to collisions.) &nbs=
p;&nbsp;The question becomes can I create two certificates that can have the=
 same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so then I =
have a successful attack at this point.<BR>
&nbsp;<BR>
However one needs to assume that if SHA-1 is significantly broken, people w=
ill be removing it from the trusted algorithm list and would then need a mig=
ration path of what to put in place of the current SHA-1 attribute. &nbsp;Th=
is is the main reason for doing the update.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><B>From:</B> <a href=3D=
"[email-masked]">[email-masked]</a> [<a href=3D"ma=
ilto:[email-masked]">mailto:[email-masked]</a>] =
<B>On Behalf Of </B>Stefan Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 5:54 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</FONT><FONT FACE=3D"Times New Roman"><BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">Yes, a good question=
 indeed.<BR>
<BR>
Say that SHA-1 is completely broken in the sense that we can produce collis=
ions at will, of all sorts and forms.<BR>
Say also that we have a few valid TSA certificates issued for the same key =
pair, signed using good hash algorithms (or else all bets are off anyway).<B=
R>
<BR>
The randomness properties of SHA-1 will remain intact even if SHA-1 is brok=
en. This means that the risk/chance that two valid certificates, signed with=
 safe signature algorithms, will by chance produce collisions, is still tota=
lly negligible.<BR>
<BR>
Where am I thinking wrong here?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The question you need to be asking is &#8211; Do you believe that SHA-1 wil=
l be broken one day, and if it is broken do you want to have in place a solu=
tion to deal with it.<BR>
&nbsp;<BR>
Jim<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><B>From:</B> <a href=3D=
"[email-masked]">[email-masked]</a> [<a href=3D"ma=
ilto:[email-masked]">mailto:[email-masked]</a>] =
<B>On Behalf Of </B>Stefan Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 7:06 AM<BR>
<B>To:</B> IETF-pkix<BR>
<B>Subject:</B> Do we need rfc 3161bis?<BR>
</FONT><FONT FACE=3D"Times New Roman"><BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">The more I look into=
 this the more I get to doubt that we actually need 3161bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.<BR>
<BR>
</FONT></SPAN></BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT FACE=3D"Verdana=
, Helvetica, Arial"><BR>
</FONT></SPAN></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE>
</BODY>
</HTML>

--B_3320157984_11999033--

Importance: Normal
Subject: Re: Do we need rfc 3161bis?
From: [email-masked]
To: Stefan Santesson <[email-masked]>
Cc: Stefan Santesson <[email-masked]>, Jim Schaad <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Date: Tue, 17 Mar 2009 16:02:19 +0100
Sender: [email-masked]

Date: Tue, 17 Mar 2009 15:29:57 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[email-masked]>
To: Stefan Santesson <[email-masked]>, Jim Schaad <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Sender: [email-masked]

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

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

I had an informal face2face meeting here in Barcelona between me, Julien
Stern and Denis Pinkas.

I will dare myself to write down some conclusion and trust Julien and Denis
to correct me if they disagree.

1. There is no known threat for which the essCertIDv2 is needed.
2. It is extremely hard to prove that there will not be any threat or attac=
k
made up in the future where essCertIDv2 would be useful
3. As essCertIDv2 is standardized and has been a focus for EU work in
relation to time stamps, it is probably reasonable to allow essCertIDv2 to
be used with RFC 3161 time stamps.
4. For the sake of specifying the time stamp protocol, we only need one
named entity representing the signer of the time stamp token (currently TSA
in RFC 3161).=20
5. There is currently a disconnect between terminology in RFC 3161 and RFC
3628 (the policy document)
6. A solution that would satisfy all parties of this meeting would be to
write an update RFC (not a replacement as current proposal). This update RF=
C
would add the option to use essCertIDv2 AND would include an informational
Annex  explaining the basic difference in terminology between RFC 3161 and
RFC 3628. Most importantly this informational text would explain that TSU i=
n
the policy document corresponds to TSA in the protocol.

I support these conclusions.

/Stefan

On 3/17/09 7:55 AM, "Stefan Santesson" <[email-masked]> wrote:

> Exactly as Jim says. Maybe we should add further that this is a bout
> substituting one valid TSA certificate with another valid TSA certificate
> since the TSA for some reason has two TSA certificates for the same publi=
c key
> which when hashed, have the same SHA-1 hash.
>=20
> /Stefan
>=20
>=20
> On 3/17/09 6:26 AM, "Jim Schaad" <[email-masked]> wrote:
>=20
>> The attack we are looking at is a certificate substitution attack with t=
he
>> TSA certificate being changed to a different certificate.  This is not
>> question of trusting the TSA itself.  Unless of course it is the one try=
ing
>> the attack for some reason.
>> =20
>> =20
>>=20
>> From: Santosh Chokhani [mailto:[email-masked]]
>> Sent: Monday, March 16, 2009 9:25 PM
>> To: Stefan Santesson; Jim Schaad; IETF-pkix
>> Subject: RE: Do we need rfc 3161bis?
>> =20
>> I have not followed the thread well.  But, are we losing forest for the =
trees
>> here?
>> =20
>> Do we not trust the TSA enough to not create collision attack?
>>> =20
>>>=20
>>>=20
>>> From: [email-masked] [mailto:[email-masked]=
] On
>>> Behalf Of Stefan Santesson
>>> Sent: Monday, March 16, 2009 9:01 PM
>>> To: Jim Schaad; 'IETF-pkix'
>>> Subject: Re: Do we need rfc 3161bis?
>>> OK,
>>>=20
>>> The prefix attack only works, as you say yourself, on the tbs bits to c=
reate
>>> two certs with the same signature. This is ONLY possible if the signatu=
re
>>> hash algorithm is broken. The hash in the essCertID is calculated on th=
e
>>> complete certificates (including signatures), not only the tbs bits.
>>> Thus, the prefix attack is pretty useless if you have a large chunk of
>>> random bits in the end that is bound to be different for each cert. And=
 they
>>> will be different IF the signature algorithm of the certificates is not
>>> broken.
>>>=20
>>> The second question, sorry for missing it, is broader than just RFC 316=
1bis.
>>>=20
>>> I think we have many protocols, where collision resistance is not an is=
sue,
>>> where we don=B9t provide algorithm agility for all uses of SHA-1. I do th=
ink
>>> there is a use of SHA-1 in OCSP that is not part of the current update
>>> proposal and there is currently a similar discussion in TLS where stron=
g
>>> arguments are raised against adding algorithm negotiation complexity wh=
en
>>> collision resistance is not a security issue. This problem is more poli=
tical
>>> than technical. But if there is any reason to do this, it probably is f=
or
>>> political reasons, so your point is valid.
>>>=20
>>> /Stefan
>>>=20
>>> On 3/17/09 1:20 AM, "Jim Schaad" <[email-masked]> wrote:
>>> Stefan,
>>> =20
>>> First I don=B9t know that I agree.  I think that the entirety of your
>>> protection is actually given by the leading sequence/length bytes.  The
>>> object is to prevent a prefix attack.  One can create a prefix attack
>>> against the TBS bytes =AD leading to identical signatures for both versio=
ns of
>>> the certificate.  However adding the leading sequence/length octets pro=
bably
>>> means that you need to have two different prefix attacks =AD a much harde=
r
>>> condition, but maybe doable.
>>> =20
>>> However I don=B9t believe that you addressed my second point at all.  Tha=
t is
>>> people completely migrate away from SHA-1 because it is considered to b=
e
>>> broken.
>>> =20
>>> jim
>>> =20
>>>=20
>>> From: Stefan Santesson [mailto:[email-masked]]
>>> Sent: Monday, March 16, 2009 5:09 PM
>>> To: Jim Schaad; 'IETF-pkix'
>>> Subject: Re: Do we need rfc 3161bis?
>>>=20
>>> Jim,
>>>=20
>>> You ask,
>>> The question becomes can I create two certificates that can have the sa=
me
>>> hash, NOT will it happen by chance.
>>>=20
>>> I totally agree. And I don=B9t think you can.
>>>=20
>>> Not if the two certificates are signed with a good signature algorithm.
>>> If these certificates are signed with a bad signature algorithm that al=
lows
>>> different certificates to share the same signature, then all bets are o=
ff
>>> anyway.
>>>=20
>>> If the signature algorithms are good, then the signatures of these
>>> certificates will be composed of a substantial amount of vastly differe=
nt
>>> bits. As the signature algorithm is good, you can=B9t control the bits of
>>> these signatures in any meaningful way, leaving you basically with a tr=
ial
>>> and error approach. That even if SHA-1 is broken.
>>>=20
>>> /Stefan
>>>=20
>>>=20
>>> On 3/16/09 8:17 PM, "Jim Schaad" <[email-masked]> wrote:
>>> Stefan,
>>> =20
>>> The property that is being used is not the randomness property, it is a
>>> collision property.  (Or more specifically resistance to collisions.)  =
 The
>>> question becomes can I create two certificates that can have the same h=
ash,
>>> NOT will it happen by chance.   If I can do so then I have a successful
>>> attack at this point.
>>> =20
>>> However one needs to assume that if SHA-1 is significantly broken, peop=
le
>>> will be removing it from the trusted algorithm list and would then need=
 a
>>> migration path of what to put in place of the current SHA-1 attribute. =
 This
>>> is the main reason for doing the update.
>>> =20
>>> jim
>>> =20
>>>=20
>>> From: [email-masked] [mailto:[email-masked]=
] On
>>> Behalf Of Stefan Santesson
>>> Sent: Saturday, March 14, 2009 5:54 PM
>>> To: Jim Schaad; 'IETF-pkix'
>>> Subject: Re: Do we need rfc 3161bis?
>>>=20
>>> Yes, a good question indeed.
>>>=20
>>> Say that SHA-1 is completely broken in the sense that we can produce
>>> collisions at will, of all sorts and forms.
>>> Say also that we have a few valid TSA certificates issued for the same =
key
>>> pair, signed using good hash algorithms (or else all bets are off anywa=
y).
>>>=20
>>> The randomness properties of SHA-1 will remain intact even if SHA-1 is
>>> broken. This means that the risk/chance that two valid certificates, si=
gned
>>> with safe signature algorithms, will by chance produce collisions, is s=
till
>>> totally negligible.
>>>=20
>>> Where am I thinking wrong here?
>>>=20
>>> /Stefan
>>>=20
>>>=20
>>>=20
>>> On 3/14/09 8:00 PM, "Jim Schaad" <[email-masked]> wrote:
>>> Stefan,
>>> =20
>>> The question you need to be asking is =AD Do you believe that SHA-1 will =
be
>>> broken one day, and if it is broken do you want to have in place a solu=
tion
>>> to deal with it.
>>> =20
>>> Jim
>>> =20
>>> =20
>>>=20
>>> From: [email-masked] [mailto:[email-masked]=
] On
>>> Behalf Of Stefan Santesson
>>> Sent: Saturday, March 14, 2009 7:06 AM
>>> To: IETF-pkix
>>> Subject: Do we need rfc 3161bis?
>>>=20
>>> The more I look into this the more I get to doubt that we actually need
>>> 3161bis.
>>>=20
>>> The only substantial technical change I know of is to allow the updated=
 ESS
>>> certIDv2 to be used to identify the signer=B9s certificate IF the TSA for=
 some
>>> reason choose to hash its certificate with another hash then SHA-1.
>>>=20
>>> The rationale for the certID identifier is given in section 5 of RFC 26=
34
>>> and describes attacks where one valid certificate is substituted by ano=
ther
>>> valid certificate (exceopt for some DoS case that I don=B9t think is rele=
vant
>>> here).
>>> Now I have to ask myself. How likely is it that a legitimate TSA has 2 =
 or
>>> more legitimate certificates for the same public key with conflicting
>>> information (or information different enough to actually have a securit=
y
>>> impact) AND where the hash of these certificates produce a SHA-1 collis=
ion.
>>>=20
>>> This is not the previously discussed certificate collision attack using=
 weak
>>> certificate signing hash, where I may prepare a certificate request in =
a way
>>> where I can fool the CA to produce two valid certificates with the same
>>> certificate signature. If I would use that technique I would have to fi=
nd a
>>> way to prepare the TSA certificate requests, the TSA certificate hash n=
eed
>>> to be weak in addition to the certID hash AND In addition to that the
>>> complete certificates (not only the to be signed part) need to create a=
 hash
>>> collision when computing the certID.
>>>=20
>>> So, my first question is if this change addresses any real security thr=
eat?
>>> Can someone provide a reasonable threat analysis?
>>> And consequently, if there are no real threats to solve, does this upda=
te
>>> motivate the potential interoperability issues that might be the result=
 of
>>> by allowing ESS CertIDv2 in time stamp tokens?
>>>=20
>>>=20
>>> If we do come to the conclusion that it is worth it, then why not just
>>> create an update RFC updating RFC 3161 instead of replacing it?
>>>=20
>>> This update does not change any bits on the wire for implementations of=
 the
>>> current protocol. The only thing it does is to add an option to use ESS
>>> certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificate=
.
>>> This seems like a perfect thing for an update RFC. Another argument is =
that
>>> the old editors that rightfully should have the credit for RFC 3161 are=
 not
>>> part of this minor amendment but are completely erased from the update.=
 That
>>> may be reasonable if the changes are major but I=B9m not so sure in this =
case.
>>>=20

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

<HTML>
<HEAD>
<TITLE>Re: Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I had an informal face2face meeting here in Barcelona between me, Julien S=
tern and Denis Pinkas.<BR>
<BR>
I will dare myself to write down some conclusion and trust Julien and Denis=
 to correct me if they disagree.<BR>
<BR>
</SPAN></FONT><OL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=
 STYLE=3D'font-size:11pt'>There is no known threat for which the essCertIDv2 i=
s needed.
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>It is extremely hard to prove that there will not be any=
 threat or attack made up in the future where essCertIDv2 would be useful
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>As essCertIDv2 is standardized and has been a focus for =
EU work in relation to time stamps, it is probably reasonable to allow essCe=
rtIDv2 to be used with RFC 3161 time stamps.
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>For the sake of specifying the time stamp protocol, we o=
nly need one named entity representing the signer of the time stamp token (c=
urrently TSA in RFC 3161).
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>There is currently a disconnect between terminology in R=
FC 3161 and RFC 3628 (the policy document)
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>A solution that would satisfy all parties of this meetin=
g would be to write an update RFC (not a replacement as current proposal). T=
his update RFC would add the option to use essCertIDv2 AND would include an =
informational Annex &nbsp;explaining the basic difference in terminology bet=
ween RFC 3161 and RFC 3628. Most importantly this informational text would e=
xplain that TSU in the policy document corresponds to TSA in the protocol. <=
BR>
</SPAN></FONT></OL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST=
YLE=3D'font-size:11pt'><BR>
I support these conclusions.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/17/09 7:55 AM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefans@exmsf=
t.com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Exactly as Jim says. Maybe we should add further=
 that this is a bout substituting one valid TSA certificate with another val=
id TSA certificate since the TSA for some reason has two TSA certificates fo=
r the same public key which when hashed, have the same SHA-1 hash.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/17/09 6:26 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D">The attack we are looking =
at is a certificate substitution attack with the TSA certificate being chang=
ed to a different certificate. &nbsp;This is not &nbsp;question of trusting =
the TSA itself. &nbsp;Unless of course it is the one trying the attack for s=
ome reason.<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Santosh Chokhani [<a href=3D"mailto=
:[email-masked]">mailto:[email-masked]</a>] <BR>
<B>Sent:</B> Monday, March 16, 2009 9:25 PM<BR>
<B>To:</B> Stefan Santesson; Jim Schaad; IETF-pkix<BR>
<B>Subject:</B> RE: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT COLOR=3D"#0000FF"><FONT SIZE=3D"2"><FONT FACE=3D"Arial"><SPAN=
 STYLE=3D'font-size:10pt'>I have not followed the thread well. &nbsp;But, are =
we losing forest for the trees here?<BR>
</SPAN></FONT></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-=
size:12pt'> <BR>
</SPAN></FONT><FONT COLOR=3D"#0000FF"><FONT SIZE=3D"2"><FONT FACE=3D"Arial"><SPAN=
 STYLE=3D'font-size:10pt'>Do we not trust the TSA enough to not create collisi=
on attack?<BR>
</SPAN></FONT></FONT></FONT><BLOCKQUOTE><FONT FACE=3D"Times New Roman"><SPAN =
STYLE=3D'font-size:12pt'>=20
</SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12pt'><HR ALIGN=3DCENTER =
SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT>
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Monday, March 16, 2009 9:01 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:11pt'>OK,<BR>
<BR>
The prefix attack only works, as you say yourself, on the tbs bits to creat=
e two certs with the same signature. This is ONLY possible if the signature =
hash algorithm is broken. The hash in the essCertID is calculated on the com=
plete certificates (including signatures), not only the tbs bits.<BR>
Thus, the prefix attack is pretty useless if you have a large chunk of rand=
om bits in the end that is bound to be different for each cert. And they wil=
l be different IF the signature algorithm of the certificates is not broken.=
<BR>
<BR>
The second question, sorry for missing it, is broader than just RFC 3161bis=
.<BR>
<BR>
I think we have many protocols, where collision resistance is not an issue,=
 where we don&#8217;t provide algorithm agility for all uses of SHA-1. I do =
think there is a use of SHA-1 in OCSP that is not part of the current update=
 proposal and there is currently a similar discussion in TLS where strong ar=
guments are raised against adding algorithm negotiation complexity when coll=
ision resistance is not a security issue. This problem is more political tha=
n technical. But if there is any reason to do this, it probably is for polit=
ical reasons, so your point is valid.<BR>
<BR>
/Stefan<BR>
<BR>
On 3/17/09 1:20 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
First I don&#8217;t know that I agree. &nbsp;I think that the entirety of y=
our protection is actually given by the leading sequence/length bytes. &nbsp=
;The object is to prevent a prefix attack. &nbsp;One can create a prefix att=
ack against the TBS bytes &#8211; leading to identical signatures for both v=
ersions of the certificate. &nbsp;However adding the leading sequence/length=
 octets probably means that you need to have two different prefix attacks &#=
8211; a much harder condition, but maybe doable.<BR>
&nbsp;<BR>
However I don&#8217;t believe that you addressed my second point at all. &n=
bsp;That is people completely migrate away from SHA-1 because it is consider=
ed to be broken.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Stefan Santesson [<a href=3D"mailto=
:[email-masked]">mailto:[email-masked]</a>] <BR>
<B>Sent:</B> Monday, March 16, 2009 5:09 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Jim,<BR>
<BR>
You ask,<BR>
<FONT COLOR=3D"#1E487C">The question becomes can I create two certificates th=
at can have the same hash, NOT will it happen by chance.<BR>
</FONT><BR>
I <B>totally</B> agree. And I don&#8217;t think you can.<BR>
<BR>
Not if the two certificates are signed with a good signature algorithm. <BR=
If these certificates are signed with a bad signature algorithm that allows=
 different certificates to share the same signature, then all bets are off a=
nyway.<BR>
<BR>
If the signature algorithms are good, then the signatures of these certific=
ates will be composed of a substantial amount of vastly different bits. As t=
he signature algorithm is good, you can&#8217;t control the bits of these si=
gnatures in any meaningful way, leaving you basically with a trial and error=
 approach. That even if SHA-1 is broken.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The property that is being used is not the randomness property, it is a col=
lision property. &nbsp;(Or more specifically resistance to collisions.) &nbs=
p;&nbsp;The question becomes can I create two certificates that can have the=
 same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so then I =
have a successful attack at this point.<BR>
&nbsp;<BR>
However one needs to assume that if SHA-1 is significantly broken, people w=
ill be removing it from the trusted algorithm list and would then need a mig=
ration path of what to put in place of the current SHA-1 attribute. &nbsp;Th=
is is the main reason for doing the update.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 5:54 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Yes, a good question indeed.<BR>
<BR>
Say that SHA-1 is completely broken in the sense that we can produce collis=
ions at will, of all sorts and forms.<BR>
Say also that we have a few valid TSA certificates issued for the same key =
pair, signed using good hash algorithms (or else all bets are off anyway).<B=
R>
<BR>
The randomness properties of SHA-1 will remain intact even if SHA-1 is brok=
en. This means that the risk/chance that two valid certificates, signed with=
 safe signature algorithms, will by chance produce collisions, is still tota=
lly negligible.<BR>
<BR>
Where am I thinking wrong here?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The question you need to be asking is &#8211; Do you believe that SHA-1 wil=
l be broken one day, and if it is broken do you want to have in place a solu=
tion to deal with it.<BR>
&nbsp;<BR>
Jim<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 7:06 AM<BR>
<B>To:</B> IETF-pkix<BR>
<B>Subject:</B> Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>The more I look into this the more I get to doubt that we ac=
tually need 3161bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.
</SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>
</SPAN></FONT>
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
</SPAN></FONT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE>
</BODY>
</HTML>

--B_3320148603_11583013--

Date: Tue, 17 Mar 2009 07:55:03 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[email-masked]>
To: Jim Schaad <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Sender: [email-masked]

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

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

Exactly as Jim says. Maybe we should add further that this is a bout
substituting one valid TSA certificate with another valid TSA certificate
since the TSA for some reason has two TSA certificates for the same public
key which when hashed, have the same SHA-1 hash.

/Stefan

On 3/17/09 6:26 AM, "Jim Schaad" <[email-masked]> wrote:

> The attack we are looking at is a certificate substitution attack with th=
e TSA
> certificate being changed to a different certificate.  This is not  quest=
ion
> of trusting the TSA itself.  Unless of course it is the one trying the at=
tack
> for some reason.
> =20
> =20
>=20
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Monday, March 16, 2009 9:25 PM
> To: Stefan Santesson; Jim Schaad; IETF-pkix
> Subject: RE: Do we need rfc 3161bis?
> =20
> I have not followed the thread well.  But, are we losing forest for the t=
rees
> here?
> =20
> Do we not trust the TSA enough to not create collision attack?
>> =20
>>=20
>>=20
>> From: [email-masked] [mailto:[email-masked]]=
 On
>> Behalf Of Stefan Santesson
>> Sent: Monday, March 16, 2009 9:01 PM
>> To: Jim Schaad; 'IETF-pkix'
>> Subject: Re: Do we need rfc 3161bis?
>> OK,
>>=20
>> The prefix attack only works, as you say yourself, on the tbs bits to cr=
eate
>> two certs with the same signature. This is ONLY possible if the signatur=
e
>> hash algorithm is broken. The hash in the essCertID is calculated on the
>> complete certificates (including signatures), not only the tbs bits.
>> Thus, the prefix attack is pretty useless if you have a large chunk of r=
andom
>> bits in the end that is bound to be different for each cert. And they wi=
ll be
>> different IF the signature algorithm of the certificates is not broken.
>>=20
>> The second question, sorry for missing it, is broader than just RFC 3161=
bis.
>>=20
>> I think we have many protocols, where collision resistance is not an iss=
ue,
>> where we don=B9t provide algorithm agility for all uses of SHA-1. I do thi=
nk
>> there is a use of SHA-1 in OCSP that is not part of the current update
>> proposal and there is currently a similar discussion in TLS where strong
>> arguments are raised against adding algorithm negotiation complexity whe=
n
>> collision resistance is not a security issue. This problem is more polit=
ical
>> than technical. But if there is any reason to do this, it probably is fo=
r
>> political reasons, so your point is valid.
>>=20
>> /Stefan
>>=20
>> On 3/17/09 1:20 AM, "Jim Schaad" <[email-masked]> wrote:
>> Stefan,
>> =20
>> First I don=B9t know that I agree.  I think that the entirety of your
>> protection is actually given by the leading sequence/length bytes.  The
>> object is to prevent a prefix attack.  One can create a prefix attack ag=
ainst
>> the TBS bytes =AD leading to identical signatures for both versions of the
>> certificate.  However adding the leading sequence/length octets probably
>> means that you need to have two different prefix attacks =AD a much harder
>> condition, but maybe doable.
>> =20
>> However I don=B9t believe that you addressed my second point at all.  That=
 is
>> people completely migrate away from SHA-1 because it is considered to be
>> broken.
>> =20
>> jim
>> =20
>>=20
>> From: Stefan Santesson [mailto:[email-masked]]
>> Sent: Monday, March 16, 2009 5:09 PM
>> To: Jim Schaad; 'IETF-pkix'
>> Subject: Re: Do we need rfc 3161bis?
>>=20
>> Jim,
>>=20
>> You ask,
>> The question becomes can I create two certificates that can have the sam=
e
>> hash, NOT will it happen by chance.
>>=20
>> I totally agree. And I don=B9t think you can.
>>=20
>> Not if the two certificates are signed with a good signature algorithm.
>> If these certificates are signed with a bad signature algorithm that all=
ows
>> different certificates to share the same signature, then all bets are of=
f
>> anyway.
>>=20
>> If the signature algorithms are good, then the signatures of these
>> certificates will be composed of a substantial amount of vastly differen=
t
>> bits. As the signature algorithm is good, you can=B9t control the bits of =
these
>> signatures in any meaningful way, leaving you basically with a trial and
>> error approach. That even if SHA-1 is broken.
>>=20
>> /Stefan
>>=20
>>=20
>> On 3/16/09 8:17 PM, "Jim Schaad" <[email-masked]> wrote:
>> Stefan,
>> =20
>> The property that is being used is not the randomness property, it is a
>> collision property.  (Or more specifically resistance to collisions.)   =
The
>> question becomes can I create two certificates that can have the same ha=
sh,
>> NOT will it happen by chance.   If I can do so then I have a successful
>> attack at this point.
>> =20
>> However one needs to assume that if SHA-1 is significantly broken, peopl=
e
>> will be removing it from the trusted algorithm list and would then need =
a
>> migration path of what to put in place of the current SHA-1 attribute.  =
This
>> is the main reason for doing the update.
>> =20
>> jim
>> =20
>>=20
>> From: [email-masked] [mailto:[email-masked]]=
 On
>> Behalf Of Stefan Santesson
>> Sent: Saturday, March 14, 2009 5:54 PM
>> To: Jim Schaad; 'IETF-pkix'
>> Subject: Re: Do we need rfc 3161bis?
>>=20
>> Yes, a good question indeed.
>>=20
>> Say that SHA-1 is completely broken in the sense that we can produce
>> collisions at will, of all sorts and forms.
>> Say also that we have a few valid TSA certificates issued for the same k=
ey
>> pair, signed using good hash algorithms (or else all bets are off anyway=
).
>>=20
>> The randomness properties of SHA-1 will remain intact even if SHA-1 is
>> broken. This means that the risk/chance that two valid certificates, sig=
ned
>> with safe signature algorithms, will by chance produce collisions, is st=
ill
>> totally negligible.
>>=20
>> Where am I thinking wrong here?
>>=20
>> /Stefan
>>=20
>>=20
>>=20
>> On 3/14/09 8:00 PM, "Jim Schaad" <[email-masked]> wrote:
>> Stefan,
>> =20
>> The question you need to be asking is =AD Do you believe that SHA-1 will b=
e
>> broken one day, and if it is broken do you want to have in place a solut=
ion
>> to deal with it.
>> =20
>> Jim
>> =20
>> =20
>>=20
>> From: [email-masked] [mailto:[email-masked]]=
 On
>> Behalf Of Stefan Santesson
>> Sent: Saturday, March 14, 2009 7:06 AM
>> To: IETF-pkix
>> Subject: Do we need rfc 3161bis?
>>=20
>> The more I look into this the more I get to doubt that we actually need
>> 3161bis.
>>=20
>> The only substantial technical change I know of is to allow the updated =
ESS
>> certIDv2 to be used to identify the signer=B9s certificate IF the TSA for =
some
>> reason choose to hash its certificate with another hash then SHA-1.
>>=20
>> The rationale for the certID identifier is given in section 5 of RFC 263=
4 and
>> describes attacks where one valid certificate is substituted by another =
valid
>> certificate (exceopt for some DoS case that I don=B9t think is relevant he=
re).
>> Now I have to ask myself. How likely is it that a legitimate TSA has 2  =
or
>> more legitimate certificates for the same public key with conflicting
>> information (or information different enough to actually have a security
>> impact) AND where the hash of these certificates produce a SHA-1 collisi=
on.
>>=20
>> This is not the previously discussed certificate collision attack using =
weak
>> certificate signing hash, where I may prepare a certificate request in a=
 way
>> where I can fool the CA to produce two valid certificates with the same
>> certificate signature. If I would use that technique I would have to fin=
d a
>> way to prepare the TSA certificate requests, the TSA certificate hash ne=
ed to
>> be weak in addition to the certID hash AND In addition to that the compl=
ete
>> certificates (not only the to be signed part) need to create a hash coll=
ision
>> when computing the certID.
>>=20
>> So, my first question is if this change addresses any real security thre=
at?
>> Can someone provide a reasonable threat analysis?
>> And consequently, if there are no real threats to solve, does this updat=
e
>> motivate the potential interoperability issues that might be the result =
of by
>> allowing ESS CertIDv2 in time stamp tokens?
>>=20
>>=20
>> If we do come to the conclusion that it is worth it, then why not just c=
reate
>> an update RFC updating RFC 3161 instead of replacing it?
>>=20
>> This update does not change any bits on the wire for implementations of =
the
>> current protocol. The only thing it does is to add an option to use ESS
>> certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificate.
>> This seems like a perfect thing for an update RFC. Another argument is t=
hat
>> the old editors that rightfully should have the credit for RFC 3161 are =
not
>> part of this minor amendment but are completely erased from the update. =
That
>> may be reasonable if the changes are major but I=B9m not so sure in this c=
ase.
>>=20

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

<HTML>
<HEAD>
<TITLE>Re: Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Exactly as Jim says. Maybe we should add further that this is a bout subst=
ituting one valid TSA certificate with another valid TSA certificate since t=
he TSA for some reason has two TSA certificates for the same public key whic=
h when hashed, have the same SHA-1 hash.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/17/09 6:26 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D">The attack we are looking =
at is a certificate substitution attack with the TSA certificate being chang=
ed to a different certificate. &nbsp;This is not &nbsp;question of trusting =
the TSA itself. &nbsp;Unless of course it is the one trying the attack for s=
ome reason.<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Santosh Chokhani [<a href=3D"mailto=
:[email-masked]">mailto:[email-masked]</a>] <BR>
<B>Sent:</B> Monday, March 16, 2009 9:25 PM<BR>
<B>To:</B> Stefan Santesson; Jim Schaad; IETF-pkix<BR>
<B>Subject:</B> RE: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT COLOR=3D"#0000FF"><FONT SIZE=3D"2"><FONT FACE=3D"Arial"><SPAN=
 STYLE=3D'font-size:10pt'>I have not followed the thread well. &nbsp;But, are =
we losing forest for the trees here?<BR>
</SPAN></FONT></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-=
size:12pt'> <BR>
</SPAN></FONT><FONT COLOR=3D"#0000FF"><FONT SIZE=3D"2"><FONT FACE=3D"Arial"><SPAN=
 STYLE=3D'font-size:10pt'>Do we not trust the TSA enough to not create collisi=
on attack?<BR>
</SPAN></FONT></FONT></FONT><BLOCKQUOTE><FONT FACE=3D"Times New Roman"><SPAN =
STYLE=3D'font-size:12pt'>=20
</SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12pt'><HR ALIGN=3DCENTER =
SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT>
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Monday, March 16, 2009 9:01 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:11pt'>OK,<BR>
<BR>
The prefix attack only works, as you say yourself, on the tbs bits to creat=
e two certs with the same signature. This is ONLY possible if the signature =
hash algorithm is broken. The hash in the essCertID is calculated on the com=
plete certificates (including signatures), not only the tbs bits.<BR>
Thus, the prefix attack is pretty useless if you have a large chunk of rand=
om bits in the end that is bound to be different for each cert. And they wil=
l be different IF the signature algorithm of the certificates is not broken.=
<BR>
<BR>
The second question, sorry for missing it, is broader than just RFC 3161bis=
.<BR>
<BR>
I think we have many protocols, where collision resistance is not an issue,=
 where we don&#8217;t provide algorithm agility for all uses of SHA-1. I do =
think there is a use of SHA-1 in OCSP that is not part of the current update=
 proposal and there is currently a similar discussion in TLS where strong ar=
guments are raised against adding algorithm negotiation complexity when coll=
ision resistance is not a security issue. This problem is more political tha=
n technical. But if there is any reason to do this, it probably is for polit=
ical reasons, so your point is valid.<BR>
<BR>
/Stefan<BR>
<BR>
On 3/17/09 1:20 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
First I don&#8217;t know that I agree. &nbsp;I think that the entirety of y=
our protection is actually given by the leading sequence/length bytes. &nbsp=
;The object is to prevent a prefix attack. &nbsp;One can create a prefix att=
ack against the TBS bytes &#8211; leading to identical signatures for both v=
ersions of the certificate. &nbsp;However adding the leading sequence/length=
 octets probably means that you need to have two different prefix attacks &#=
8211; a much harder condition, but maybe doable.<BR>
&nbsp;<BR>
However I don&#8217;t believe that you addressed my second point at all. &n=
bsp;That is people completely migrate away from SHA-1 because it is consider=
ed to be broken.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Stefan Santesson [<a href=3D"mailto=
:[email-masked]">mailto:[email-masked]</a>] <BR>
<B>Sent:</B> Monday, March 16, 2009 5:09 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Jim,<BR>
<BR>
You ask,<BR>
<FONT COLOR=3D"#1E487C">The question becomes can I create two certificates th=
at can have the same hash, NOT will it happen by chance.<BR>
</FONT><BR>
I <B>totally</B> agree. And I don&#8217;t think you can.<BR>
<BR>
Not if the two certificates are signed with a good signature algorithm. <BR=
If these certificates are signed with a bad signature algorithm that allows=
 different certificates to share the same signature, then all bets are off a=
nyway.<BR>
<BR>
If the signature algorithms are good, then the signatures of these certific=
ates will be composed of a substantial amount of vastly different bits. As t=
he signature algorithm is good, you can&#8217;t control the bits of these si=
gnatures in any meaningful way, leaving you basically with a trial and error=
 approach. That even if SHA-1 is broken.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The property that is being used is not the randomness property, it is a col=
lision property. &nbsp;(Or more specifically resistance to collisions.) &nbs=
p;&nbsp;The question becomes can I create two certificates that can have the=
 same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so then I =
have a successful attack at this point.<BR>
&nbsp;<BR>
However one needs to assume that if SHA-1 is significantly broken, people w=
ill be removing it from the trusted algorithm list and would then need a mig=
ration path of what to put in place of the current SHA-1 attribute. &nbsp;Th=
is is the main reason for doing the update.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 5:54 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Yes, a good question indeed.<BR>
<BR>
Say that SHA-1 is completely broken in the sense that we can produce collis=
ions at will, of all sorts and forms.<BR>
Say also that we have a few valid TSA certificates issued for the same key =
pair, signed using good hash algorithms (or else all bets are off anyway).<B=
R>
<BR>
The randomness properties of SHA-1 will remain intact even if SHA-1 is brok=
en. This means that the risk/chance that two valid certificates, signed with=
 safe signature algorithms, will by chance produce collisions, is still tota=
lly negligible.<BR>
<BR>
Where am I thinking wrong here?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The question you need to be asking is &#8211; Do you believe that SHA-1 wil=
l be broken one day, and if it is broken do you want to have in place a solu=
tion to deal with it.<BR>
&nbsp;<BR>
Jim<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 7:06 AM<BR>
<B>To:</B> IETF-pkix<BR>
<B>Subject:</B> Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>The more I look into this the more I get to doubt that we ac=
tually need 3161bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3320121305_10619757--

From: "Jim Schaad" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Subject: RE: Do we need rfc 3161bis?
Date: Mon, 16 Mar 2009 22:26:43 -0700
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_0151_01C9A686.4975B890
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The attack we are looking at is a certificate substitution attack with the
TSA certificate being changed to a different certificate.  This is not
question of trusting the TSA itself.  Unless of course it is the one trying
the attack for some reason.

From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Monday, March 16, 2009 9:25 PM
To: Stefan Santesson; Jim Schaad; IETF-pkix
Subject: RE: Do we need rfc 3161bis?

I have not followed the thread well.  But, are we losing forest for the
trees here?

Do we not trust the TSA enough to not create collision attack?

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Monday, March 16, 2009 9:01 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?

OK,

The prefix attack only works, as you say yourself, on the tbs bits to create
two certs with the same signature. This is ONLY possible if the signature
hash algorithm is broken. The hash in the essCertID is calculated on the
complete certificates (including signatures), not only the tbs bits.
Thus, the prefix attack is pretty useless if you have a large chunk of
random bits in the end that is bound to be different for each cert. And they
will be different IF the signature algorithm of the certificates is not
broken.

The second question, sorry for missing it, is broader than just RFC 3161bis.

I think we have many protocols, where collision resistance is not an issue,
where we don't provide algorithm agility for all uses of SHA-1. I do think
there is a use of SHA-1 in OCSP that is not part of the current update
proposal and there is currently a similar discussion in TLS where strong
arguments are raised against adding algorithm negotiation complexity when
collision resistance is not a security issue. This problem is more political
than technical. But if there is any reason to do this, it probably is for
political reasons, so your point is valid.

/Stefan

On 3/17/09 1:20 AM, "Jim Schaad" <[email-masked]> wrote:

Stefan,
 
First I don't know that I agree.  I think that the entirety of your
protection is actually given by the leading sequence/length bytes.  The
object is to prevent a prefix attack.  One can create a prefix attack
against the TBS bytes - leading to identical signatures for both versions of
the certificate.  However adding the leading sequence/length octets probably
means that you need to have two different prefix attacks - a much harder
condition, but maybe doable.
 
However I don't believe that you addressed my second point at all.  That is
people completely migrate away from SHA-1 because it is considered to be
broken.
 
jim

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Monday, March 16, 2009 5:09 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?

Jim,

You ask,
The question becomes can I create two certificates that can have the same
hash, NOT will it happen by chance.

I totally agree. And I don't think you can.

Not if the two certificates are signed with a good signature algorithm. 
If these certificates are signed with a bad signature algorithm that allows
different certificates to share the same signature, then all bets are off
anyway.

If the signature algorithms are good, then the signatures of these
certificates will be composed of a substantial amount of vastly different
bits. As the signature algorithm is good, you can't control the bits of
these signatures in any meaningful way, leaving you basically with a trial
and error approach. That even if SHA-1 is broken.

/Stefan

On 3/16/09 8:17 PM, "Jim Schaad" <[email-masked]> wrote:
Stefan,
 
The property that is being used is not the randomness property, it is a
collision property.  (Or more specifically resistance to collisions.)   The
question becomes can I create two certificates that can have the same hash,
NOT will it happen by chance.   If I can do so then I have a successful
attack at this point.
 
However one needs to assume that if SHA-1 is significantly broken, people
will be removing it from the trusted algorithm list and would then need a
migration path of what to put in place of the current SHA-1 attribute.  This
is the main reason for doing the update.
 
jim

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 5:54 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?

Yes, a good question indeed.

Say that SHA-1 is completely broken in the sense that we can produce
collisions at will, of all sorts and forms.
Say also that we have a few valid TSA certificates issued for the same key
pair, signed using good hash algorithms (or else all bets are off anyway).

The randomness properties of SHA-1 will remain intact even if SHA-1 is
broken. This means that the risk/chance that two valid certificates, signed
with safe signature algorithms, will by chance produce collisions, is still
totally negligible.

Where am I thinking wrong here?

/Stefan

On 3/14/09 8:00 PM, "Jim Schaad" <[email-masked]> wrote:
Stefan,
 
The question you need to be asking is - Do you believe that SHA-1 will be
broken one day, and if it is broken do you want to have in place a solution
to deal with it.
 
Jim

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 7:06 AM
To: IETF-pkix
Subject: Do we need rfc 3161bis?

The more I look into this the more I get to doubt that we actually need
3161bis.

The only substantial technical change I know of is to allow the updated ESS
certIDv2 to be used to identify the signer's certificate IF the TSA for some
reason choose to hash its certificate with another hash then SHA-1.

The rationale for the certID identifier is given in section 5 of RFC 2634
and describes attacks where one valid certificate is substituted by another
valid certificate (exceopt for some DoS case that I don't think is relevant
here).
Now I have to ask myself. How likely is it that a legitimate TSA has 2  or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 collision.

This is not the previously discussed certificate collision attack using weak
certificate signing hash, where I may prepare a certificate request in a way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to find a
way to prepare the TSA certificate requests, the TSA certificate hash need
to be weak in addition to the certID hash AND In addition to that the
complete certificates (not only the to be signed part) need to create a hash
collision when computing the certID.

So, my first question is if this change addresses any real security threat?
Can someone provide a reasonable threat analysis?
And consequently, if there are no real threats to solve, does this update
motivate the potential interoperability issues that might be the result of
by allowing ESS CertIDv2 in time stamp tokens?

If we do come to the conclusion that it is worth it, then why not just
create an update RFC updating RFC 3161 instead of replacing it?

This update does not change any bits on the wire for implementations of the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA's certificate.
This seems like a perfect thing for an update RFC. Another argument is that
the old editors that rightfully should have the credit for RFC 3161 are not
part of this minor amendment but are completely erased from the update. That
may be reasonable if the changes are major but I'm not so sure in this case.

------=_NextPart_000_0151_01C9A686.4975B890
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: Do we need rfc 3161bis?</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The attack we are looking at is a certificate =
substitution attack
with the TSA certificate being changed to a different certificate.&nbsp; =
This is
not&nbsp; question of trusting the TSA itself.&nbsp; Unless of course it =
is the one
trying the attack for some reason.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Santosh =
Chokhani
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, March 16, 2009 9:25 PM<br>
<b>To:</b> Stefan Santesson; Jim Schaad; IETF-pkix<br>
<b>Subject:</b> RE: Do we need rfc 3161bis?<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>I have not followed the thread well.&nbsp; But, are we =
losing
forest for the trees here?</span><o:p></o:p></p>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Do we not trust the TSA enough to not create collision =
attack?</span><o:p></o:p></p>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

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

</div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Stefan =
Santesson<br>
<b>Sent:</b> Monday, March 16, 2009 9:01 PM<br>
<b>To:</b> Jim Schaad; 'IETF-pkix'<br>
<b>Subject:</b> Re: Do we need rfc 3161bis?</span><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>OK,<br>
<br>
The prefix attack only works, as you say yourself, on the tbs bits to =
create
two certs with the same signature. This is ONLY possible if the =
signature hash
algorithm is broken. The hash in the essCertID is calculated on the =
complete
certificates (including signatures), not only the tbs bits.<br>
Thus, the prefix attack is pretty useless if you have a large chunk of =
random
bits in the end that is bound to be different for each cert. And they =
will be
different IF the signature algorithm of the certificates is not =
broken.<br>
<br>
The second question, sorry for missing it, is broader than just RFC =
3161bis.<br>
<br>
I think we have many protocols, where collision resistance is not an =
issue,
where we don&#8217;t provide algorithm agility for all uses of SHA-1. I =
do think
there is a use of SHA-1 in OCSP that is not part of the current update =
proposal
and there is currently a similar discussion in TLS where strong =
arguments are
raised against adding algorithm negotiation complexity when collision
resistance is not a security issue. This problem is more political than
technical. But if there is any reason to do this, it probably is for =
political
reasons, so your point is valid.<br>
<br>
/Stefan<br>
<br>
On 3/17/09 1:20 AM, &quot;Jim Schaad&quot; &lt;<a =
href=3D"[email-masked]">[email-masked]</a>&gt;
wrote:</span><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Stefan,<br>
&nbsp;<br>
First I don&#8217;t know that I agree. &nbsp;I think that the entirety =
of your
protection is actually given by the leading sequence/length bytes. =
&nbsp;The
object is to prevent a prefix attack. &nbsp;One can create a prefix =
attack
against the TBS bytes &#8211; leading to identical signatures for both =
versions of
the certificate. &nbsp;However adding the leading sequence/length octets
probably means that you need to have two different prefix attacks =
&#8211; a much
harder condition, but maybe doable.<br>
&nbsp;<br>
However I don&#8217;t believe that you addressed my second point at all. =
&nbsp;That
is people completely migrate away from SHA-1 because it is considered to =
be
broken.<br>
&nbsp;<br>
jim<br>
&nbsp;<br>
</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Stefan =
Santesson [<a
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>] <br>
<b>Sent:</b> Monday, March 16, 2009 5:09 PM<br>
<b>To:</b> Jim Schaad; 'IETF-pkix'<br>
<b>Subject:</b> Re: Do we need rfc 3161bis?<br>
</span><br>
<span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Jim,<br>
<br>
You ask,<br>
<span style=3D'color:#1E487C'>The question becomes can I create two =
certificates
that can have the same hash, NOT will it happen by chance.<br>
</span><br>
I <b>totally</b> agree. And I don&#8217;t think you can.<br>
<br>
Not if the two certificates are signed with a good signature algorithm. =
<br>
If these certificates are signed with a bad signature algorithm that =
allows
different certificates to share the same signature, then all bets are =
off
anyway.<br>
<br>
If the signature algorithms are good, then the signatures of these =
certificates
will be composed of a substantial amount of vastly different bits. As =
the
signature algorithm is good, you can&#8217;t control the bits of these =
signatures in
any meaningful way, leaving you basically with a trial and error =
approach. That
even if SHA-1 is broken.<br>
<br>
/Stefan<br>
<br>
<br>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a =
href=3D"[email-masked]">[email-masked]</a>&gt;
wrote:<br>
<span style=3D'color:#1F497D'>Stefan,<br>
&nbsp;<br>
The property that is being used is not the randomness property, it is a
collision property. &nbsp;(Or more specifically resistance to =
collisions.)
&nbsp;&nbsp;The question becomes can I create two certificates that can =
have
the same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so =
then I
have a successful attack at this point.<br>
&nbsp;<br>
However one needs to assume that if SHA-1 is significantly broken, =
people will
be removing it from the trusted algorithm list and would then need a =
migration
path of what to put in place of the current SHA-1 attribute. &nbsp;This =
is the
main reason for doing the update.<br>
&nbsp;<br>
jim<br>
&nbsp;<br>
</span><br>
</span><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a
href=3D"[email-masked]">[email-masked]</a> =
[<a
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
<b>On Behalf Of </b>Stefan Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 5:54 PM<br>
<b>To:</b> Jim Schaad; 'IETF-pkix'<br>
<b>Subject:</b> Re: Do we need rfc 3161bis?<br>
</span><br>
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Yes, =
a good
question indeed.<br>
<br>
Say that SHA-1 is completely broken in the sense that we can produce =
collisions
at will, of all sorts and forms.<br>
Say also that we have a few valid TSA certificates issued for the same =
key
pair, signed using good hash algorithms (or else all bets are off =
anyway).<br>
<br>
The randomness properties of SHA-1 will remain intact even if SHA-1 is =
broken.
This means that the risk/chance that two valid certificates, signed with =
safe
signature algorithms, will by chance produce collisions, is still =
totally
negligible.<br>
<br>
Where am I thinking wrong here?<br>
<br>
/Stefan<br>
<br>
<br>
<br>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a =
href=3D"[email-masked]">[email-masked]</a>&gt;
wrote:<br>
<span style=3D'color:#1F497D'>Stefan,<br>
&nbsp;<br>
The question you need to be asking is &#8211; Do you believe that SHA-1 =
will be
broken one day, and if it is broken do you want to have in place a =
solution to
deal with it.<br>
&nbsp;<br>
Jim<br>
&nbsp;<br>
&nbsp;<br>
</span><br>
</span><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a
href=3D"[email-masked]">[email-masked]</a> =
[<a
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
<b>On Behalf Of </b>Stefan Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 7:06 AM<br>
<b>To:</b> IETF-pkix<br>
<b>Subject:</b> Do we need rfc 3161bis?<br>
</span><br>
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>The =
more I
look into this the more I get to doubt that we actually need =
3161bis.<br>
<br>
The only substantial technical change I know of is to allow the updated =
ESS
certIDv2 to be used to identify the signer&#8217;s certificate IF the =
TSA for some
reason choose to hash its certificate with another hash then SHA-1.<br>
<br>
The rationale for the certID identifier is given in section 5 of RFC =
2634 and
describes attacks where one valid certificate is substituted by another =
valid
certificate (exceopt for some DoS case that I don&#8217;t think is =
relevant here).<br>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 =
&nbsp;or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 =
collision.<br>
<br>
This is not the previously discussed certificate collision attack using =
weak
certificate signing hash, where I may prepare a certificate request in a =
way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to =
find a way
to prepare the TSA certificate requests, the TSA certificate hash need =
to be
weak in addition to the certID hash AND In addition to that the complete
certificates (not only the to be signed part) need to create a hash =
collision
when computing the certID.<br>
<br>
So, my first question is if this change addresses any real security =
threat?<br>
Can someone provide a reasonable threat analysis?<br>
And consequently, if there are no real threats to solve, does this =
update
motivate the potential interoperability issues that might be the result =
of by
allowing ESS CertIDv2 in time stamp tokens?<br>
<br>
<br>
If we do come to the conclusion that it is worth it, then why not just =
create
an update RFC updating RFC 3161 instead of replacing it?<br>
<br>
This update does not change any bits on the wire for implementations of =
the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s =
certificate.<br>
This seems like a perfect thing for an update RFC. Another argument is =
that the
old editors that rightfully should have the credit for RFC 3161 are not =
part of
this minor amendment but are completely erased from the update. That may =
be
reasonable if the changes are major but I&#8217;m not so sure in this =
case.</span><o:p></o:p></p>

</blockquote>

</div>

</div>

</body>

</html>

------=_NextPart_000_0151_01C9A686.4975B890--

Content-class: urn:content-classes:message
Subject: RE: Do we need rfc 3161bis?
Date: Tue, 17 Mar 2009 00:24:50 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Jim Schaad" <[email-masked]>, "IETF-pkix" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A6B8.50F52E87
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have not followed the thread well.  But, are we losing forest for the
trees here?
=20
Do we not trust the TSA enough to not create collision attack?

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
	Sent: Monday, March 16, 2009 9:01 PM
	To: Jim Schaad; 'IETF-pkix'
	Subject: Re: Do we need rfc 3161bis?
=09
=09
	OK,
=09
	The prefix attack only works, as you say yourself, on the tbs
bits to create two certs with the same signature. This is ONLY possible
if the signature hash algorithm is broken. The hash in the essCertID is
calculated on the complete certificates (including signatures), not only
the tbs bits.
	Thus, the prefix attack is pretty useless if you have a large
chunk of random bits in the end that is bound to be different for each
cert. And they will be different IF the signature algorithm of the
certificates is not broken.
=09
	The second question, sorry for missing it, is broader than just
RFC 3161bis.
=09
	I think we have many protocols, where collision resistance is
not an issue, where we don't provide algorithm agility for all uses of
SHA-1. I do think there is a use of SHA-1 in OCSP that is not part of
the current update proposal and there is currently a similar discussion
in TLS where strong arguments are raised against adding algorithm
negotiation complexity when collision resistance is not a security
issue. This problem is more political than technical. But if there is
any reason to do this, it probably is for political reasons, so your
point is valid.
=09
	/Stefan
=09
	On 3/17/09 1:20 AM, "Jim Schaad" <[email-masked]> wrote:
=09
=09

		Stefan,
		=20
		First I don't know that I agree.  I think that the
entirety of your protection is actually given by the leading
sequence/length bytes.  The object is to prevent a prefix attack.  One
can create a prefix attack against the TBS bytes - leading to identical
signatures for both versions of the certificate.  However adding the
leading sequence/length octets probably means that you need to have two
different prefix attacks - a much harder condition, but maybe doable.
		=20
		However I don't believe that you addressed my second
point at all.  That is people completely migrate away from SHA-1 because
it is considered to be broken.
		=20
		jim
		=20
	=09
		From: Stefan Santesson [mailto:[email-masked]]=20
		Sent: Monday, March 16, 2009 5:09 PM
		To: Jim Schaad; 'IETF-pkix'
		Subject: Re: Do we need rfc 3161bis?
	=09
		Jim,
	=09
		You ask,
		The question becomes can I create two certificates that
can have the same hash, NOT will it happen by chance.
	=09
		I totally agree. And I don't think you can.
	=09
		Not if the two certificates are signed with a good
signature algorithm.=20
		If these certificates are signed with a bad signature
algorithm that allows different certificates to share the same
signature, then all bets are off anyway.
	=09
		If the signature algorithms are good, then the
signatures of these certificates will be composed of a substantial
amount of vastly different bits. As the signature algorithm is good, you
can't control the bits of these signatures in any meaningful way,
leaving you basically with a trial and error approach. That even if
SHA-1 is broken.
	=09
		/Stefan
	=09
	=09
		On 3/16/09 8:17 PM, "Jim Schaad"
<[email-masked]> wrote:
		Stefan,
		=20
		The property that is being used is not the randomness
property, it is a collision property.  (Or more specifically resistance
to collisions.)   The question becomes can I create two certificates
that can have the same hash, NOT will it happen by chance.   If I can do
so then I have a successful attack at this point.
		=20
		However one needs to assume that if SHA-1 is
significantly broken, people will be removing it from the trusted
algorithm list and would then need a migration path of what to put in
place of the current SHA-1 attribute.  This is the main reason for doing
the update.
		=20
		jim
		=20
	=09
		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
		Sent: Saturday, March 14, 2009 5:54 PM
		To: Jim Schaad; 'IETF-pkix'
		Subject: Re: Do we need rfc 3161bis?
	=09
		Yes, a good question indeed.
	=09
		Say that SHA-1 is completely broken in the sense that we
can produce collisions at will, of all sorts and forms.
		Say also that we have a few valid TSA certificates
issued for the same key pair, signed using good hash algorithms (or else
all bets are off anyway).
	=09
		The randomness properties of SHA-1 will remain intact
even if SHA-1 is broken. This means that the risk/chance that two valid
certificates, signed with safe signature algorithms, will by chance
produce collisions, is still totally negligible.
	=09
		Where am I thinking wrong here?
	=09
		/Stefan
	=09
	=09
	=09
		On 3/14/09 8:00 PM, "Jim Schaad"
<[email-masked]> wrote:
		Stefan,
		=20
		The question you need to be asking is - Do you believe
that SHA-1 will be broken one day, and if it is broken do you want to
have in place a solution to deal with it.
		=20
		Jim
		=20
		=20
	=09
		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
		Sent: Saturday, March 14, 2009 7:06 AM
		To: IETF-pkix
		Subject: Do we need rfc 3161bis?
	=09
		The more I look into this the more I get to doubt that
we actually need 3161bis.
	=09
		The only substantial technical change I know of is to
allow the updated ESS certIDv2 to be used to identify the signer's
certificate IF the TSA for some reason choose to hash its certificate
with another hash then SHA-1.
	=09
		The rationale for the certID identifier is given in
section 5 of RFC 2634 and describes attacks where one valid certificate
is substituted by another valid certificate (exceopt for some DoS case
that I don't think is relevant here).
		Now I have to ask myself. How likely is it that a
legitimate TSA has 2  or more legitimate certificates for the same
public key with conflicting information (or information different enough
to actually have a security impact) AND where the hash of these
certificates produce a SHA-1 collision.
	=09
		This is not the previously discussed certificate
collision attack using weak certificate signing hash, where I may
prepare a certificate request in a way where I can fool the CA to
produce two valid certificates with the same certificate signature. If I
would use that technique I would have to find a way to prepare the TSA
certificate requests, the TSA certificate hash need to be weak in
addition to the certID hash AND In addition to that the complete
certificates (not only the to be signed part) need to create a hash
collision when computing the certID.
	=09
		So, my first question is if this change addresses any
real security threat?
		Can someone provide a reasonable threat analysis?
		And consequently, if there are no real threats to solve,
does this update motivate the potential interoperability issues that
might be the result of by allowing ESS CertIDv2 in time stamp tokens?
	=09
	=09
		If we do come to the conclusion that it is worth it,
then why not just create an update RFC updating RFC 3161 instead of
replacing it?
	=09
		This update does not change any bits on the wire for
implementations of the current protocol. The only thing it does is to
add an option to use ESS certIDv2 IF SHA-1 is not used as hash to
identify the TSA's certificate.
		This seems like a perfect thing for an update RFC.
Another argument is that the old editors that rightfully should have the
credit for RFC 3161 are not part of this minor amendment but are
completely erased from the update. That may be reasonable if the changes
are major but I'm not so sure in this case.
	=09
	=09

------_=_NextPart_001_01C9A6B8.50F52E87
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: Do we need rfc 3161bis?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16809" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D252232304-17032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I have not followed the thread well.&nbsp; But, =
are we=20
losing forest for the trees here?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D252232304-17032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D252232304-17032009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Do we not trust the TSA enough to not create =
collision=20
attack?</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =

  [mailto:[email-masked]] <B>On Behalf Of </B>Stefan=20
  Santesson<BR><B>Sent:</B> Monday, March 16, 2009 9:01 PM<BR><B>To:</B> =
Jim=20
  Schaad; 'IETF-pkix'<BR><B>Subject:</B> Re: Do we need rfc=20
  3161bis?<BR></FONT><BR></DIV>
  <DIV></DIV><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20
  style=3D"FONT-SIZE: 11pt">OK,<BR><BR>The prefix attack only works, as =
you say=20
  yourself, on the tbs bits to create two certs with the same signature. =
This is=20
  ONLY possible if the signature hash algorithm is broken. The hash in =
the=20
  essCertID is calculated on the complete certificates (including =
signatures),=20
  not only the tbs bits.<BR>Thus, the prefix attack is pretty useless if =
you=20
  have a large chunk of random bits in the end that is bound to be =
different for=20
  each cert. And they will be different IF the signature algorithm of =
the=20
  certificates is not broken.<BR><BR>The second question, sorry for =
missing it,=20
  is broader than just RFC 3161bis.<BR><BR>I think we have many =
protocols, where=20
  collision resistance is not an issue, where we don&#8217;t provide =
algorithm agility=20
  for all uses of SHA-1. I do think there is a use of SHA-1 in OCSP that =
is not=20
  part of the current update proposal and there is currently a similar=20
  discussion in TLS where strong arguments are raised against adding =
algorithm=20
  negotiation complexity when collision resistance is not a security =
issue. This=20
  problem is more political than technical. But if there is any reason =
to do=20
  this, it probably is for political reasons, so your point is=20
  valid.<BR><BR>/Stefan<BR><BR>On 3/17/09 1:20 AM, "Jim Schaad" &lt;<A=20
  href=3D"[email-masked]">[email-masked]</A>&gt;=20
  wrote:<BR><BR></SPAN></FONT>
  <BLOCKQUOTE><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 11pt"><FONT =
color=3D#1f497d>Stefan,<BR>&nbsp;<BR>First I=20
    don&#8217;t know that I agree. &nbsp;I think that the entirety of =
your protection=20
    is actually given by the leading sequence/length bytes. &nbsp;The =
object is=20
    to prevent a prefix attack. &nbsp;One can create a prefix attack =
against the=20
    TBS bytes &#8211; leading to identical signatures for both versions =
of the=20
    certificate. &nbsp;However adding the leading sequence/length octets =

    probably means that you need to have two different prefix attacks =
&#8211; a much=20
    harder condition, but maybe doable.<BR>&nbsp;<BR>However I =
don&#8217;t believe=20
    that you addressed my second point at all. &nbsp;That is people =
completely=20
    migrate away from SHA-1 because it is considered to be=20
    broken.<BR>&nbsp;<BR>jim<BR>&nbsp;<BR></FONT><BR></SPAN></FONT><FONT =

    size=3D2><FONT face=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 10pt"><B>From:</B> Stefan Santesson [<A=20
    href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]=20
    <BR><B>Sent:</B> Monday, March 16, 2009 5:09 PM<BR><B>To:</B> Jim =
Schaad;=20
    'IETF-pkix'<BR><B>Subject:</B> Re: Do we need rfc=20
    3161bis?<BR></SPAN></FONT></FONT><FONT face=3D"Times New =
Roman"><SPAN=20
    style=3D"FONT-SIZE: 12pt"><BR></SPAN></FONT><FONT=20
    face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 11pt">Jim,<BR><BR>You ask,<BR><FONT =
color=3D#1e487c>The=20
    question becomes can I create two certificates that can have the =
same hash,=20
    NOT will it happen by chance.<BR></FONT><BR>I <B>totally</B> agree. =
And I=20
    don&#8217;t think you can.<BR><BR>Not if the two certificates are =
signed with a=20
    good signature algorithm. <BR>If these certificates are signed with =
a bad=20
    signature algorithm that allows different certificates to share the =
same=20
    signature, then all bets are off anyway.<BR><BR>If the signature =
algorithms=20
    are good, then the signatures of these certificates will be composed =
of a=20
    substantial amount of vastly different bits. As the signature =
algorithm is=20
    good, you can&#8217;t control the bits of these signatures in any =
meaningful way,=20
    leaving you basically with a trial and error approach. That even if =
SHA-1 is=20
    broken.<BR><BR>/Stefan<BR><BR><BR>On 3/16/09 8:17 PM, "Jim Schaad" =
&lt;<A=20
    href=3D"[email-masked]">[email-masked]</A>&gt; =
wrote:<BR><FONT=20
    color=3D#1f497d>Stefan,<BR>&nbsp;<BR>The property that is being used =
is not=20
    the randomness property, it is a collision property. &nbsp;(Or more=20
    specifically resistance to collisions.) &nbsp;&nbsp;The question =
becomes can=20
    I create two certificates that can have the same hash, NOT will it =
happen by=20
    chance. &nbsp;&nbsp;If I can do so then I have a successful attack =
at this=20
    point.<BR>&nbsp;<BR>However one needs to assume that if SHA-1 is=20
    significantly broken, people will be removing it from the trusted =
algorithm=20
    list and would then need a migration path of what to put in place of =
the=20
    current SHA-1 attribute. &nbsp;This is the main reason for doing the =

    update.<BR>&nbsp;<BR>jim<BR>&nbsp;<BR></FONT><BR></SPAN></FONT><FONT =

    size=3D2><FONT face=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 10pt"><B>From:</B> <A=20
    =
href=3D"[email-masked]">[email-masked]</A> =
[<A=20
    =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]=20
    <B>On Behalf Of </B>Stefan Santesson<BR><B>Sent:</B> Saturday, March =
14,=20
    2009 5:54 PM<BR><B>To:</B> Jim Schaad; =
'IETF-pkix'<BR><B>Subject:</B> Re: Do=20
    we need rfc 3161bis?<BR></SPAN></FONT></FONT><FONT=20
    face=3D"Times New Roman"><SPAN style=3D"FONT-SIZE: =
12pt"><BR></SPAN></FONT><FONT=20
    face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
style=3D"FONT-SIZE: 11pt">Yes,=20
    a good question indeed.<BR><BR>Say that SHA-1 is completely broken =
in the=20
    sense that we can produce collisions at will, of all sorts and =
forms.<BR>Say=20
    also that we have a few valid TSA certificates issued for the same =
key pair,=20
    signed using good hash algorithms (or else all bets are off=20
    anyway).<BR><BR>The randomness properties of SHA-1 will remain =
intact even=20
    if SHA-1 is broken. This means that the risk/chance that two valid=20
    certificates, signed with safe signature algorithms, will by chance =
produce=20
    collisions, is still totally negligible.<BR><BR>Where am I thinking =
wrong=20
    here?<BR><BR>/Stefan<BR><BR><BR><BR>On 3/14/09 8:00 PM, "Jim Schaad" =
&lt;<A=20
    href=3D"[email-masked]">[email-masked]</A>&gt; =
wrote:<BR><FONT=20
    color=3D#1f497d>Stefan,<BR>&nbsp;<BR>The question you need to be =
asking is &#8211;=20
    Do you believe that SHA-1 will be broken one day, and if it is =
broken do you=20
    want to have in place a solution to deal with=20
    =
it.<BR>&nbsp;<BR>Jim<BR>&nbsp;<BR>&nbsp;<BR></FONT><BR></SPAN></FONT><FON=
T=20
    size=3D2><FONT face=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 10pt"><B>From:</B> <A=20
    =
href=3D"[email-masked]">[email-masked]</A> =
[<A=20
    =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]=20
    <B>On Behalf Of </B>Stefan Santesson<BR><B>Sent:</B> Saturday, March =
14,=20
    2009 7:06 AM<BR><B>To:</B> IETF-pkix<BR><B>Subject:</B> Do we need =
rfc=20
    3161bis?<BR></SPAN></FONT></FONT><FONT face=3D"Times New =
Roman"><SPAN=20
    style=3D"FONT-SIZE: 12pt"><BR></SPAN></FONT><FONT=20
    face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
style=3D"FONT-SIZE: 11pt">The=20
    more I look into this the more I get to doubt that we actually need=20
    3161bis.<BR><BR>The only substantial technical change I know of is =
to allow=20
    the updated ESS certIDv2 to be used to identify the signer&#8217;s =
certificate IF=20
    the TSA for some reason choose to hash its certificate with another =
hash=20
    then SHA-1.<BR><BR>The rationale for the certID identifier is given =
in=20
    section 5 of RFC 2634 and describes attacks where one valid =
certificate is=20
    substituted by another valid certificate (exceopt for some DoS case =
that I=20
    don&#8217;t think is relevant here).<BR>Now I have to ask myself. =
How likely is it=20
    that a legitimate TSA has 2 &nbsp;or more legitimate certificates =
for the=20
    same public key with conflicting information (or information =
different=20
    enough to actually have a security impact) AND where the hash of =
these=20
    certificates produce a SHA-1 collision.<BR><BR>This is not the =
previously=20
    discussed certificate collision attack using weak certificate =
signing hash,=20
    where I may prepare a certificate request in a way where I can fool =
the CA=20
    to produce two valid certificates with the same certificate =
signature. If I=20
    would use that technique I would have to find a way to prepare the =
TSA=20
    certificate requests, the TSA certificate hash need to be weak in =
addition=20
    to the certID hash AND In addition to that the complete certificates =
(not=20
    only the to be signed part) need to create a hash collision when =
computing=20
    the certID.<BR><BR>So, my first question is if this change addresses =
any=20
    real security threat?<BR>Can someone provide a reasonable threat=20
    analysis?<BR>And consequently, if there are no real threats to =
solve, does=20
    this update motivate the potential interoperability issues that =
might be the=20
    result of by allowing ESS CertIDv2 in time stamp =
tokens?<BR><BR><BR>If we do=20
    come to the conclusion that it is worth it, then why not just create =
an=20
    update RFC updating RFC 3161 instead of replacing it?<BR><BR>This =
update=20
    does not change any bits on the wire for implementations of the =
current=20
    protocol. The only thing it does is to add an option to use ESS =
certIDv2 IF=20
    SHA-1 is not used as hash to identify the TSA&#8217;s =
certificate.<BR>This seems=20
    like a perfect thing for an update RFC. Another argument is that the =
old=20
    editors that rightfully should have the credit for RFC 3161 are not =
part of=20
    this minor amendment but are completely erased from the update. That =
may be=20
    reasonable if the changes are major but I&#8217;m not so sure in =
this=20
    case.<BR><BR></SPAN></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C9A6B8.50F52E87--

Date: Tue, 17 Mar 2009 02:00:30 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[email-masked]>
To: Jim Schaad <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Sender: [email-masked]

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

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

OK,

The prefix attack only works, as you say yourself, on the tbs bits to creat=
e
two certs with the same signature. This is ONLY possible if the signature
hash algorithm is broken. The hash in the essCertID is calculated on the
complete certificates (including signatures), not only the tbs bits.
Thus, the prefix attack is pretty useless if you have a large chunk of
random bits in the end that is bound to be different for each cert. And the=
y
will be different IF the signature algorithm of the certificates is not
broken.

The second question, sorry for missing it, is broader than just RFC 3161bis=
.

I think we have many protocols, where collision resistance is not an issue,
where we don=B9t provide algorithm agility for all uses of SHA-1. I do think
there is a use of SHA-1 in OCSP that is not part of the current update
proposal and there is currently a similar discussion in TLS where strong
arguments are raised against adding algorithm negotiation complexity when
collision resistance is not a security issue. This problem is more politica=
l
than technical. But if there is any reason to do this, it probably is for
political reasons, so your point is valid.

/Stefan

On 3/17/09 1:20 AM, "Jim Schaad" <[email-masked]> wrote:

> Stefan,
> =20
> First I don=B9t know that I agree.  I think that the entirety of your prote=
ction
> is actually given by the leading sequence/length bytes.  The object is to
> prevent a prefix attack.  One can create a prefix attack against the TBS =
bytes
> =AD leading to identical signatures for both versions of the certificate.
> However adding the leading sequence/length octets probably means that you=
 need
> to have two different prefix attacks =AD a much harder condition, but maybe
> doable.
> =20
> However I don=B9t believe that you addressed my second point at all.  That =
is
> people completely migrate away from SHA-1 because it is considered to be
> broken.
> =20
> jim
> =20
>=20
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Monday, March 16, 2009 5:09 PM
> To: Jim Schaad; 'IETF-pkix'
> Subject: Re: Do we need rfc 3161bis?
> =20
> Jim,
>=20
> You ask,
> The question becomes can I create two certificates that can have the same
> hash, NOT will it happen by chance.
>=20
> I totally agree. And I don=B9t think you can.
>=20
> Not if the two certificates are signed with a good signature algorithm.
> If these certificates are signed with a bad signature algorithm that allo=
ws
> different certificates to share the same signature, then all bets are off
> anyway.
>=20
> If the signature algorithms are good, then the signatures of these
> certificates will be composed of a substantial amount of vastly different
> bits. As the signature algorithm is good, you can=B9t control the bits of t=
hese
> signatures in any meaningful way, leaving you basically with a trial and =
error
> approach. That even if SHA-1 is broken.
>=20
> /Stefan
>=20
>=20
> On 3/16/09 8:17 PM, "Jim Schaad" <[email-masked]> wrote:
> Stefan,
> =20
> The property that is being used is not the randomness property, it is a
> collision property.  (Or more specifically resistance to collisions.)   T=
he
> question becomes can I create two certificates that can have the same has=
h,
> NOT will it happen by chance.   If I can do so then I have a successful a=
ttack
> at this point.
> =20
> However one needs to assume that if SHA-1 is significantly broken, people=
 will
> be removing it from the trusted algorithm list and would then need a migr=
ation
> path of what to put in place of the current SHA-1 attribute.  This is the=
 main
> reason for doing the update.
> =20
> jim
> =20
>=20
> From: [email-masked] [mailto:[email-masked]] =
On
> Behalf Of Stefan Santesson
> Sent: Saturday, March 14, 2009 5:54 PM
> To: Jim Schaad; 'IETF-pkix'
> Subject: Re: Do we need rfc 3161bis?
>=20
> Yes, a good question indeed.
>=20
> Say that SHA-1 is completely broken in the sense that we can produce
> collisions at will, of all sorts and forms.
> Say also that we have a few valid TSA certificates issued for the same ke=
y
> pair, signed using good hash algorithms (or else all bets are off anyway)=
.
>=20
> The randomness properties of SHA-1 will remain intact even if SHA-1 is br=
oken.
> This means that the risk/chance that two valid certificates, signed with =
safe
> signature algorithms, will by chance produce collisions, is still totally
> negligible.
>=20
> Where am I thinking wrong here?
>=20
> /Stefan
>=20
>=20
>=20
> On 3/14/09 8:00 PM, "Jim Schaad" <[email-masked]> wrote:
> Stefan,
> =20
> The question you need to be asking is =AD Do you believe that SHA-1 will be
> broken one day, and if it is broken do you want to have in place a soluti=
on to
> deal with it.
> =20
> Jim
> =20
> =20
>=20
> From: [email-masked] [mailto:[email-masked]] =
On
> Behalf Of Stefan Santesson
> Sent: Saturday, March 14, 2009 7:06 AM
> To: IETF-pkix
> Subject: Do we need rfc 3161bis?
>=20
> The more I look into this the more I get to doubt that we actually need
> 3161bis.
>=20
> The only substantial technical change I know of is to allow the updated E=
SS
> certIDv2 to be used to identify the signer=B9s certificate IF the TSA for s=
ome
> reason choose to hash its certificate with another hash then SHA-1.
>=20
> The rationale for the certID identifier is given in section 5 of RFC 2634=
 and
> describes attacks where one valid certificate is substituted by another v=
alid
> certificate (exceopt for some DoS case that I don=B9t think is relevant her=
e).
> Now I have to ask myself. How likely is it that a legitimate TSA has 2  o=
r
> more legitimate certificates for the same public key with conflicting
> information (or information different enough to actually have a security
> impact) AND where the hash of these certificates produce a SHA-1 collisio=
n.
>=20
> This is not the previously discussed certificate collision attack using w=
eak
> certificate signing hash, where I may prepare a certificate request in a =
way
> where I can fool the CA to produce two valid certificates with the same
> certificate signature. If I would use that technique I would have to find=
 a
> way to prepare the TSA certificate requests, the TSA certificate hash nee=
d to
> be weak in addition to the certID hash AND In addition to that the comple=
te
> certificates (not only the to be signed part) need to create a hash colli=
sion
> when computing the certID.
>=20
> So, my first question is if this change addresses any real security threa=
t?
> Can someone provide a reasonable threat analysis?
> And consequently, if there are no real threats to solve, does this update
> motivate the potential interoperability issues that might be the result o=
f by
> allowing ESS CertIDv2 in time stamp tokens?
>=20
>=20
> If we do come to the conclusion that it is worth it, then why not just cr=
eate
> an update RFC updating RFC 3161 instead of replacing it?
>=20
> This update does not change any bits on the wire for implementations of t=
he
> current protocol. The only thing it does is to add an option to use ESS
> certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificate.
> This seems like a perfect thing for an update RFC. Another argument is th=
at
> the old editors that rightfully should have the credit for RFC 3161 are n=
ot
> part of this minor amendment but are completely erased from the update. T=
hat
> may be reasonable if the changes are major but I=B9m not so sure in this ca=
se.
>=20

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

<HTML>
<HEAD>
<TITLE>Re: Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>OK,<BR>
<BR>
The prefix attack only works, as you say yourself, on the tbs bits to creat=
e two certs with the same signature. This is ONLY possible if the signature =
hash algorithm is broken. The hash in the essCertID is calculated on the com=
plete certificates (including signatures), not only the tbs bits.<BR>
Thus, the prefix attack is pretty useless if you have a large chunk of rand=
om bits in the end that is bound to be different for each cert. And they wil=
l be different IF the signature algorithm of the certificates is not broken.=
<BR>
<BR>
The second question, sorry for missing it, is broader than just RFC 3161bis=
.<BR>
<BR>
I think we have many protocols, where collision resistance is not an issue,=
 where we don&#8217;t provide algorithm agility for all uses of SHA-1. I do =
think there is a use of SHA-1 in OCSP that is not part of the current update=
 proposal and there is currently a similar discussion in TLS where strong ar=
guments are raised against adding algorithm negotiation complexity when coll=
ision resistance is not a security issue. This problem is more political tha=
n technical. But if there is any reason to do this, it probably is for polit=
ical reasons, so your point is valid.<BR>
<BR>
/Stefan<BR>
<BR>
On 3/17/09 1:20 AM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
First I don&#8217;t know that I agree. &nbsp;I think that the entirety of y=
our protection is actually given by the leading sequence/length bytes. &nbsp=
;The object is to prevent a prefix attack. &nbsp;One can create a prefix att=
ack against the TBS bytes &#8211; leading to identical signatures for both v=
ersions of the certificate. &nbsp;However adding the leading sequence/length=
 octets probably means that you need to have two different prefix attacks &#=
8211; a much harder condition, but maybe doable.<BR>
&nbsp;<BR>
However I don&#8217;t believe that you addressed my second point at all. &n=
bsp;That is people completely migrate away from SHA-1 because it is consider=
ed to be broken.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Stefan Santesson [<a href=3D"mailto=
:[email-masked]">mailto:[email-masked]</a>] <BR>
<B>Sent:</B> Monday, March 16, 2009 5:09 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Jim,<BR>
<BR>
You ask,<BR>
<FONT COLOR=3D"#1E487C">The question becomes can I create two certificates th=
at can have the same hash, NOT will it happen by chance.<BR>
</FONT><BR>
I <B>totally</B> agree. And I don&#8217;t think you can.<BR>
<BR>
Not if the two certificates are signed with a good signature algorithm. <BR=
If these certificates are signed with a bad signature algorithm that allows=
 different certificates to share the same signature, then all bets are off a=
nyway.<BR>
<BR>
If the signature algorithms are good, then the signatures of these certific=
ates will be composed of a substantial amount of vastly different bits. As t=
he signature algorithm is good, you can&#8217;t control the bits of these si=
gnatures in any meaningful way, leaving you basically with a trial and error=
 approach. That even if SHA-1 is broken.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The property that is being used is not the randomness property, it is a col=
lision property. &nbsp;(Or more specifically resistance to collisions.) &nbs=
p;&nbsp;The question becomes can I create two certificates that can have the=
 same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so then I =
have a successful attack at this point.<BR>
&nbsp;<BR>
However one needs to assume that if SHA-1 is significantly broken, people w=
ill be removing it from the trusted algorithm list and would then need a mig=
ration path of what to put in place of the current SHA-1 attribute. &nbsp;Th=
is is the main reason for doing the update.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 5:54 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Yes, a good question indeed.<BR>
<BR>
Say that SHA-1 is completely broken in the sense that we can produce collis=
ions at will, of all sorts and forms.<BR>
Say also that we have a few valid TSA certificates issued for the same key =
pair, signed using good hash algorithms (or else all bets are off anyway).<B=
R>
<BR>
The randomness properties of SHA-1 will remain intact even if SHA-1 is brok=
en. This means that the risk/chance that two valid certificates, signed with=
 safe signature algorithms, will by chance produce collisions, is still tota=
lly negligible.<BR>
<BR>
Where am I thinking wrong here?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The question you need to be asking is &#8211; Do you believe that SHA-1 wil=
l be broken one day, and if it is broken do you want to have in place a solu=
tion to deal with it.<BR>
&nbsp;<BR>
Jim<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 7:06 AM<BR>
<B>To:</B> IETF-pkix<BR>
<B>Subject:</B> Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>The more I look into this the more I get to doubt that we ac=
tually need 3161bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3320100205_9340425--

From: "Jim Schaad" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Subject: RE: Do we need rfc 3161bis?
Date: Mon, 16 Mar 2009 17:20:06 -0700
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_01B1_01C9A65B.74BFEE60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

First I don't know that I agree.  I think that the entirety of your
protection is actually given by the leading sequence/length bytes.  The
object is to prevent a prefix attack.  One can create a prefix attack
against the TBS bytes - leading to identical signatures for both versions of
the certificate.  However adding the leading sequence/length octets probably
means that you need to have two different prefix attacks - a much harder
condition, but maybe doable.

However I don't believe that you addressed my second point at all.  That is
people completely migrate away from SHA-1 because it is considered to be
broken.

jim

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Monday, March 16, 2009 5:09 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?

Jim,

You ask,
The question becomes can I create two certificates that can have the same
hash, NOT will it happen by chance.

I totally agree. And I don't think you can.

Not if the two certificates are signed with a good signature algorithm. 
If these certificates are signed with a bad signature algorithm that allows
different certificates to share the same signature, then all bets are off
anyway.

If the signature algorithms are good, then the signatures of these
certificates will be composed of a substantial amount of vastly different
bits. As the signature algorithm is good, you can't control the bits of
these signatures in any meaningful way, leaving you basically with a trial
and error approach. That even if SHA-1 is broken.

/Stefan

On 3/16/09 8:17 PM, "Jim Schaad" <[email-masked]> wrote:

Stefan,
 
The property that is being used is not the randomness property, it is a
collision property.  (Or more specifically resistance to collisions.)   The
question becomes can I create two certificates that can have the same hash,
NOT will it happen by chance.   If I can do so then I have a successful
attack at this point.
 
However one needs to assume that if SHA-1 is significantly broken, people
will be removing it from the trusted algorithm list and would then need a
migration path of what to put in place of the current SHA-1 attribute.  This
is the main reason for doing the update.
 
jim

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 5:54 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?

Yes, a good question indeed.

Say that SHA-1 is completely broken in the sense that we can produce
collisions at will, of all sorts and forms.
Say also that we have a few valid TSA certificates issued for the same key
pair, signed using good hash algorithms (or else all bets are off anyway).

The randomness properties of SHA-1 will remain intact even if SHA-1 is
broken. This means that the risk/chance that two valid certificates, signed
with safe signature algorithms, will by chance produce collisions, is still
totally negligible.

Where am I thinking wrong here?

/Stefan

On 3/14/09 8:00 PM, "Jim Schaad" <[email-masked]> wrote:
Stefan,
 
The question you need to be asking is - Do you believe that SHA-1 will be
broken one day, and if it is broken do you want to have in place a solution
to deal with it.
 
Jim

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 7:06 AM
To: IETF-pkix
Subject: Do we need rfc 3161bis?

The more I look into this the more I get to doubt that we actually need
3161bis.

The only substantial technical change I know of is to allow the updated ESS
certIDv2 to be used to identify the signer's certificate IF the TSA for some
reason choose to hash its certificate with another hash then SHA-1.

The rationale for the certID identifier is given in section 5 of RFC 2634
and describes attacks where one valid certificate is substituted by another
valid certificate (exceopt for some DoS case that I don't think is relevant
here).
Now I have to ask myself. How likely is it that a legitimate TSA has 2  or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 collision.

This is not the previously discussed certificate collision attack using weak
certificate signing hash, where I may prepare a certificate request in a way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to find a
way to prepare the TSA certificate requests, the TSA certificate hash need
to be weak in addition to the certID hash AND In addition to that the
complete certificates (not only the to be signed part) need to create a hash
collision when computing the certID.

So, my first question is if this change addresses any real security threat?
Can someone provide a reasonable threat analysis?
And consequently, if there are no real threats to solve, does this update
motivate the potential interoperability issues that might be the result of
by allowing ESS CertIDv2 in time stamp tokens?

If we do come to the conclusion that it is worth it, then why not just
create an update RFC updating RFC 3161 instead of replacing it?

This update does not change any bits on the wire for implementations of the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA's certificate.
This seems like a perfect thing for an update RFC. Another argument is that
the old editors that rightfully should have the credit for RFC 3161 are not
part of this minor amendment but are completely erased from the update. That
may be reasonable if the changes are major but I'm not so sure in this case.

------=_NextPart_000_01B1_01C9A65B.74BFEE60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<title>Re: Do we need rfc 3161bis?</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Stefan,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>First I don&#8217;t know that I agree.&nbsp; I think that =
the entirety of
your protection is actually given by the leading sequence/length =
bytes.&nbsp; The
object is to prevent a prefix attack.&nbsp; One can create a prefix =
attack against
the TBS bytes &#8211; leading to identical signatures for both versions =
of the
certificate.&nbsp; However adding the leading sequence/length octets =
probably means
that you need to have two different prefix attacks &#8211; a much harder =
condition,
but maybe doable.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>However I don&#8217;t believe that you addressed my =
second point at
all.&nbsp; That is people completely migrate away from SHA-1 because it =
is
considered to be broken.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>jim<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Stefan =
Santesson
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, March 16, 2009 5:09 PM<br>
<b>To:</b> Jim Schaad; 'IETF-pkix'<br>
<b>Subject:</b> Re: Do we need rfc 3161bis?<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Jim,<br>
<br>
You ask,<br>
<span style=3D'color:#1E487C'>The question becomes can I create two =
certificates
that can have the same hash, NOT will it happen by chance.<br>
</span><br>
I <b>totally</b> agree. And I don&#8217;t think you can.<br>
<br>
Not if the two certificates are signed with a good signature algorithm. =
<br>
If these certificates are signed with a bad signature algorithm that =
allows
different certificates to share the same signature, then all bets are =
off
anyway.<br>
<br>
If the signature algorithms are good, then the signatures of these =
certificates
will be composed of a substantial amount of vastly different bits. As =
the
signature algorithm is good, you can&#8217;t control the bits of these =
signatures in
any meaningful way, leaving you basically with a trial and error =
approach. That
even if SHA-1 is broken.<br>
<br>
/Stefan<br>
<br>
<br>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a =
href=3D"[email-masked]">[email-masked]</a>&gt;
wrote:</span><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Stefan,<br>
&nbsp;<br>
The property that is being used is not the randomness property, it is a
collision property. &nbsp;(Or more specifically resistance to =
collisions.)
&nbsp;&nbsp;The question becomes can I create two certificates that can =
have
the same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so =
then I
have a successful attack at this point.<br>
&nbsp;<br>
However one needs to assume that if SHA-1 is significantly broken, =
people will
be removing it from the trusted algorithm list and would then need a =
migration
path of what to put in place of the current SHA-1 attribute. &nbsp;This =
is the
main reason for doing the update.<br>
&nbsp;<br>
jim<br>
&nbsp;<br>
</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a
href=3D"[email-masked]">[email-masked]</a> =
[<a
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
<b>On Behalf Of </b>Stefan Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 5:54 PM<br>
<b>To:</b> Jim Schaad; 'IETF-pkix'<br>
<b>Subject:</b> Re: Do we need rfc 3161bis?<br>
</span><br>
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Yes, =
a good
question indeed.<br>
<br>
Say that SHA-1 is completely broken in the sense that we can produce =
collisions
at will, of all sorts and forms.<br>
Say also that we have a few valid TSA certificates issued for the same =
key
pair, signed using good hash algorithms (or else all bets are off =
anyway).<br>
<br>
The randomness properties of SHA-1 will remain intact even if SHA-1 is =
broken.
This means that the risk/chance that two valid certificates, signed with =
safe
signature algorithms, will by chance produce collisions, is still =
totally
negligible.<br>
<br>
Where am I thinking wrong here?<br>
<br>
/Stefan<br>
<br>
<br>
<br>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a =
href=3D"[email-masked]">[email-masked]</a>&gt;
wrote:<br>
<span style=3D'color:#1F497D'>Stefan,<br>
&nbsp;<br>
The question you need to be asking is &#8211; Do you believe that SHA-1 =
will be
broken one day, and if it is broken do you want to have in place a =
solution to
deal with it.<br>
&nbsp;<br>
Jim<br>
&nbsp;<br>
&nbsp;<br>
</span><br>
</span><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a
href=3D"[email-masked]">[email-masked]</a> =
[<a
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
<b>On Behalf Of </b>Stefan Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 7:06 AM<br>
<b>To:</b> IETF-pkix<br>
<b>Subject:</b> Do we need rfc 3161bis?<br>
</span><br>
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>The =
more I
look into this the more I get to doubt that we actually need =
3161bis.<br>
<br>
The only substantial technical change I know of is to allow the updated =
ESS
certIDv2 to be used to identify the signer&#8217;s certificate IF the =
TSA for some
reason choose to hash its certificate with another hash then SHA-1.<br>
<br>
The rationale for the certID identifier is given in section 5 of RFC =
2634 and
describes attacks where one valid certificate is substituted by another =
valid
certificate (exceopt for some DoS case that I don&#8217;t think is =
relevant here).<br>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 =
&nbsp;or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 =
collision.<br>
<br>
This is not the previously discussed certificate collision attack using =
weak
certificate signing hash, where I may prepare a certificate request in a =
way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to =
find a way
to prepare the TSA certificate requests, the TSA certificate hash need =
to be
weak in addition to the certID hash AND In addition to that the complete
certificates (not only the to be signed part) need to create a hash =
collision
when computing the certID.<br>
<br>
So, my first question is if this change addresses any real security =
threat?<br>
Can someone provide a reasonable threat analysis?<br>
And consequently, if there are no real threats to solve, does this =
update
motivate the potential interoperability issues that might be the result =
of by
allowing ESS CertIDv2 in time stamp tokens?<br>
<br>
<br>
If we do come to the conclusion that it is worth it, then why not just =
create
an update RFC updating RFC 3161 instead of replacing it?<br>
<br>
This update does not change any bits on the wire for implementations of =
the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s =
certificate.<br>
This seems like a perfect thing for an update RFC. Another argument is =
that the
old editors that rightfully should have the credit for RFC 3161 are not =
part of
this minor amendment but are completely erased from the update. That may =
be
reasonable if the changes are major but I&#8217;m not so sure in this =
case.</span><o:p></o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_01B1_01C9A65B.74BFEE60--

Date: Tue, 17 Mar 2009 01:08:45 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[email-masked]>
To: Jim Schaad <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Sender: [email-masked]

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

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

Jim,

You ask,
The question becomes can I create two certificates that can have the same
hash, NOT will it happen by chance.

I totally agree. And I don=B9t think you can.

Not if the two certificates are signed with a good signature algorithm.
If these certificates are signed with a bad signature algorithm that allows
different certificates to share the same signature, then all bets are off
anyway.

If the signature algorithms are good, then the signatures of these
certificates will be composed of a substantial amount of vastly different
bits. As the signature algorithm is good, you can=B9t control the bits of
these signatures in any meaningful way, leaving you basically with a trial
and error approach. That even if SHA-1 is broken.

/Stefan

On 3/16/09 8:17 PM, "Jim Schaad" <[email-masked]> wrote:

> Stefan,
> =20
> The property that is being used is not the randomness property, it is a
> collision property.  (Or more specifically resistance to collisions.)   T=
he
> question becomes can I create two certificates that can have the same has=
h,
> NOT will it happen by chance.   If I can do so then I have a successful a=
ttack
> at this point.
> =20
> However one needs to assume that if SHA-1 is significantly broken, people=
 will
> be removing it from the trusted algorithm list and would then need a migr=
ation
> path of what to put in place of the current SHA-1 attribute.  This is the=
 main
> reason for doing the update.
> =20
> jim
> =20
>=20
> From: [email-masked] [mailto:[email-masked]] =
On
> Behalf Of Stefan Santesson
> Sent: Saturday, March 14, 2009 5:54 PM
> To: Jim Schaad; 'IETF-pkix'
> Subject: Re: Do we need rfc 3161bis?
> =20
> Yes, a good question indeed.
>=20
> Say that SHA-1 is completely broken in the sense that we can produce
> collisions at will, of all sorts and forms.
> Say also that we have a few valid TSA certificates issued for the same ke=
y
> pair, signed using good hash algorithms (or else all bets are off anyway)=
.
>=20
> The randomness properties of SHA-1 will remain intact even if SHA-1 is br=
oken.
> This means that the risk/chance that two valid certificates, signed with =
safe
> signature algorithms, will by chance produce collisions, is still totally
> negligible.
>=20
> Where am I thinking wrong here?
>=20
> /Stefan
>=20
>=20
>=20
> On 3/14/09 8:00 PM, "Jim Schaad" <[email-masked]> wrote:
> Stefan,
> =20
> The question you need to be asking is =AD Do you believe that SHA-1 will be
> broken one day, and if it is broken do you want to have in place a soluti=
on to
> deal with it.
> =20
> Jim
> =20
> =20
>=20
> From: [email-masked] [mailto:[email-masked]] =
On
> Behalf Of Stefan Santesson
> Sent: Saturday, March 14, 2009 7:06 AM
> To: IETF-pkix
> Subject: Do we need rfc 3161bis?
>=20
> The more I look into this the more I get to doubt that we actually need
> 3161bis.
>=20
> The only substantial technical change I know of is to allow the updated E=
SS
> certIDv2 to be used to identify the signer=B9s certificate IF the TSA for s=
ome
> reason choose to hash its certificate with another hash then SHA-1.
>=20
> The rationale for the certID identifier is given in section 5 of RFC 2634=
 and
> describes attacks where one valid certificate is substituted by another v=
alid
> certificate (exceopt for some DoS case that I don=B9t think is relevant her=
e).
> Now I have to ask myself. How likely is it that a legitimate TSA has 2  o=
r
> more legitimate certificates for the same public key with conflicting
> information (or information different enough to actually have a security
> impact) AND where the hash of these certificates produce a SHA-1 collisio=
n.
>=20
> This is not the previously discussed certificate collision attack using w=
eak
> certificate signing hash, where I may prepare a certificate request in a =
way
> where I can fool the CA to produce two valid certificates with the same
> certificate signature. If I would use that technique I would have to find=
 a
> way to prepare the TSA certificate requests, the TSA certificate hash nee=
d to
> be weak in addition to the certID hash AND In addition to that the comple=
te
> certificates (not only the to be signed part) need to create a hash colli=
sion
> when computing the certID.
>=20
> So, my first question is if this change addresses any real security threa=
t?
> Can someone provide a reasonable threat analysis?
> And consequently, if there are no real threats to solve, does this update
> motivate the potential interoperability issues that might be the result o=
f by
> allowing ESS CertIDv2 in time stamp tokens?
>=20
>=20
> If we do come to the conclusion that it is worth it, then why not just cr=
eate
> an update RFC updating RFC 3161 instead of replacing it?
>=20
> This update does not change any bits on the wire for implementations of t=
he
> current protocol. The only thing it does is to add an option to use ESS
> certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificate.
> This seems like a perfect thing for an update RFC. Another argument is th=
at
> the old editors that rightfully should have the credit for RFC 3161 are n=
ot
> part of this minor amendment but are completely erased from the update. T=
hat
> may be reasonable if the changes are major but I=B9m not so sure in this ca=
se.
>=20

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

<HTML>
<HEAD>
<TITLE>Re: Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Jim,<BR>
<BR>
You ask,<BR>
<FONT COLOR=3D"#1E487C">The question becomes can I create two certificates th=
at can have the same hash, NOT will it happen by chance.<BR>
</FONT><BR>
I <B>totally</B> agree. And I don&#8217;t think you can.<BR>
<BR>
Not if the two certificates are signed with a good signature algorithm. <BR=
If these certificates are signed with a bad signature algorithm that allows=
 different certificates to share the same signature, then all bets are off a=
nyway.<BR>
<BR>
If the signature algorithms are good, then the signatures of these certific=
ates will be composed of a substantial amount of vastly different bits. As t=
he signature algorithm is good, you can&#8217;t control the bits of these si=
gnatures in any meaningful way, leaving you basically with a trial and error=
 approach. That even if SHA-1 is broken.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 3/16/09 8:17 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The property that is being used is not the randomness property, it is a col=
lision property. &nbsp;(Or more specifically resistance to collisions.) &nbs=
p;&nbsp;The question becomes can I create two certificates that can have the=
 same hash, NOT will it happen by chance. &nbsp;&nbsp;If I can do so then I =
have a successful attack at this point.<BR>
&nbsp;<BR>
However one needs to assume that if SHA-1 is significantly broken, people w=
ill be removing it from the trusted algorithm list and would then need a mig=
ration path of what to put in place of the current SHA-1 attribute. &nbsp;Th=
is is the main reason for doing the update.<BR>
&nbsp;<BR>
jim<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 5:54 PM<BR>
<B>To:</B> Jim Schaad; 'IETF-pkix'<BR>
<B>Subject:</B> Re: Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Yes, a good question indeed.<BR>
<BR>
Say that SHA-1 is completely broken in the sense that we can produce collis=
ions at will, of all sorts and forms.<BR>
Say also that we have a few valid TSA certificates issued for the same key =
pair, signed using good hash algorithms (or else all bets are off anyway).<B=
R>
<BR>
The randomness properties of SHA-1 will remain intact even if SHA-1 is brok=
en. This means that the risk/chance that two valid certificates, signed with=
 safe signature algorithms, will by chance produce collisions, is still tota=
lly negligible.<BR>
<BR>
Where am I thinking wrong here?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The question you need to be asking is &#8211; Do you believe that SHA-1 wil=
l be broken one day, and if it is broken do you want to have in place a solu=
tion to deal with it.<BR>
&nbsp;<BR>
Jim<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 7:06 AM<BR>
<B>To:</B> IETF-pkix<BR>
<B>Subject:</B> Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>The more I look into this the more I get to doubt that we ac=
tually need 3161bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3320096927_9156048--

From: "Jim Schaad" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Subject: RE: Do we need rfc 3161bis?
Date: Mon, 16 Mar 2009 12:17:25 -0700
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_015D_01C9A631.2B2170F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

The property that is being used is not the randomness property, it is a
collision property.  (Or more specifically resistance to collisions.)   The
question becomes can I create two certificates that can have the same hash,
NOT will it happen by chance.   If I can do so then I have a successful
attack at this point.

However one needs to assume that if SHA-1 is significantly broken, people
will be removing it from the trusted algorithm list and would then need a
migration path of what to put in place of the current SHA-1 attribute.  This
is the main reason for doing the update.

jim

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 5:54 PM
To: Jim Schaad; 'IETF-pkix'
Subject: Re: Do we need rfc 3161bis?

Yes, a good question indeed.

Say that SHA-1 is completely broken in the sense that we can produce
collisions at will, of all sorts and forms.
Say also that we have a few valid TSA certificates issued for the same key
pair, signed using good hash algorithms (or else all bets are off anyway).

The randomness properties of SHA-1 will remain intact even if SHA-1 is
broken. This means that the risk/chance that two valid certificates, signed
with safe signature algorithms, will by chance produce collisions, is still
totally negligible.

Where am I thinking wrong here?

/Stefan

On 3/14/09 8:00 PM, "Jim Schaad" <[email-masked]> wrote:

Stefan,
 
The question you need to be asking is - Do you believe that SHA-1 will be
broken one day, and if it is broken do you want to have in place a solution
to deal with it.
 
Jim

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 7:06 AM
To: IETF-pkix
Subject: Do we need rfc 3161bis?

The more I look into this the more I get to doubt that we actually need
3161bis.

The only substantial technical change I know of is to allow the updated ESS
certIDv2 to be used to identify the signer's certificate IF the TSA for some
reason choose to hash its certificate with another hash then SHA-1.

The rationale for the certID identifier is given in section 5 of RFC 2634
and describes attacks where one valid certificate is substituted by another
valid certificate (exceopt for some DoS case that I don't think is relevant
here).
Now I have to ask myself. How likely is it that a legitimate TSA has 2  or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 collision.

This is not the previously discussed certificate collision attack using weak
certificate signing hash, where I may prepare a certificate request in a way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to find a
way to prepare the TSA certificate requests, the TSA certificate hash need
to be weak in addition to the certID hash AND In addition to that the
complete certificates (not only the to be signed part) need to create a hash
collision when computing the certID.

So, my first question is if this change addresses any real security threat?
Can someone provide a reasonable threat analysis?
And consequently, if there are no real threats to solve, does this update
motivate the potential interoperability issues that might be the result of
by allowing ESS CertIDv2 in time stamp tokens?

If we do come to the conclusion that it is worth it, then why not just
create an update RFC updating RFC 3161 instead of replacing it?

This update does not change any bits on the wire for implementations of the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA's certificate.
This seems like a perfect thing for an update RFC. Another argument is that
the old editors that rightfully should have the credit for RFC 3161 are not
part of this minor amendment but are completely erased from the update. That
may be reasonable if the changes are major but I'm not so sure in this case.

------=_NextPart_000_015D_01C9A631.2B2170F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<title>Re: Do we need rfc 3161bis?</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Stefan,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The property that is being used is not the randomness =
property,
it is a collision property.&nbsp; (Or more specifically resistance to
collisions.)&nbsp;&nbsp; The question becomes can I create two =
certificates
that can have the same hash, NOT will it happen by chance. =
&nbsp;&nbsp;If I can
do so then I have a successful attack at this =
point.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>However one needs to assume that if SHA-1 is =
significantly
broken, people will be removing it from the trusted algorithm list and =
would
then need a migration path of what to put in place of the current SHA-1
attribute.&nbsp; This is the main reason for doing the =
update.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>jim<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Stefan =
Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 5:54 PM<br>
<b>To:</b> Jim Schaad; 'IETF-pkix'<br>
<b>Subject:</b> Re: Do we need rfc 3161bis?<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>Yes, a good question indeed.<br>
<br>
Say that SHA-1 is completely broken in the sense that we can produce =
collisions
at will, of all sorts and forms.<br>
Say also that we have a few valid TSA certificates issued for the same =
key
pair, signed using good hash algorithms (or else all bets are off =
anyway).<br>
<br>
The randomness properties of SHA-1 will remain intact even if SHA-1 is =
broken.
This means that the risk/chance that two valid certificates, signed with =
safe
signature algorithms, will by chance produce collisions, is still =
totally
negligible.<br>
<br>
Where am I thinking wrong here?<br>
<br>
/Stefan<br>
<br>
<br>
<br>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a =
href=3D"[email-masked]">[email-masked]</a>&gt;
wrote:</span><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Stefan,<br>
&nbsp;<br>
The question you need to be asking is &#8211; Do you believe that SHA-1 =
will be
broken one day, and if it is broken do you want to have in place a =
solution to
deal with it.<br>
&nbsp;<br>
Jim<br>
&nbsp;<br>
&nbsp;<br>
</span><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
</span><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> <a
href=3D"[email-masked]">[email-masked]</a> =
[<a
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
<b>On Behalf Of </b>Stefan Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 7:06 AM<br>
<b>To:</b> IETF-pkix<br>
<b>Subject:</b> Do we need rfc 3161bis?<br>
</span><br>
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>The =
more I
look into this the more I get to doubt that we actually need =
3161bis.<br>
<br>
The only substantial technical change I know of is to allow the updated =
ESS
certIDv2 to be used to identify the signer&#8217;s certificate IF the =
TSA for
some reason choose to hash its certificate with another hash then =
SHA-1.<br>
<br>
The rationale for the certID identifier is given in section 5 of RFC =
2634 and
describes attacks where one valid certificate is substituted by another =
valid
certificate (exceopt for some DoS case that I don&#8217;t think is =
relevant
here).<br>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 =
&nbsp;or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 =
collision.<br>
<br>
This is not the previously discussed certificate collision attack using =
weak
certificate signing hash, where I may prepare a certificate request in a =
way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to =
find a way
to prepare the TSA certificate requests, the TSA certificate hash need =
to be
weak in addition to the certID hash AND In addition to that the complete
certificates (not only the to be signed part) need to create a hash =
collision
when computing the certID.<br>
<br>
So, my first question is if this change addresses any real security =
threat?<br>
Can someone provide a reasonable threat analysis?<br>
And consequently, if there are no real threats to solve, does this =
update
motivate the potential interoperability issues that might be the result =
of by
allowing ESS CertIDv2 in time stamp tokens?<br>
<br>
<br>
If we do come to the conclusion that it is worth it, then why not just =
create an
update RFC updating RFC 3161 instead of replacing it?<br>
<br>
This update does not change any bits on the wire for implementations of =
the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s =
certificate.<br>
This seems like a perfect thing for an update RFC. Another argument is =
that the
old editors that rightfully should have the credit for RFC 3161 are not =
part of
this minor amendment but are completely erased from the update. That may =
be
reasonable if the changes are major but I&#8217;m not so sure in this =
case.</span><o:p></o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_015D_01C9A631.2B2170F0--

Date: Mon, 16 Mar 2009 13:10:26 -0400
From: Sean Turner <[email-masked]>
To: RFC Errata System <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [Editorial Errata Reported] RFC5480 (1728)
Sender: [email-masked]

I approve (not sure this is the right term) this errata.

spt

RFC Errata System wrote:
> The following errata report has been submitted for RFC5480,
> "Elliptic Curve Cryptography Subject Public Key Information".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5480&eid=1728
> 
> --------------------------------------
> Type: Editorial
> Reported by: Alfred Hoenes <[email-masked]>
> 
> Section: 2.1.1.1
> 
> Original Text
> -------------
>    The namedCurve field in ECParameters uses object identifiers to name
>    well-known curves.  This document publishes curve identifiers for the
>    fifteen NIST-recommended curves [FIPS186-3].  Other documents can
> |  publish other name curve identifiers.  The NIST-named curves are:
> 
> 
> Corrected Text
> --------------
>    The namedCurve field in ECParameters uses object identifiers to name
>    well-known curves.  This document publishes curve identifiers for the
>    fifteen NIST-recommended curves [FIPS186-3].  Other documents can
> |  publish other named curve identifiers.  The NIST named curves are:
>                      ^                             ^
> 
> Notes
> -----
> Location: first paragraph of 2.1.1.1
> Rationale:
> a) typo:  s/name curve/named curve/
> b) extraneous hyphen (inserted in final publication processing)
>    changes semantics in an unfortunate manner; "NIST-named curves"
>    could be misunderstood as indicating that NIST had named these
>    'Named Curves'; "NIST-recommended named curves" might have been a
>    valid alternative but would have incurred too much word repetition.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5480 (draft-ietf-pkix-ecc-subpubkeyinfo-11)
> --------------------------------------
> Title               : Elliptic Curve Cryptography Subject Public Key Information
> Publication Date    : March 2009
> Author(s)           : S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk
> Category            : PROPOSED STANDARD
> Source              : Public-Key Infrastructure (X.509)
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
> 
> 

CC: [email-masked], [email-masked]
Date: Mon, 16 Mar 2009 18:24:54 +0200
From: "Maxim Masiutin" <[email-masked]>
Reply-To: "Maxim Masiutin" <[email-masked]>
Subject: Re[2]: A contradiction between RFC3852 and RFC3278
To: "Sean Turner" <[email-masked]>
Sender: [email-masked]

Hello Sean,

Thank you, your suggestion to add a paragraph is fine!

-- 
Best regards,
Maxim Masiutin                            mailto:[email-masked]

Date: Mon, 16 Mar 2009 12:10:04 -0400
From: Sean Turner <[email-masked]>
To: Maxim Masiutin <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: A contradiction between RFC3852 and RFC3278
Sender: [email-masked]

Maxim,

The paragraph now says:

signatureAlgorithm contains the signature algorithm identifier (see 
Section 7.1.3): ecdsa-with-SHA1, ecdsa-with-SHA224, ecdsa-with-SHA256, 
ecdsa-with-SHA384, or ecdsa-with-SHA512.

How about we add the following to the end of it:

The hash algorithm identified in the name of the signature algorithm 
MUST be the same as the digestAlgorithm (e.g., digestAlgorithm is 
id-sha256 therefore signatureAlgorithm is ecdsa-with-SHA256).

spt

Maxim Masiutin wrote:
> Hello Sean,
> 
> Maybe we should alter the description of signatureAlgorithm in section 2.1.1 of draft-smime-3278bis, to the following:
> 
>      - signatureAlgorithm contains the signature algorithm identifier 
>        (see Section 7.1.3) where the public key part of it
>        is ECDSA and the hash part MUST refer to the same algorithm as 
>        specified in the digestAlgorithm field. signatureAlgorithm MUST
>        be one of the following ecdsa-with-SHA1, 
>        ecdsa-with-SHA224, ecdsa-with-SHA256, 
>        ecdsa-with-SHA384, or ecdsa-with-SHA512. 
> 
> 

Date: Mon, 16 Mar 2009 08:52:21 -0700 (PDT)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Editorial Errata Reported] RFC5480 (1728)
From: RFC Errata System <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

The following errata report has been submitted for RFC5480,
"Elliptic Curve Cryptography Subject Public Key Information".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5480&eid=1728

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <[email-masked]>

Section: 2.1.1.1

Original Text
-------------
   The namedCurve field in ECParameters uses object identifiers to name
   well-known curves.  This document publishes curve identifiers for the
   fifteen NIST-recommended curves [FIPS186-3].  Other documents can
|  publish other name curve identifiers.  The NIST-named curves are:

Corrected Text
--------------
   The namedCurve field in ECParameters uses object identifiers to name
   well-known curves.  This document publishes curve identifiers for the
   fifteen NIST-recommended curves [FIPS186-3].  Other documents can
|  publish other named curve identifiers.  The NIST named curves are:
                     ^                             ^

Notes
-----
Location: first paragraph of 2.1.1.1
Rationale:
a) typo:  s/name curve/named curve/
b) extraneous hyphen (inserted in final publication processing)
   changes semantics in an unfortunate manner; "NIST-named curves"
   could be misunderstood as indicating that NIST had named these
   'Named Curves'; "NIST-recommended named curves" might have been a
   valid alternative but would have incurred too much word repetition.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5480 (draft-ietf-pkix-ecc-subpubkeyinfo-11)
--------------------------------------
Title               : Elliptic Curve Cryptography Subject Public Key Information
Publication Date    : March 2009
Author(s)           : S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG

Date: Mon, 16 Mar 2009 08:42:40 -0700 (PDT)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Editorial Errata Reported] RFC5480 (1727)
From: RFC Errata System <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

The following errata report has been submitted for RFC5480,
"Elliptic Curve Cryptography Subject Public Key Information".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5480&eid=1727

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <[email-masked]>

Section: 2.1.1, pg.5

Original Text
-------------
|     o specifiedCurve, which is of type SpecifiedECDomain type (defined
        in [X9.62]), allows all of the elliptic curve domain parameters
        to be explicitly specified.  [...]

Corrected Text
--------------
|     o specifiedCurve, which is of type SpecifiedECDomain (defined
        in [X9.62]), allows all of the elliptic curve domain parameters
        to be explicitly specified.  [...]

Notes
-----
Location: last bullet in Section 2.1.1.
Rationale: inadvertant replication of "type"

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5480 (draft-ietf-pkix-ecc-subpubkeyinfo-11)
--------------------------------------
Title               : Elliptic Curve Cryptography Subject Public Key Information
Publication Date    : March 2009
Author(s)           : S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk
Category            : PROPOSED STANDARD
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG

From: "Miller, Timothy J." <[email-masked]>
To: "'Jim Schaad'" <[email-masked]>, "'Maxim Masiutin'" <[email-masked]>, "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Mon, 16 Mar 2009 11:32:53 -0400
Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

------=_NextPart_000_0006_01C9A622.900EFCD0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Not correct.  Mail address local parts are *case sensitive*.

RFC5322 Section 3.4.1:

"""
The local-part portion is a domain-dependent string.
"""

RFC5321:

"""
2.4.  General Syntax Principles and Transaction Model

   [...]
 
The
   local-part of a mailbox MUST BE treated as case sensitive.
   Therefore, SMTP implementations MUST take care to preserve the case
   of mailbox local-parts.  In particular, for some hosts, the user
   "smith" is different from the user "Smith".  However, exploiting the
   case sensitivity of mailbox local-parts impedes interoperability and
   is discouraged.  Mailbox domains follow normal DNS rules and are
   hence not case sensitive.
"""

Discouraged != (MUST NOT || SHOULD NOT)

We went through this argument (at my instigation) last year on the S/MIME
list:

http://osdir.com/ml/ietf.smime/2007-09/msg00004.html

-- Tim

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Jim Schaad
>Sent: Saturday, March 14, 2009 4:53 PM
>To: 'Maxim Masiutin'; [email-masked]
>Cc: [email-masked]
>Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
>
>
>For the purposes of S/MIME all RFC822 addresses are considered to be
>case
>insensitive.
>
>Jim
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:owner-ietf-
>> [email-masked]] On Behalf Of Maxim Masiutin
>> Sent: Saturday, March 14, 2009 2:22 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: RFC4134 email mismatch in examples 4.8 and 4.9
>>
>> Hello,
>>
>> I have a question about RFC4134, Examples 4.8 and 4.9.
>>
>> "From" line of the RFC-822 message is [email-masked], while the
>> certificate's SubjectAlternativeName contains Rfc822Name =
>> [email-masked]
>>
>> So the two emails are different in the host part.
>>
>> Is it OK for them to be different?
>>
>>
>> --
>> Best regards,
>> Maxim Masiutin
>> Ritlabs SRL
>> http://www.ritlabs.com/

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

------=_NextPart_000_0006_01C9A622.900EFCD0--

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, pkix mailing list <[email-masked]>, pkix chair <[email-masked]>
Subject: Protocol Action: 'Update for RSAES-OAEP Algorithm  Parameters' to Proposed Standard 
Date: Mon, 16 Mar 2009 07:57:54 -0700 (PDT)
Sender: [email-masked]

The IESG has approved the following document:

- 'Update for RSAES-OAEP Algorithm Parameters '
   <draft-ietf-pkix-rfc4055-update-02.txt> as a Proposed Standard

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

The IESG contact persons are Pasi Eronen and Tim Polk.

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

Technical Summary

   The subjectPublicKeyInfo field of an X.509 certificate carries
   three data items: an algorithm identifier, optional parameters, and
   a bit string that represents the public key. The parameters are
   specific to the algorithm and this field usually contains simple
   values needed to characterize the public key algorithm, e.g., the
   generator and modulus for Diffie-Hellman. However, X.509 does not
   constrain the scope of this parameters field. The ANSI X9.62
   standards committee elected to use this field to express
   potentially complex limitations on how the public key in the
   certificate can be used, e.g., which key derivation functions can
   be applied to the bit string that results from a Diffie-Hellman key
   exchange.

   After considerable debate, the PKIX WG has decided to not express
   key usage constraints via this field. Instead, the WG decided that
   this sort of information should be expressed via use of distinct
   algorithm identifiers. (This decision is consistent with the
   observation that current products are not deigned to handle such
   key usage restrictions expressed in the subjectPublicKeyInfo
   field.)

   RFC 4055 such allowed restrictions to be placed in this field when
   used with RSA-OAEP.  This document changes RFC 4055 to say that
   restrictions MUST NOT be present in the certificate's
   subjectPublicKeyInfo field when used with RSA-OAEP. It also
   replaces incorrect references to the publicKeyAlgorithm field with
   references to the subjectPublicKeyInfo field. As a result, this
   revised version of RFC 4055 will be consistent with the PKIX WG
   conventions adopted for this field.

Working Group Summary

   This ID was discussed on the mailing list. A poll was taken on the
   PKIX list to determine whether the proposed change was the way
   forward and another poll was taken to determine whether the change
   would adversely affect implementations. The WG was in favor of the
   change and no implementer said it would adversely affect their
   products. Further, vendors that implement RFC 4055 support the
   change.

Document Quality

   This document is a short update of an existing draft and is
   comparable in quality to its predecessor.

Personnel

   Steve Kent is the document Shepherd.  Pasi Eronen is the 
   responsible security area director.

Date: Mon, 16 Mar 2009 10:17:02 -0400
From: "David A. Cooper" <[email-masked]>
To: Jim Schaad <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: RFC4134 email mismatch in examples 4.8 and 4.9
Sender: [email-masked]

Jim Schaad wrote:
> For the purposes of S/MIME all RFC822 addresses are considered to be case
> insensitive.

Jim,

Could you provide a reference for this?

I know that the PKCS#9 emailAddress attribute is case insensitive, but 
everywhere else that I have seen indicates that the local-part of an 
email address is case sensitive (although the host may, and usually 
does, treat the local-part as case insensitive).  For example, RFC 5321 
states:

   The local-part of a mailbox MUST BE treated as case sensitive.
   Therefore, SMTP implementations MUST take care to preserve
   the case of mailbox local-parts.  In particular, for some hosts, the
   user "smith" is different from the user "Smith".  However, exploiting
   the case sensitivity of mailbox local-parts impedes interoperability
   and is discouraged.  Mailbox domains follow normal DNS rules
   and are hence not case sensitive.

When you say that RFC822 addresses are considered to be case 
insensitive, are you saying that this is according to the standard for 
S/MIME or just that it is common practice?

Thanks,

Dave

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-pkix"<[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Date: Mon, 16 Mar 2009 12:27:29 +0100
Sender: [email-masked]

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

Sorry for the delay to respond.

Responses are in-line.

Denis
----- Message re=E7u -----=20
De : owner-ietf-pkix=20
=C0 : ietf-pkix=20
Date : 2009-03-04, 18:22:25
Sujet : draft-ietf-pkix-rfc3161bis-01.txt

I had the impression that thegoal of that texwt was an update
concerning hash algorithms.

One could expecte it would only contain an update to the ESScertid using
ESSCertidV2 etc.

The actual texts corresponds roughly to an expired draft some
years ago.

        - the document has been aligned with RFC 3628 to make the
          difference between a time-stamping unit (TSU) and a TSA.

Thus, the text is not a small update of 3161 but introduces several
new items, some of them seems questionable to me. Some problems
which had been mentioned with RFC 3161 in the past, have not been
addressed.

In 3161, a TSA is merely a technical service similar to what is
said in 3161bis for a TSU. A TSA in 3161bis does not really
have a defined technical role.

[Denis]  The key point is that the certificate belongs to one TSU, not to=
 one TSA.

A TSU certificate may be revoked. A TSA has no certificate and thus is no=
t revoked if one of its TSUs is compromised.
A TSA is the administrative entity responsible for managing one or more T=
SUs.

On the other hand the field tsa in a response refers to a TSA,
and to a certficate that validates it. But a TSA does no longer
have a certificate, only TSUs.

[Denis]  In the proposal, I kept the same names for the fields.=20
Maybe this is not the best choice, and "tsa" should be changed into "tsu"=
 to reflect better the difference.

As a consequence, the following paragraph cannot mention TSA
but at best a TSU.
Besides that it should also mentiion ESSCertIDv2.)

    The purpose of the tsa field is to give a hint in identifying the
    name of the TSA. If present, it MUST correspond to one of the
    subject names included in the certificate that is to be used to
    verify the token. However, the actual identification of the entity
    that signed the response will always occur through the use of the
    certificate identifier (ESSCertID Attribute) inside a
    SigningCertificate attribute which is part of the signerInfo
    (See Section 5 of [ESS]).

Chapter 3.3 does not use the 2119 terminology in the first phrase but
rather the ISO terminoilogy.=20

[Denis]  Do you mean "shall" should be changed into" SHALL" ?

3.3 is not relevant for the function of
a time stamp service. (Although it is likely that TSA actually
have filled all the REQUIRED 'shall) attributes in the DN)

The following text is extremely fuzzy:

    The name of the issuing TSU shall contain an appropriate subset of
    the following attributes (defined in ISO 9594-6 [ISO9594-6] and
    ITU-T Recommendation X.520 [X.520]):

        - countryName;
        - stateOrProvinceName;
        - organizationName;
        - commonName.

What means "appropriate subset". The text does not exclude
other attributs. So in fact, it says: The TSU MUST have a subjectDN?

It is not defined what name identifies a TSA? for example, everything exc=
ept
the common name?

[Denis]  The text is very explicit: "organizationName shall be present". =
Other fields are optional.

4.3 :

As it had been mentioned before the socket protocol as it is defined
has some problems: Since it was taken texto from CMP, there are some feat=
ures
that are may require some complexity in clients:
Only 00, 05, and 06 seem useful to me. If a TSA/U is not able to sign
a response within a few milliseconds with a TCP connection kept open,
I wouldn't call this a service.

[Denis]  I care for backwards compatibility first.=20
If some cases may not exist, then we can suppress them.=20
If they may exist, then we should keep them.=20

For HTTP, a server cannot return a poll indication as a comparison.

If a client does not send a pollReq, what will happen with a pending
response?

The protocol does not specify who terminates the connection. Is it the
server that closes after one exchange?

If multiple requests and responses can be exchanged over the same connect=
ion,
what is the dialogue model? request/response, pipelining, etc?

[Denis]  If you have a proposal , please post it to the list.

What is a TSU message? I think it should be TSP message. Old text was
TSA, which was also somewhat wrong.

[Denis]  A TSU Message is simply a message from a TSU.

Security section point 1 seems not quite correct:

Instead of :
it SHALL be set either to unspecified (0), affiliationChanged (3),
       superseded (4) or cessationOfOperation (5). In that case,

it should say

In the case when the reasonCode is set to either
       affiliationChanged (3),
       superseded (4) or cessationOfOperation (5)

Unspecified means that ther can be a key compromise IMO?

[Denis]. Good catch. Let us delete "unspecified (0)"

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

<HTML><HEAD><TITLE></TITLE>
<META content=3D"KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, =A9 Kurt=
 Senfer"=20
name=3DGENERATOR>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-=
1"></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=3D5 topMa=
rgin=3D5=20
#ffffff>
<DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>Sorry for the delay to respond.<BR></DIV>
<DIV>Responses are in-line.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-=
LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal">-----=20
  Message re=E7u ----- </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE=
-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: bl=
ack"><B>De=20
  :</B> <A href=3D"mailto :[email-masked]">owner-ietf-pkix<=
/A>=20
</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>=C0=20
  :</B> <A href=3D"mailto :[email-masked]">ietf-pkix</A> </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Date=20
  :</B> 2009-03-04, 18:22:25</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Sujet=20
  :</B> draft-ietf-pkix-rfc3161bis-01.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>I had the impression that thegoal of that texwt was an=20
  update<BR>concerning hash algorithms.<BR><BR>One could expecte it would=
 only=20
  contain an update to the ESScertid using<BR>ESSCertidV2 etc.<BR><BR>The=
 actual=20
  texts corresponds roughly to an expired draft some<BR>years=20
  ago.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- the docum=
ent has=20
  been aligned with RFC 3628 to make=20
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;diff=
erence=20
  between a time-stamping unit (TSU) and a TSA.<BR><BR>Thus, the text is =
not a=20
  small update of 3161 but introduces several<BR>new items, some of them =
seems=20
  questionable to me. Some problems<BR>which had been mentioned with RFC =
3161 in=20
  the past, have not been<BR>addressed.<BR><BR>In 3161, a TSA is merely a=
=20
  technical service similar to what is<BR>said in 3161bis for a TSU. A TS=
A in=20
  3161bis does not really<BR>have a defined technical role.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff>[Denis]&nbsp; The key point is that the cert=
ificate=20
  belongs to one TSU, not to one TSA.</FONT></DIV>
  <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff>A TSU certificate may be revoked. A TSA has =
no=20
  certificate and thus is not revoked if one of its TSUs is=20
  compromised.</FONT></DIV>
  <DIV><FONT color=3D#0000ff>A TSA&nbsp;is&nbsp;the administrative entity=
=20
  responsible for managing one or more TSUs.</FONT></DIV>
  <DIV><BR>On the other hand the field tsa in a response refers to a TSA,=
<BR>and=20
  to a certficate that validates it. But a TSA does no longer<BR>have a=20
  certificate, only TSUs.<BR></DIV>
  <DIV>
  <DIV><FONT color=3D#0000ff>[Denis]&nbsp; </FONT><FONT color=3D#0000ff>I=
n the=20
  proposal, I kept the same names for the fields. <BR>Maybe this is not t=
he best=20
  choice, and "tsa" should be changed into "tsu" to reflect better the=20
  difference.</FONT></DIV></DIV>
  <DIV><BR>As a consequence, the following paragraph cannot mention TSA<B=
R>but=20
  at best a TSU.<BR>Besides that it should also mentiion=20
  ESSCertIDv2.)<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;The purpose of the tsa fie=
ld is=20
  to give a hint in identifying the<BR>&nbsp;&nbsp;&nbsp;&nbsp;name of th=
e TSA.=20
  If present, it MUST correspond to one of=20
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;subject names included in the certificat=
e that=20
  is to be used to<BR>&nbsp;&nbsp;&nbsp;&nbsp;verify the token. However, =
the=20
  actual identification of the entity<BR>&nbsp;&nbsp;&nbsp;&nbsp;that sig=
ned the=20
  response will always occur through the use of=20
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;certificate identifier (ESSCertID Attrib=
ute)=20
  inside a<BR>&nbsp;&nbsp;&nbsp;&nbsp;SigningCertificate attribute which =
is part=20
  of the signerInfo<BR>&nbsp;&nbsp;&nbsp;&nbsp;(See Section 5 of=20
  [ESS]).<BR><BR><BR>Chapter 3.3 does not use the 2119 terminology in the=
 first=20
  phrase but<BR>rather the ISO terminoilogy. </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>
  <DIV><FONT color=3D#0000ff>[Denis]&nbsp; Do you mean "shall" should be =
changed=20
  into" SHALL" ?</FONT></DIV></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>3.3 is not relevant for the function of<BR>a time stamp service.=20
  (Although it is likely that TSA actually<BR>have filled all the REQUIRE=
D=20
  'shall) attributes in the DN)<BR><BR>The following text is extremely=20
  fuzzy:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;The name of the issuing TSU shall=
=20
  contain an appropriate subset of<BR>&nbsp;&nbsp;&nbsp;&nbsp;the followi=
ng=20
  attributes (defined in ISO 9594-6 [ISO9594-6]=20
  and<BR>&nbsp;&nbsp;&nbsp;&nbsp;ITU-T Recommendation X.520=20
  [X.520]):<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-=20
  countryName;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-=20
  stateOrProvinceName;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;-=20
  organizationName;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-=20
  commonName.<BR><BR>What means "appropriate subset". The text does not=20
  exclude<BR>other attributs. So in fact, it says: The TSU MUST have a=20
  subjectDN?<BR></DIV>
  <DIV>It is not defined what name identifies a TSA? for example, everyth=
ing=20
  except<BR>the common name?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff>[Denis]&nbsp; The text is very explicit:=20
  "organizationName shall be present". Other fields are optional.</FONT><=
/DIV>
  <DIV><BR>4.3 :<BR><BR>As it had been mentioned before the socket protoc=
ol as=20
  it is defined<BR>has some problems: Since it was taken texto from CMP, =
there=20
  are some features<BR>that are may require some complexity in clients:<B=
R>Only=20
  00, 05, and 06 seem useful to me. If a TSA/U is not able to sign<BR>a r=
esponse=20
  within a few milliseconds with a TCP connection kept open,<BR>I wouldn'=
t call=20
  this a service.</DIV>
  <DIV>
  <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff>[Denis]&nbsp; I care for backwards compatibi=
lity=20
  first. <BR>If some cases may not exist, then we can suppress them.=20
  </FONT></DIV>
  <DIV><FONT color=3D#0000ff>If they may exist, then we should keep them.=
=20
  </FONT></DIV></DIV>
  <DIV><BR>For HTTP, a server cannot return a poll indication as a=20
  comparison.<BR><BR>If a client does not send a pollReq, what will happe=
n with=20
  a pending<BR>response?<BR><BR>The protocol does not specify who termina=
tes the=20
  connection. Is it the<BR>server that closes after one exchange?<BR><BR>=
If=20
  multiple requests and responses can be exchanged over the same=20
  connection,<BR>what is the dialogue model? request/response, pipelining=
,=20
  etc?</DIV>
  <DIV><BR><FONT color=3D#0000ff>[Denis]&nbsp; If you have a proposal , p=
lease=20
  post it to the list.</FONT></DIV>
  <DIV><BR>What is a TSU message? I think it should be TSP message. Old t=
ext=20
  was<BR>TSA, which was also somewhat wrong.<BR></DIV>
  <DIV><FONT color=3D#0000ff>[Denis]&nbsp; A TSU Message is simply a mess=
age from=20
  a TSU.</FONT></DIV>
  <DIV><BR>Security section point 1 seems not quite correct:<BR><BR>Inste=
ad of=20
  :<BR>it SHALL be set either to unspecified (0), affiliationChanged=20
  (3),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;superseded (4) or=20
  cessationOfOperation (5). In that case,<BR><BR>it should say<BR><BR>In =
the=20
  case when the reasonCode is set to=20
  either<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;affiliationChanged=20
  (3),<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;superseded (4) or=20
  cessationOfOperation (5)<BR><BR>Unspecified means that ther can be a ke=
y=20
  compromise IMO?<BR></DIV>
  <DIV><FONT color=3D#0000ff>[Denis]. Good catch. Let us delete "unspecif=
ied=20
  (0)"</FONT><BR></DIV>
  <DIV>&nbsp;</DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_09031612271986357818122_002--

Date: Sun, 15 Mar 2009 14:26:33 +0100
From: Peter Sylvester <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: Jim Schaad <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Subject: Re: Do we need rfc 3161bis?
Sender: [email-masked]

Stefan Santesson wrote:
> Peter, 
>
> If we were designing the time stamp protocol from scratch today, I would
> probably argue that it is unnecessary to bind the signer's certificate to
> the time stamp token, or at least to make that optional.
>
> In most security services/protocols (such as OCSP) we do not bother to bind
> the signer's certificate to the signed data. In the general case the relying
> party is the one who reasonably relies on the signature and is therefore
> responsible for deciding if the certificate used to validate the signature
> is adequate for that trust decision.
>   
The "name of responder" is bound to the signature, as part
of the OCSP response similar to tsaName. Using essSigningCertficate
was overkill, but well, I am not asking to remove it.

If some update woul be necessary, I would rather remove the
MUST that requires a client to validate essSigningCert. IMO
tsaName match is sufficient.

At least one known public domain client
also verifies that the asserted date lies
in the validity period of the certificate. I am
not sure whether this is good.
> But since we already have 3161 out there, unless implementers and users have
> huge problems with it. I would not change anything.
>   
clarification and maybe simplifications that don't break interoperability
may be possible. The eesSigncert stuff is not in this category I think/

> In all other aspects I agree.
>
> /Stefan
>   
/P
>
> On 3/15/09 9:46 AM, "Peter Sylvester" <[email-masked]> wrote:
>
>   
>> What would be the impact, if a timestamp would not contain
>> a signingCertficate in the signed attributes?
>>
>> - A TSA could extend the lifetime of its TSA certificate by
>>   getting another with a different validity period?
>>
>> - The CA goes out of business, the CA cert gets revoked somehow;
>>   the TSA can get a replacement certificate with the same
>>   public key by another CA, so timestamps can still be
>>   verified,
>>
>> ... bad idea? Any security problem? I don't want to start
>> a discussion about long term verifiability (vs validity
>> of a timestamp).
>>
>> The 10 years old EU directive concerning  signatures do
>> require that the signatary is clearly identified. This is
>> sufficiently fulfilled by the 'tsa' field in the time stamp.
>>
>>
>> Another point:
>>
>> Most time stamp clients, if not all, verify that the timestamp
>> contains an essSigningCertficate. a v2 thus cannot simply
>> replace it without a risk that a client would not be able to
>> verify. The following piece of 3161bis may be problematic.
>>
>>    The time-stamp token MUST NOT contain any signatures other than the
>>    signature of the TSA.  The certificate identifier (either ESSCertID
>>    or ESSCertIDv2) of the TSU certificate MUST be included as a
>>    signerInfo attribute inside a SigningCertificate attribute.
>>
>>    Note: As mentioned in RFC 5035 [ESSV2], the SigningCertificateV2
>>          attribute MUST be used if any algorithm other than SHA-1
>>          is used and SHOULD NOT be used for SHA-1
>>
>> A TSA that starts using V2 after 3161bis publication would
>> be probably unable to produce verifiable time stamps for
>> many clients.
>>
>> In fact, it restricts the possibilities of a TSA, which today can
>> set both attributs.
>>
>> Peter
>>     
>
>
>   

Date: Sun, 15 Mar 2009 12:31:02 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: Jim Schaad <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Sender: [email-masked]

Peter, 

If we were designing the time stamp protocol from scratch today, I would
probably argue that it is unnecessary to bind the signer's certificate to
the time stamp token, or at least to make that optional.

In most security services/protocols (such as OCSP) we do not bother to bind
the signer's certificate to the signed data. In the general case the relying
party is the one who reasonably relies on the signature and is therefore
responsible for deciding if the certificate used to validate the signature
is adequate for that trust decision.

But since we already have 3161 out there, unless implementers and users have
huge problems with it. I would not change anything.

In all other aspects I agree.

/Stefan

On 3/15/09 9:46 AM, "Peter Sylvester" <[email-masked]> wrote:

> 
> What would be the impact, if a timestamp would not contain
> a signingCertficate in the signed attributes?
> 
> - A TSA could extend the lifetime of its TSA certificate by
>   getting another with a different validity period?
> 
> - The CA goes out of business, the CA cert gets revoked somehow;
>   the TSA can get a replacement certificate with the same
>   public key by another CA, so timestamps can still be
>   verified,
> 
> ... bad idea? Any security problem? I don't want to start
> a discussion about long term verifiability (vs validity
> of a timestamp).
> 
> The 10 years old EU directive concerning  signatures do
> require that the signatary is clearly identified. This is
> sufficiently fulfilled by the 'tsa' field in the time stamp.
> 
> 
> Another point:
> 
> Most time stamp clients, if not all, verify that the timestamp
> contains an essSigningCertficate. a v2 thus cannot simply
> replace it without a risk that a client would not be able to
> verify. The following piece of 3161bis may be problematic.
> 
>    The time-stamp token MUST NOT contain any signatures other than the
>    signature of the TSA.  The certificate identifier (either ESSCertID
>    or ESSCertIDv2) of the TSU certificate MUST be included as a
>    signerInfo attribute inside a SigningCertificate attribute.
> 
>    Note: As mentioned in RFC 5035 [ESSV2], the SigningCertificateV2
>          attribute MUST be used if any algorithm other than SHA-1
>          is used and SHOULD NOT be used for SHA-1
> 
> A TSA that starts using V2 after 3161bis publication would
> be probably unable to produce verifiable time stamps for
> many clients.
> 
> In fact, it restricts the possibilities of a TSA, which today can
> set both attributs.
> 
> Peter

Date: Sun, 15 Mar 2009 10:42:42 +0100
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Cc: ietf-pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Sender: [email-masked]

Denis Pinkas wrote:
> Stefan,
>  
> When you use the TSP (P = Protocol), you talk to a service (in this 
> case,  a Time Stamping Service).
>  
> You will get a response from one of the TSUs behind that service.
>  
> If the request is sucessful, the TST is signed by a TSU.
No, not in rfc 3161. The term used is TSA. The way how the
service is implemented, is out of scope NOIMO.

>  
> Every TSU is managed by a TSA.
Since I don't know your interpretation of "managed", it
is not clear whether you think about the TS Service Provider
the TS Service Operator, or some legal entity that assumes
the correct usage of a date and the protection of a key, or
else.

Nothing of that matters for the protocol.

Peter

Date: Sun, 15 Mar 2009 09:46:01 +0100
From: Peter Sylvester <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: Jim Schaad <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Subject: Re: Do we need rfc 3161bis?
Sender: [email-masked]

What would be the impact, if a timestamp would not contain
a signingCertficate in the signed attributes?

- A TSA could extend the lifetime of its TSA certificate by
  getting another with a different validity period?

- The CA goes out of business, the CA cert gets revoked somehow;
  the TSA can get a replacement certificate with the same
  public key by another CA, so timestamps can still be
  verified,

... bad idea? Any security problem? I don't want to start
a discussion about long term verifiability (vs validity
of a timestamp).

The 10 years old EU directive concerning  signatures do
require that the signatary is clearly identified. This is
sufficiently fulfilled by the 'tsa' field in the time stamp.

Another point:

Most time stamp clients, if not all, verify that the timestamp
contains an essSigningCertficate. a v2 thus cannot simply
replace it without a risk that a client would not be able to
verify. The following piece of 3161bis may be problematic.

   The time-stamp token MUST NOT contain any signatures other than the
   signature of the TSA.  The certificate identifier (either ESSCertID 
   or ESSCertIDv2) of the TSU certificate MUST be included as a 
   signerInfo attribute inside a SigningCertificate attribute.

   Note: As mentioned in RFC 5035 [ESSV2], the SigningCertificateV2 
         attribute MUST be used if any algorithm other than SHA-1 
         is used and SHOULD NOT be used for SHA-1

A TSA that starts using V2 after 3161bis publication would
be probably unable to produce verifiable time stamps for
many clients.

In fact, it restricts the possibilities of a TSA, which today can
set both attributs.

Peter

Date: Sun, 15 Mar 2009 01:53:49 +0100
Subject: Re: Do we need rfc 3161bis?
From: Stefan Santesson <[email-masked]>
To: Jim Schaad <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Sender: [email-masked]

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

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

Yes, a good question indeed.

Say that SHA-1 is completely broken in the sense that we can produce
collisions at will, of all sorts and forms.
Say also that we have a few valid TSA certificates issued for the same key
pair, signed using good hash algorithms (or else all bets are off anyway).

The randomness properties of SHA-1 will remain intact even if SHA-1 is
broken. This means that the risk/chance that two valid certificates, signed
with safe signature algorithms, will by chance produce collisions, is still
totally negligible.

Where am I thinking wrong here?

/Stefan

On 3/14/09 8:00 PM, "Jim Schaad" <[email-masked]> wrote:

> Stefan,
> =20
> The question you need to be asking is =AD Do you believe that SHA-1 will be
> broken one day, and if it is broken do you want to have in place a soluti=
on to
> deal with it.
> =20
> Jim
> =20
> =20
>=20
> From: [email-masked] [mailto:[email-masked]] =
On
> Behalf Of Stefan Santesson
> Sent: Saturday, March 14, 2009 7:06 AM
> To: IETF-pkix
> Subject: Do we need rfc 3161bis?
> =20
> The more I look into this the more I get to doubt that we actually need
> 3161bis.
>=20
> The only substantial technical change I know of is to allow the updated E=
SS
> certIDv2 to be used to identify the signer=B9s certificate IF the TSA for s=
ome
> reason choose to hash its certificate with another hash then SHA-1.
>=20
> The rationale for the certID identifier is given in section 5 of RFC 2634=
 and
> describes attacks where one valid certificate is substituted by another v=
alid
> certificate (exceopt for some DoS case that I don=B9t think is relevant her=
e).
> Now I have to ask myself. How likely is it that a legitimate TSA has 2  o=
r
> more legitimate certificates for the same public key with conflicting
> information (or information different enough to actually have a security
> impact) AND where the hash of these certificates produce a SHA-1 collisio=
n.
>=20
> This is not the previously discussed certificate collision attack using w=
eak
> certificate signing hash, where I may prepare a certificate request in a =
way
> where I can fool the CA to produce two valid certificates with the same
> certificate signature. If I would use that technique I would have to find=
 a
> way to prepare the TSA certificate requests, the TSA certificate hash nee=
d to
> be weak in addition to the certID hash AND In addition to that the comple=
te
> certificates (not only the to be signed part) need to create a hash colli=
sion
> when computing the certID.
>=20
> So, my first question is if this change addresses any real security threa=
t?
> Can someone provide a reasonable threat analysis?
> And consequently, if there are no real threats to solve, does this update
> motivate the potential interoperability issues that might be the result o=
f by
> allowing ESS CertIDv2 in time stamp tokens?
>=20
>=20
> If we do come to the conclusion that it is worth it, then why not just cr=
eate
> an update RFC updating RFC 3161 instead of replacing it?
>=20
> This update does not change any bits on the wire for implementations of t=
he
> current protocol. The only thing it does is to add an option to use ESS
> certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificate.
> This seems like a perfect thing for an update RFC. Another argument is th=
at
> the old editors that rightfully should have the credit for RFC 3161 are n=
ot
> part of this minor amendment but are completely erased from the update. T=
hat
> may be reasonable if the changes are major but I=B9m not so sure in this ca=
se.
>=20

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

<HTML>
<HEAD>
<TITLE>Re: Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Yes, a good question indeed.<BR>
<BR>
Say that SHA-1 is completely broken in the sense that we can produce collis=
ions at will, of all sorts and forms.<BR>
Say also that we have a few valid TSA certificates issued for the same key =
pair, signed using good hash algorithms (or else all bets are off anyway).<B=
R>
<BR>
The randomness properties of SHA-1 will remain intact even if SHA-1 is brok=
en. This means that the risk/chance that two valid certificates, signed with=
 safe signature algorithms, will by chance produce collisions, is still tota=
lly negligible.<BR>
<BR>
Where am I thinking wrong here?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 3/14/09 8:00 PM, &quot;Jim Schaad&quot; &lt;<a href=3D"ietf@augustcellars.=
com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D">Stefan,<BR>
&nbsp;<BR>
The question you need to be asking is &#8211; Do you believe that SHA-1 wil=
l be broken one day, and if it is broken do you want to have in place a solu=
tion to deal with it.<BR>
&nbsp;<BR>
Jim<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Saturday, March 14, 2009 7:06 AM<BR>
<B>To:</B> IETF-pkix<BR>
<B>Subject:</B> Do we need rfc 3161bis?<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>The more I look into this the more I get to doubt that we ac=
tually need 3161bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3319926831_1682829--

CC: <[email-masked]>, <[email-masked]>
Date: Sun, 15 Mar 2009 00:29:45 +0200
From: "Maxim Masiutin" <[email-masked]>
Reply-To: "Maxim Masiutin" <[email-masked]>
Subject: Re: RE: RFC4134 email mismatch in examples 4.8 and 4.9
To: "Jim Schaad" <[email-masked]>
Sender: [email-masked]

Hello Jim,

Then you for replying. As I wrote in my first message, the two emails are different in the host part ("examples.com" vs "example.com"), where the character "s" after "example" before ".com" is the difference:

[email-masked]
[email-masked]

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

From: "Jim Schaad" <[email-masked]>
To: "'Maxim Masiutin'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RFC4134 email mismatch in examples 4.8 and 4.9
Date: Sat, 14 Mar 2009 14:53:18 -0700
Sender: [email-masked]

For the purposes of S/MIME all RFC822 addresses are considered to be case
insensitive.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Maxim Masiutin
> Sent: Saturday, March 14, 2009 2:22 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RFC4134 email mismatch in examples 4.8 and 4.9
> 
> Hello,
> 
> I have a question about RFC4134, Examples 4.8 and 4.9.
> 
> "From" line of the RFC-822 message is [email-masked], while the
> certificate's SubjectAlternativeName contains Rfc822Name =
> [email-masked]
> 
> So the two emails are different in the host part.
> 
> Is it OK for them to be different?
> 
> 
> --
> Best regards,
> Maxim Masiutin
> Ritlabs SRL
> http://www.ritlabs.com/

CC: [email-masked], [email-masked]
Date: Sat, 14 Mar 2009 23:43:18 +0200
From: "Maxim Masiutin" <[email-masked]>
Reply-To: "Maxim Masiutin" <[email-masked]>
Subject: Re[2]: A contradiction between RFC3852 and RFC3278
To: "Sean Turner" <[email-masked]>
Sender: [email-masked]

Hello Sean,

Maybe we should alter the description of signatureAlgorithm in section 2.1.1 of draft-smime-3278bis, to the following:

     - signatureAlgorithm contains the signature algorithm identifier 
       (see Section 7.1.3) where the public key part of it
       is ECDSA and the hash part MUST refer to the same algorithm as 
       specified in the digestAlgorithm field. signatureAlgorithm MUST
       be one of the following ecdsa-with-SHA1, 
       ecdsa-with-SHA224, ecdsa-with-SHA256, 
       ecdsa-with-SHA384, or ecdsa-with-SHA512. 

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

CC: [email-masked]
Date: Sat, 14 Mar 2009 23:22:24 +0200
From: "Maxim Masiutin" <[email-masked]>
Reply-To: "Maxim Masiutin" <[email-masked]>
Subject: RFC4134 email mismatch in examples 4.8 and 4.9
To: [email-masked]
Sender: [email-masked]

SGVsbG8sDQoNCkkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IFJGQzQxMzQsIEV4YW1wbGVzIDQuOCBh
bmQgNC45Lg0KDQoiRnJvbSIgbGluZSBvZiB0aGUgUkZDLTgyMiBtZXNzYWdlIGlzIGFsaWNlRHNz
QGV4YW1wbGVzLmNvbSwgd2hpbGUgdGhlIGNlcnRpZmljYXRlknMgU3ViamVjdEFsdGVybmF0aXZl
TmFtZSBjb250YWlucyBSZmM4MjJOYW1lID0gQWxpY2VEU1NAZXhhbXBsZS5jb20NCg0KU28gdGhl
IHR3byBlbWFpbHMgYXJlIGRpZmZlcmVudCBpbiB0aGUgaG9zdCBwYXJ0Lg0KDQpJcyBpdCBPSyBm
b3IgdGhlbSB0byBiZSBkaWZmZXJlbnQ/DQoNCg0KLS0gDQpCZXN0IHJlZ2FyZHMsDQpNYXhpbSBN
YXNpdXRpbiAgICAgICAgICAgICAgICAgICAgICAgICANClJpdGxhYnMgU1JMDQpodHRwOi8vd3d3
LnJpdGxhYnMuY29tLw0K

From: "Jim Schaad" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "'IETF-pkix'" <[email-masked]>
Subject: RE: Do we need rfc 3161bis?
Date: Sat, 14 Mar 2009 12:00:43 -0700
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_0829_01C9A49C.80C61B50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

The question you need to be asking is - Do you believe that SHA-1 will be
broken one day, and if it is broken do you want to have in place a solution
to deal with it.

Jim

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Saturday, March 14, 2009 7:06 AM
To: IETF-pkix
Subject: Do we need rfc 3161bis?

The more I look into this the more I get to doubt that we actually need
3161bis.

The only substantial technical change I know of is to allow the updated ESS
certIDv2 to be used to identify the signer's certificate IF the TSA for some
reason choose to hash its certificate with another hash then SHA-1.

The rationale for the certID identifier is given in section 5 of RFC 2634
and describes attacks where one valid certificate is substituted by another
valid certificate (exceopt for some DoS case that I don't think is relevant
here).
Now I have to ask myself. How likely is it that a legitimate TSA has 2  or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 collision.

This is not the previously discussed certificate collision attack using weak
certificate signing hash, where I may prepare a certificate request in a way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to find a
way to prepare the TSA certificate requests, the TSA certificate hash need
to be weak in addition to the certID hash AND In addition to that the
complete certificates (not only the to be signed part) need to create a hash
collision when computing the certID.

So, my first question is if this change addresses any real security threat?
Can someone provide a reasonable threat analysis?
And consequently, if there are no real threats to solve, does this update
motivate the potential interoperability issues that might be the result of
by allowing ESS CertIDv2 in time stamp tokens?

If we do come to the conclusion that it is worth it, then why not just
create an update RFC updating RFC 3161 instead of replacing it?

This update does not change any bits on the wire for implementations of the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA's certificate.
This seems like a perfect thing for an update RFC. Another argument is that
the old editors that rightfully should have the credit for RFC 3161 are not
part of this minor amendment but are completely erased from the update. That
may be reasonable if the changes are major but I'm not so sure in this case.

------=_NextPart_000_0829_01C9A49C.80C61B50
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<title>Do we need rfc 3161bis?</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Stefan,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The question you need to be asking is &#8211; Do you =
believe that
SHA-1 will be broken one day, and if it is broken do you want to have in =
place
a solution to deal with it.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Jim<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

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

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Stefan =
Santesson<br>
<b>Sent:</b> Saturday, March 14, 2009 7:06 AM<br>
<b>To:</b> IETF-pkix<br>
<b>Subject:</b> Do we need rfc 3161bis?<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif"'>The more I look into this the more I =
get to
doubt that we actually need 3161bis.<br>
<br>
The only substantial technical change I know of is to allow the updated =
ESS
certIDv2 to be used to identify the signer&#8217;s certificate IF the =
TSA for some
reason choose to hash its certificate with another hash then SHA-1.<br>
<br>
The rationale for the certID identifier is given in section 5 of RFC =
2634 and
describes attacks where one valid certificate is substituted by another =
valid
certificate (exceopt for some DoS case that I don&#8217;t think is =
relevant here).<br>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 =
&nbsp;or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 =
collision.<br>
<br>
This is not the previously discussed certificate collision attack using =
weak
certificate signing hash, where I may prepare a certificate request in a =
way
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to =
find a way
to prepare the TSA certificate requests, the TSA certificate hash need =
to be
weak in addition to the certID hash AND In addition to that the complete
certificates (not only the to be signed part) need to create a hash =
collision
when computing the certID.<br>
<br>
So, my first question is if this change addresses any real security =
threat?<br>
Can someone provide a reasonable threat analysis?<br>
And consequently, if there are no real threats to solve, does this =
update
motivate the potential interoperability issues that might be the result =
of by
allowing ESS CertIDv2 in time stamp tokens?<br>
<br>
<br>
If we do come to the conclusion that it is worth it, then why not just =
create
an update RFC updating RFC 3161 instead of replacing it?<br>
<br>
This update does not change any bits on the wire for implementations of =
the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s =
certificate.<br>
This seems like a perfect thing for an update RFC. Another argument is =
that the
old editors that rightfully should have the credit for RFC 3161 are not =
part of
this minor amendment but are completely erased from the update. That may =
be
reasonable if the changes are major but I&#8217;m not so sure in this =
case.</span><o:p></o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0829_01C9A49C.80C61B50--

Date: Sat, 14 Mar 2009 15:05:54 +0100
Subject: Do we need rfc 3161bis?
From: Stefan Santesson <[email-masked]>
To: IETF-pkix <[email-masked]>
Sender: [email-masked]

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

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

The more I look into this the more I get to doubt that we actually need
3161bis.

The only substantial technical change I know of is to allow the updated ESS
certIDv2 to be used to identify the signer=B9s certificate IF the TSA for som=
e
reason choose to hash its certificate with another hash then SHA-1.

The rationale for the certID identifier is given in section 5 of RFC 2634
and describes attacks where one valid certificate is substituted by another
valid certificate (exceopt for some DoS case that I don=B9t think is relevant
here).
Now I have to ask myself. How likely is it that a legitimate TSA has 2  or
more legitimate certificates for the same public key with conflicting
information (or information different enough to actually have a security
impact) AND where the hash of these certificates produce a SHA-1 collision.

This is not the previously discussed certificate collision attack using wea=
k
certificate signing hash, where I may prepare a certificate request in a wa=
y
where I can fool the CA to produce two valid certificates with the same
certificate signature. If I would use that technique I would have to find a
way to prepare the TSA certificate requests, the TSA certificate hash need
to be weak in addition to the certID hash AND In addition to that the
complete certificates (not only the to be signed part) need to create a has=
h
collision when computing the certID.

So, my first question is if this change addresses any real security threat?
Can someone provide a reasonable threat analysis?
And consequently, if there are no real threats to solve, does this update
motivate the potential interoperability issues that might be the result of
by allowing ESS CertIDv2 in time stamp tokens?

If we do come to the conclusion that it is worth it, then why not just
create an update RFC updating RFC 3161 instead of replacing it?

This update does not change any bits on the wire for implementations of the
current protocol. The only thing it does is to add an option to use ESS
certIDv2 IF SHA-1 is not used as hash to identify the TSA=B9s certificate.
This seems like a perfect thing for an update RFC. Another argument is that
the old editors that rightfully should have the credit for RFC 3161 are not
part of this minor amendment but are completely erased from the update. Tha=
t
may be reasonable if the changes are major but I=B9m not so sure in this case=
.

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

<HTML>
<HEAD>
<TITLE>Do we need rfc 3161bis?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>The more I look into this the more I get to doubt that we actually need 31=
61bis.<BR>
<BR>
The only substantial technical change I know of is to allow the updated ESS=
 certIDv2 to be used to identify the signer&#8217;s certificate IF the TSA f=
or some reason choose to hash its certificate with another hash then SHA-1.<=
BR>
<BR>
The rationale for the certID identifier is given in section 5 of RFC 2634 a=
nd describes attacks where one valid certificate is substituted by another v=
alid certificate (exceopt for some DoS case that I don&#8217;t think is rele=
vant here).<BR>
Now I have to ask myself. How likely is it that a legitimate TSA has 2 &nbs=
p;or more legitimate certificates for the same public key with conflicting i=
nformation (or information different enough to actually have a security impa=
ct) AND where the hash of these certificates produce a SHA-1 collision.<BR>
<BR>
This is not the previously discussed certificate collision attack using wea=
k certificate signing hash, where I may prepare a certificate request in a w=
ay where I can fool the CA to produce two valid certificates with the same c=
ertificate signature. If I would use that technique I would have to find a w=
ay to prepare the TSA certificate requests, the TSA certificate hash need to=
 be weak in addition to the certID hash AND In addition to that the complete=
 certificates (not only the to be signed part) need to create a hash collisi=
on when computing the certID.<BR>
<BR>
So, my first question is if this change addresses any real security threat?=
<BR>
Can someone provide a reasonable threat analysis?<BR>
And consequently, if there are no real threats to solve, does this update m=
otivate the potential interoperability issues that might be the result of by=
 allowing ESS CertIDv2 in time stamp tokens?<BR>
<BR>
<BR>
If we do come to the conclusion that it is worth it, then why not just crea=
te an update RFC updating RFC 3161 instead of replacing it?<BR>
<BR>
This update does not change any bits on the wire for implementations of the=
 current protocol. The only thing it does is to add an option to use ESS cer=
tIDv2 IF SHA-1 is not used as hash to identify the TSA&#8217;s certificate.<=
BR>
This seems like a perfect thing for an update RFC. Another argument is that=
 the old editors that rightfully should have the credit for RFC 3161 are not=
 part of this minor amendment but are completely erased from the update. Tha=
t may be reasonable if the changes are major but I&#8217;m not so sure in th=
is case.<BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>

--B_3319887957_685341--

Date: Fri, 13 Mar 2009 19:56:24 -0400
From: Sean Turner <[email-masked]>
To: Maxim Masiutin <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: A contradiction between RFC3852 and RFC3278
Sender: [email-masked]

Maxim,

I don't have any objection to adding the note to draft-smime-3278bis.

spt

Maxim Masiutin wrote:
> Hello Sean,
> 
> In all CMS messages that I’ve seen, when RSA algorithm is used, SignatureAlgorithm in the SignerInfo is rsaEncryption, not md5WithRSAEncryption. That’s why it made confusion when I was implementing elliptic curves.
> Maybe, if an update of RFC3852 is planned, we will add a clarification for this?
> Also, while RFC3278-bis is in the draft status, what about adding a clarification that hash in SignatureAlgorithm and DigestAlgorithm must match?
> 
> 

CC: [email-masked]
Date: Fri, 13 Mar 2009 18:19:42 +0200
From: "Maxim Masiutin" <[email-masked]>
Reply-To: "Maxim Masiutin" <[email-masked]>
Subject: Re[2]: A contradiction between RFC3852 and RFC3278
To: "Sean Turner" <[email-masked]>
Sender: [email-masked]

Date: Fri, 13 Mar 2009 11:58:16 -0400
From: Sean Turner <[email-masked]>
To: Maxim Masiutin <[email-masked]>
CC: [email-masked]
Subject: Re: A contradiction between RFC3852 and RFC3278
Sender: [email-masked]

Maxim,

I don't think that having the name of the hash algorithm in the 
signature ID assumes assumes that the algorithm takes as an input the 
whole message itself rather than the digest.  There are many examples 
where the object identifier's name for a signature algorithms includes 
the name of the hash that's used: md*WithRSAEncryption, 
sha*-WithRSAEncryption, and id-dsa-with-sha*. RFC 3278 and 
draft-ietf-smime-3278bis just follow the examples set by algorithms 
defined earlier.

I think it's pretty well implied that the digestAlgorithm hash (e.g., 
id-sha256) algorithm and the name of the hash in the signatureAlgorithm 
(e.g., ecdsda-with-SHA256) need to match.

spt

Maxim Masiutin wrote:
> Hello Ietf-Pkix,
> 
> I have found a contradiction between RFC3278 (and draft-ietf-smime-3278bis-05.txt work in progress) and RFC3852.
> 
> RFC3852 declares that the signatureAlgorithm in the SignerInfo should not be a compound algorithm of a public key algorithm and a hash function. Section 10.1.2 of RFC3852: ”The SignatureAlgorithmIdentifier type identifies a signature algorithm.  Examples include RSA, DSA, and ECDSA.  A signature algorithm supports signature generation and verification operations.  The signature generation operation uses the message digest and the signer’s private key to generate a signature value”. As specified in the RFC3852, the signature algorithm takes the message digest, i.e. the result of a hash function specified in the digestAlgorithm in the SignerInfo
> 
> 
> RFC3278 (and bis) declares that signatureAlgorithm contains the algorithm identifier ecdsa-with-SHA1 (bis also allows any other SHA hash), i.e. assumes that the algorithm takes as an input the whole message itself rather than the digest. It also tells that the digestAlgorithm in the SignerInfo should also be a SHA hash. Maybe it assumes that the SHA in digestAlgorithm should match SHA in signatureAlgorithm, but it is not explicitly clarified. Thus, a combination of ecdsa-with-SHA224 in signatureAlgorithm and id-sha-512 in digestAlgorithm is not prohibited.
> 
> 
> How can we resolve this contradiction of RFC3852 and RFC3278?
> 
>   
> 
> 

Date: Fri, 13 Mar 2009 14:38:03 +0200
From: "Maxim Masiutin" <[email-masked]>
Reply-To: "Maxim Masiutin" <[email-masked]>
Subject: A contradiction between RFC3852 and RFC3278
To: [email-masked]
Sender: [email-masked]

Date: Fri, 13 Mar 2009 09:56:24 +0100
From: Johannes Merkle <[email-masked]>
To: Alfredo Esposito <[email-masked]>
CC: Stefan Santesson <[email-masked]>, Peter Sylvester <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Sender: [email-masked]

so, if a "time stamp Responder" uses several signature creation devices in order to increase performance, but the
corresponding certificates are issued for the same subject names, these signature creation devices represent the same
TSU? This seems counterintuitive to me.
And I am not sure whether this (quite typical) scenario is reflected by the new draft. At least the last sentence in
section 3.3 indicates a different scenario:
   A TSS MAY have distinct TSUs, e.g., to accommodate different
   policies, different algorithms, different private key sizes or to
   increase the performance.

Johannes

Alfredo Esposito schrieb am 12.03.2009 17:27:
> 
> I love joking with the words in my own language, but my English is not
> smart enough
> TSU is the subject of a X.509 public key certificate and the
> corresponding private key is used to sign time-stamp-token compliant
> with IETF RFC 3161
> Is it better?
> 
> 
> Stefan Santesson wrote:
>> Alfred,
>>
>>  
>>> The meaning of TSU seems to me pretty clear: it is the entity signing
>>> the time stamp token.
>>>     
>>
>> You see, already here you loose me.
>>
>> How can a "Unit" be an Entity? If so, how do you define entity?
>>
>> /Stefan
>>
>>
>>
>>
>>   
> 

-- 
Viele Grüße,
Johannes Merkle

Date: Thu, 12 Mar 2009 20:15:59 -0400
To: Paul Hoffman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Call for agenda items
Cc: Stefan Santesson <[email-masked]>, IETF-pkix <[email-masked]>
Sender: [email-masked]

At 9:49 AM -0700 3/12/09, Paul Hoffman wrote:
>At 3:13 AM +0100 3/12/09, Stefan Santesson wrote:
>>I lack information about 3 active WG documents:
>>  - New ASN.1
>
>We have posted a new draft addressing the WGLC comments, but do not 
>need to spend face-to-face time telling people that fact. We will 
>send out a request for people to re-check the modules soon but, 
>again, don't need to take up meeting time doing that.
>
>--Paul Hoffman, Director
>--VPN Consortium

Paul,

Please post a message describing the changes made in response to WGLC comments.

Thanks,

Steve

Date: Thu, 12 Mar 2009 19:00:04 +0100
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
From: Stefan Santesson <[email-masked]>
To: Alfredo Esposito <[email-masked]>
CC: <[email-masked]>
Sender: [email-masked]

I can understand that it is a plus for a policy document, but not for the
protocol standard, especially not when we are "updating" an existing
standard.

I could argue the same for PKI. When describing a certificate issuing
service from a policy perspective I may want to distinguish between the
legal entity responsible for the service, the RA, the cryptographic modules
and the keys. But for the sake of defining the certificate standard, we only
have one entity (the certificate issuer a.k.a. The CA).

/Stefan

On 3/12/09 6:23 PM, "Alfredo Esposito" <[email-masked]> wrote:

> 
> Stefan
> Sure, for the mere description of the protocol we just need a
> "time-stamp" responder (may be the best term), unaware of the technical
> implementation and of any way the responder is organized.
> Nevertheless, IMHO, distinguishing among the physical responder and the
> organization ("the authority") liable for the service was a plus.
> 
> 
> 
> Stefan Santesson wrote:
>> Alfredo,
>> 
>> It may seem that I'm kidding around with words, but to me it is larger than
>> that.
>> 
>> No your definition does not help convince me why I need three separate terms
>> to describe one entity of a protocol, unless they are distinguished in the
>> protocol bits on the wire.
>> 
>> If the protocol could be defined for a TSA, and the bits on the wire are the
>> same today, except for the CertID, then why do I have to split the entity
>> into three separate terms. It's just confusing.
>> 
>> Where is the benefit?
>> 
>> /Stefan
>> 
>> 
>> 
>> On 3/12/09 5:27 PM, "Alfredo Esposito" <[email-masked]> wrote:
>> 
>>   
>>> I love joking with the words in my own language, but my English is not
>>> smart enough
>>> TSU is the subject of a X.509 public key certificate and the
>>> corresponding private key is used to sign time-stamp-token compliant
>>> with IETF RFC 3161
>>> Is it better?
>>> 
>>> 
>>> Stefan Santesson wrote:
>>>     
>>>> Alfred,
>>>> 
>>>>   
>>>>       
>>>>> The meaning of TSU seems to me pretty clear: it is the entity signing
>>>>> the time stamp token.
>>>>>     
>>>>>         
>>>> You see, already here you loose me.
>>>> 
>>>> How can a "Unit" be an Entity? If so, how do you define entity?
>>>> 
>>>> /Stefan
>>>> 
>>>> 
>>>> 
>>>> 
>>>>   
>>>>       
>> 
>> 
>> 
>>   
> 

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-pkix"<[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Date: Thu, 12 Mar 2009 18:27:20 +0100
Sender: [email-masked]

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

Stefan,

When you use the TSP (P =3D Protocol), you talk to a service (in this cas=
e,  a Time Stamping Service).

You will get a response from one of the TSUs behind that service.

If the request is sucessful, the TST is signed by a TSU.

Every TSU is managed by a TSA.

Denis

----- Message re=E7u -----=20
De : owner-ietf-pkix=20
=C0 : Alfredo Esposito=20
Date : 2009-03-12, 17:49:08
Sujet : Re: draft-ietf-pkix-rfc3161bis-01.txt

Alfredo,

It may seem that I'm kidding around with words, but to me it is larger th=
an
that.

No your definition does not help convince me why I need three separate te=
rms
to describe one entity of a protocol, unless they are distinguished in th=
e
protocol bits on the wire.

If the protocol could be defined for a TSA, and the bits on the wire are =
the
same today, except for the CertID, then why do I have to split the entity
into three separate terms. It's just confusing.

Where is the benefit?

/Stefan

On 3/12/09 5:27 PM, "Alfredo Esposito" <[email-masked]> wro=
te:

> I love joking with the words in my own language, but my English is not
> smart enough
> TSU is the subject of a X.509 public key certificate and the
> corresponding private key is used to sign time-stamp-token compliant
> with IETF RFC 3161
> Is it better?
>=20
>=20
> Stefan Santesson wrote:
>> Alfred,
>>=20
>>=20
>>> The meaning of TSU seems to me pretty clear: it is the entity signing
>>> the time stamp token.
>>>=20
>>=20
>> You see, already here you loose me.
>>=20
>> How can a "Unit" be an Entity? If so, how do you define entity?
>>=20
>> /Stefan
>>=20
>>=20
>>=20
>>=20
>>=20

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

<HTML><HEAD><TITLE></TITLE>
<META content=3D"KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, =A9 Kurt=
 Senfer"=20
name=3DGENERATOR>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-=
1"></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=3D5 topMa=
rgin=3D5=20
#ffffff>
<DIV>Stefan,</DIV>
<DIV>&nbsp;</DIV>
<DIV>When you use&nbsp;the TSP (P =3D Protocol), you talk to a service (i=
n this=20
case,&nbsp; a Time Stamping Service).</DIV>
<DIV>&nbsp;</DIV>
<DIV>You will get a response from one of the TSUs behind that service.</D=
IV>
<DIV>&nbsp;</DIV>
<DIV>If the request is sucessful, the TST is signed by a TSU.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Every TSU is managed by a TSA.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-=
LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal">-----=20
  Message re=E7u ----- </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE=
-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: bl=
ack"><B>De=20
  :</B> <A href=3D"mailto :[email-masked]">owner-ietf-pkix<=
/A>=20
</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>=C0=20
  :</B> <A href=3D"mailto :[email-masked]">Alfredo Esposito=
</A>=20
  </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Date=20
  :</B> 2009-03-12, 17:49:08</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Sujet=20
  :</B> Re: draft-ietf-pkix-rfc3161bis-01.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>Alfredo,<BR><BR>It may seem that I'm kidding around with words, bu=
t to me=20
  it is larger than<BR>that.<BR><BR>No your definition does not help conv=
ince me=20
  why I need three separate terms<BR>to describe one entity of a protocol=
,=20
  unless they are distinguished in the<BR>protocol bits on the wire.<BR><=
BR>If=20
  the protocol could be defined for a TSA, and the bits on the wire are=20
  the<BR>same today, except for the CertID, then why do I have to split t=
he=20
  entity<BR>into three separate terms. It's just confusing.<BR><BR>Where =
is the=20
  benefit?<BR><BR>/Stefan<BR><BR><BR><BR>On 3/12/09 5:27 PM, "Alfredo Esp=
osito"=20
  &lt;<A=20
  href=3D"mailto: [email-masked]">alfredo.esposito@infocert=
.it</A>&gt;=20
  wrote:<BR><BR>&gt; I love joking with the words in my own language, but=
 my=20
  English is not<BR>&gt; smart enough<BR>&gt; TSU is the subject of a X.5=
09=20
  public key certificate and the<BR>&gt; corresponding private key is use=
d to=20
  sign time-stamp-token compliant<BR>&gt; with IETF RFC 3161<BR>&gt; Is i=
t=20
  better?<BR>&gt; <BR>&gt; <BR>&gt; Stefan Santesson wrote:<BR>&gt;&gt;=20
  Alfred,<BR>&gt;&gt; <BR>&gt;&gt; <BR>&gt;&gt;&gt; The meaning of TSU se=
ems to=20
  me pretty clear: it is the entity signing<BR>&gt;&gt;&gt; the time stam=
p=20
  token.<BR>&gt;&gt;&gt; <BR>&gt;&gt; <BR>&gt;&gt; You see, already here =
you=20
  loose me.<BR>&gt;&gt; <BR>&gt;&gt; How can a "Unit" be an Entity? If so=
, how=20
  do you define entity?<BR>&gt;&gt; <BR>&gt;&gt; /Stefan<BR>&gt;&gt;=20
  <BR>&gt;&gt; <BR>&gt;&gt; <BR>&gt;&gt; <BR>&gt;&gt;=20
  <BR><BR><BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_09031218271969540460310_002--

Date: Thu, 12 Mar 2009 18:23:37 +0100
From: Alfredo Esposito <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Sender: [email-masked]

Stefan
Sure, for the mere description of the protocol we just need a 
"time-stamp" responder (may be the best term), unaware of the technical 
implementation and of any way the responder is organized.
Nevertheless, IMHO, distinguishing among the physical responder and the 
organization ("the authority") liable for the service was a plus.

Stefan Santesson wrote:
> Alfredo,
>
> It may seem that I'm kidding around with words, but to me it is larger than
> that.
>
> No your definition does not help convince me why I need three separate terms
> to describe one entity of a protocol, unless they are distinguished in the
> protocol bits on the wire.
>
> If the protocol could be defined for a TSA, and the bits on the wire are the
> same today, except for the CertID, then why do I have to split the entity
> into three separate terms. It's just confusing.
>
> Where is the benefit?
>
> /Stefan
>
>
>
> On 3/12/09 5:27 PM, "Alfredo Esposito" <[email-masked]> wrote:
>
>   
>> I love joking with the words in my own language, but my English is not
>> smart enough
>> TSU is the subject of a X.509 public key certificate and the
>> corresponding private key is used to sign time-stamp-token compliant
>> with IETF RFC 3161
>> Is it better?
>>
>>
>> Stefan Santesson wrote:
>>     
>>> Alfred,
>>>
>>>   
>>>       
>>>> The meaning of TSU seems to me pretty clear: it is the entity signing
>>>> the time stamp token.
>>>>     
>>>>         
>>> You see, already here you loose me.
>>>
>>> How can a "Unit" be an Entity? If so, how do you define entity?
>>>
>>> /Stefan
>>>
>>>
>>>
>>>
>>>   
>>>       
>
>
>
>   

Date: Thu, 12 Mar 2009 17:49:08 +0100
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
From: Stefan Santesson <[email-masked]>
To: Alfredo Esposito <[email-masked]>
CC: Peter Sylvester <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Alfredo,

It may seem that I'm kidding around with words, but to me it is larger than
that.

No your definition does not help convince me why I need three separate terms
to describe one entity of a protocol, unless they are distinguished in the
protocol bits on the wire.

If the protocol could be defined for a TSA, and the bits on the wire are the
same today, except for the CertID, then why do I have to split the entity
into three separate terms. It's just confusing.

Where is the benefit?

/Stefan

On 3/12/09 5:27 PM, "Alfredo Esposito" <[email-masked]> wrote:

> I love joking with the words in my own language, but my English is not
> smart enough
> TSU is the subject of a X.509 public key certificate and the
> corresponding private key is used to sign time-stamp-token compliant
> with IETF RFC 3161
> Is it better?
> 
> 
> Stefan Santesson wrote:
>> Alfred,
>> 
>>   
>>> The meaning of TSU seems to me pretty clear: it is the entity signing
>>> the time stamp token.
>>>     
>> 
>> You see, already here you loose me.
>> 
>> How can a "Unit" be an Entity? If so, how do you define entity?
>> 
>> /Stefan
>> 
>> 
>> 
>> 
>>   

Date: Thu, 12 Mar 2009 09:49:12 -0700
To: Stefan Santesson <[email-masked]>, IETF-pkix <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Call for agenda items
Sender: [email-masked]

At 3:13 AM +0100 3/12/09, Stefan Santesson wrote:
>I lack information about 3 active WG documents:
> - New ASN.1

We have posted a new draft addressing the WGLC comments, but do not need to spend face-to-face time telling people that fact. We will send out a request for people to re-check the modules soon but, again, don't need to take up meeting time doing that.

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 12 Mar 2009 17:27:53 +0100
From: Alfredo Esposito <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Peter Sylvester <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Sender: [email-masked]

I love joking with the words in my own language, but my English is not 
smart enough
TSU is the subject of a X.509 public key certificate and the 
corresponding private key is used to sign time-stamp-token compliant 
with IETF RFC 3161
Is it better?

Stefan Santesson wrote:
> Alfred,
>
>   
>> The meaning of TSU seems to me pretty clear: it is the entity signing
>> the time stamp token.
>>     
>
> You see, already here you loose me.
>
> How can a "Unit" be an Entity? If so, how do you define entity?
>
> /Stefan
>
>
>
>
>   

Date: Thu, 12 Mar 2009 15:14:02 +0100
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
From: Stefan Santesson <[email-masked]>
To: Alfredo Esposito <[email-masked]>
CC: Peter Sylvester <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Alfred,

> The meaning of TSU seems to me pretty clear: it is the entity signing
> the time stamp token.

You see, already here you loose me.

How can a "Unit" be an Entity? If so, how do you define entity?

/Stefan

Date: Thu, 12 Mar 2009 15:23:56 +0100
From: Peter Sylvester <[email-masked]>
To: Alfredo Esposito <[email-masked]>
Cc: Stefan Santesson <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Sender: [email-masked]

Alfredo Esposito wrote:
> The meaning of TSU seems to me pretty clear: it is the entity signing 
> the time stamp token. For example, my company runs several Time stamp 
> services, each based on more than one different signing unit, for 
> performance and availability. An organization (i.e. an Authorithy) can 
> offer different time stamp services with different policies, so that TST 
> are signed with different keys. At the same time, defining different 
> roles does not forbid to collapse all in one. I don't see the problem.

A small paragraph allowing a reader to better distinguish the technical
term from some organisational usage may be sufficient. This is similar
as for the definition of an RA and CA. When used as technical terms,
a CA is simply a signing device, and a TSA is simply a 'signing device that
adds some time.'

... some text removed

> Stefan Santesson wrote:

... some text removed

>> A more thorough discussion is needed here. My current view is that we
>> probably should revert completely back to the text of RFC 3161 and 
>> then just
>> do a minimum of technically well motivated changes. At this time I oppose
>> terminology alignment to RFC 3628.

I fully agree with this.

The text should be just have an update for the ESSSigningCertV2.

I mentioned also some unclear text concerning the socket protocol.

>> /Stefan

Date: Thu, 12 Mar 2009 14:03:43 +0100
From: Alfredo Esposito <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Peter Sylvester <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
Sender: [email-masked]

The meaning of TSU seems to me pretty clear: it is the entity signing 
the time stamp token. For example, my company runs several Time stamp 
services, each based on more than one different signing unit, for 
performance and availability. An organization (i.e. an Authorithy) can 
offer different time stamp services with different policies, so that TST 
are signed with different keys. At the same time, defining different 
roles does not forbid to collapse all in one. I don't see the problem.
Some suggestions for the draft
I would remove the first part of section 3.3 (identification of the TSU) 
related to the TSU name since it seems outside the scope of the document 
(named Time stamp PROTOCOL) and more suitable for a profile document 
(strictly speaking also the prescription of the EKU would be out of 
scope, but it was already there in the RFC 3161).
--Introduction
-replace
The TSA can  also be used to indicate the time of submission when a 
deadline is critical, or to indicate the time of transaction for entries 
in a  log.  An exhaustive list of possible uses of a TSU is beyond the 
scope of this document.
-with
A time-stamp can also be used to indicate the time of submission when a 
deadline is critical, or to indicate the time of transaction for entries 
in a  log.  An exhaustive list of possible uses of a time-stamps scope 
of this document.
--Definitions
-replace
time-stamping authority: authority which issues time-stamp tokens.
-with
time-stamping authority: authority responsible of issuing time-stamp tokens.

Stefan Santesson wrote:
> I would like to line up and express my concerns regarding the direction of
> this document.
>
> In principle I'm worried about the fundamental changes of concept and
> terminology made in the update of an existing IETF standard.
>
> While 3161 used TSA (Time Stamping Authority) as a collective term, 3161bis
> uses three different terms:
>
> TSA - TS Authority
> TSU - TS Unit
> TSS - TS Service
>
> This is extremely confusing to me and appears unnecessary distinctions for
> the sake of defining a protocol.
>
> The change is motivated by RFC 3628 which has been upgraded as Normative.
> But RFC 3628 is an Informational policy document and should never be
> normative over the protocol standard.
>
> I see several mixes of these new terms that appears confusing to me. For
> example TSU is mentioned as being responsible for things where I would
> suspect that any responsibility must reside with a TSA.
>
> In section 4.3 the body text talk about TSU Messages, but the protocol
> definitions define TSA Messages.
>
> And it goes on like that throughout the document.
>
> A more thorough discussion is needed here. My current view is that we
> probably should revert completely back to the text of RFC 3161 and then just
> do a minimum of technically well motivated changes. At this time I oppose
> terminology alignment to RFC 3628.
>
> /Stefan
>
>
>
> On 3/4/09 6:22 PM, "Peter Sylvester" <[email-masked]> wrote:
>
>   
>> I had the impression that thegoal of that texwt was an update
>> concerning hash algorithms.
>>
>>
>> One could expecte it would only contain an update to the ESScertid using
>> ESSCertidV2 etc.
>>
>> The actual texts corresponds roughly to an expired draft some
>> years ago.
>>
>>         - the document has been aligned with RFC 3628 to make the
>>           difference between a time-stamping unit (TSU) and a TSA.
>>
>> Thus, the text is not a small update of 3161 but introduces several
>> new items, some of them seems questionable to me. Some problems
>> which had been mentioned with RFC 3161 in the past, have not been
>> addressed.
>>
>> In 3161, a TSA is merely a technical service similar to what is
>> said in 3161bis for a TSU. A TSA in 3161bis does not really
>> have a defined technical role.
>>
>> On the other hand the field tsa in a response refers to a TSA,
>> and to a certficate that validates it. But a TSA does no longer
>> have a certificate, only TSUs.
>>
>> As a consequence, the following paragraph cannot mention TSA
>> but at best a TSU.
>> Besides that it should also mentiion ESSCertIDv2.)
>>
>>     The purpose of the tsa field is to give a hint in identifying the
>>     name of the TSA.  If present, it MUST correspond to one of the
>>     subject names included in the certificate that is to be used to
>>     verify the token.  However, the actual identification of the entity
>>     that signed the response will always occur through the use of the
>>     certificate identifier (ESSCertID Attribute) inside a
>>     SigningCertificate attribute which is part of the signerInfo
>>     (See Section 5 of [ESS]).
>>
>>
>> Chapter 3.3 does not use the 2119 terminology in the first phrase but
>> rather the ISO terminoilogy. 3.3 is not relevant for the function of
>> a time stamp service. (Although it is likely that TSA actually
>> have filled all the REQUIRED 'shall) attributes in the DN)
>>
>> The following text is extremely fuzzy:
>>
>>     The name of the issuing TSU shall contain an appropriate subset of
>>     the following attributes (defined in ISO 9594-6 [ISO9594-6] and
>>     ITU-T Recommendation X.520 [X.520]):
>>
>>         - countryName;
>>         - stateOrProvinceName;
>>         - organizationName;
>>         - commonName.
>>
>> What means "appropriate subset". The text does not exclude
>> other attributs. So in fact, it says: The TSU MUST have a subjectDN?
>>
>> It is not defined what name identifies a TSA? for example, everything except
>> the common name?
>>
>> 4.3 :
>>
>> As it had been mentioned before the socket protocol as it is defined
>> has some problems: Since it was taken texto from CMP, there are some features
>> that are may require some complexity in clients:
>> Only 00, 05, and 06 seem useful to me. If a TSA/U is not able to sign
>> a response within a few milliseconds with a TCP connection kept open,
>> I wouldn't call this a service.
>> For HTTP, a server cannot return a poll indication as a comparison.
>>
>> If a client does not send a pollReq, what will happen with a pending
>> response?
>>
>> The protocol does not specify who terminates the connection. Is it the
>> server that closes after one exchange?
>>
>> If multiple requests and responses can be exchanged over the same connection,
>> what is the dialogue model? request/response, pipelining, etc?
>>
>> What is a TSU message? I think it should be TSP message. Old text was
>> TSA, which was also somewhat wrong.
>>
>> Security section point 1 seems not quite correct:
>>
>> Instead of :
>> it SHALL be set either to unspecified (0), affiliationChanged (3),
>>        superseded (4) or cessationOfOperation (5).  In that case,
>>
>> it should say
>>
>> In the case when the reasonCode is set to either
>>        affiliationChanged (3),
>>        superseded (4) or cessationOfOperation (5)
>>
>> Unspecified means that ther can be a key compromise IMO?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     
>
>
>
>   

Date: Thu, 12 Mar 2009 03:13:45 +0100
Subject: Re: Call for agenda items
From: Stefan Santesson <[email-masked]>
To: IETF-pkix <[email-masked]>
Sender: [email-masked]

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

--B_3319672426_2560708
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

The preliminary agenda is posted.

http://www.ietf.org/proceedings/09mar/agenda/pkix.txt

I lack information about 3 active WG documents:
 - 3161bis (Time stamping),
 - New ASN.1
 - SHA2 for DSA and ECDSA

Please let me know if anyone is presenting anything bout these document
status.
Also, we are having the Monday Morning session. In order for me to be able
to prepare for the meeting, I would like the slides of all presenters before
1700 (5 pm) on Sunday March 22

Thank you.

Stefan Santesson
AAA-sec.com

On 3/3/09 12:29 PM, "Stefan Santesson" <[email-masked]> wrote:

> IETF in San Francisco is coming up.
> 
> PKIX has a 2.5 hour session directly on the Monday morning March 23 at 0900
> 
> Please let me know if you have anything you whish to present at the meeting.
> At least one representative of each active WG document MUST inform me if you
> need a time slot for that document or not.
>  
> I would like to have your request for timeslot by Wednesday March 11.
> After that we can always do late adjustments but I appreciate to have your
> request as early as possible.
> 
> Thank you.
> 
> /Stefan

--B_3319672426_2560708
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Call for agenda items</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>The preliminary agenda is posted.<BR>
<BR>
<a href=3D"http://www.ietf.org/proceedings/09mar/agenda/pkix.txt">http://www.=
ietf.org/proceedings/09mar/agenda/pkix.txt</a><BR>
<BR>
I lack information about 3 active WG documents: <BR>
&nbsp;- 3161bis (Time stamping), <BR>
&nbsp;- New ASN.1<BR>
&nbsp;- SHA2 for DSA and ECDSA<BR>
<BR>
Please let me know if anyone is presenting anything bout these document sta=
tus.<BR>
Also, we are having the Monday Morning session. In order for me to be able =
to prepare for the meeting, I would like the slides of all presenters before=
 1700 (5 pm) on Sunday March 22 <BR>
<BR>
Thank you.<BR>
</SPAN></FONT><FONT COLOR=3D"#333333"><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verd=
ana, Helvetica, Arial"><SPAN STYLE=3D'font-size:10pt'><BR>
</SPAN></FONT></FONT></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FO=
NT COLOR=3D"#008080"><FONT FACE=3D"Cambria"><B>Stefan Santesson<BR>
</B></FONT></FONT><FONT FACE=3D"Cambria">AAA-sec.com<BR>
<BR>
<BR>
<BR>
</FONT></SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:11pt'><BR>
<BR>
<BR>
On 3/3/09 12:29 PM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefans@exmsf=
t.com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>IETF in San Francisco is coming up.<BR>
<BR>
PKIX has a 2.5 hour session directly on the Monday morning March 23 at 0900=
<BR>
<BR>
Please let me know if you have anything you whish to present at the meeting=
.<BR>
<B><U>At least one representative of each active WG document MUST inform me=
 if you need a time slot for that document or not.<BR>
</U></B> <BR>
I would like to have your request for timeslot by Wednesday March 11.<BR>
After that we can always do late adjustments but I appreciate to have your =
request as early as possible.<BR>
<BR>
Thank you.<BR>
<BR>
/Stefan<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3319672426_2560708--

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-tamp-01.txt 
Date: Wed, 11 Mar 2009 16:56:24 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Carl Wallace" <[email-masked]>, "max pritikin" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Would it be more accurate to say that signer of TAMP messages must be a
management TA or the signer's certification path must terminate at a
management TA.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Carl Wallace
> Sent: Wednesday, March 11, 2009 3:48 PM
> To: max pritikin; [email-masked]
> Subject: RE: I-D Action:draft-ietf-pkix-tamp-01.txt=20
>=20
>=20
> <snip>
> > The latest [TAF] document appear to move away from specifically
> categorizing Apex, Management and Identity trust=20
> > anchors. I agree with this change. The [TAMP] draft still indicates
> these three types though and I no longer see how=20
> > they are distinguished. I do see that [TAMP, Section 1.3.2]=20
> indicates
> that:
> >   o  The trust anchor store MUST support the secure storage=20
> of exactly
> >     one apex trust anchor.  The trust anchor store SHOULD=20
> support the
> >     secure storage of at least one additional trust anchor.=20
> > but not how it is identified as the Apex. Or as a management trust
> anchor, or identity trust anchor. Is it expected that > this=20
> information would be encoded into the TAF extensions=20
> field[s]? For example TAMP would specify a specific extension=20
> > with these types indicated?
>=20
> The terms describe the function of a trust anchor, not=20
> necessarily its composition.
>=20
> A trust anchor is identified as the apex by placement,=20
> similar to a certificate that is recognized as a trust anchor=20
> by placing it in a trust anchor store.  The presence of a=20
> Apex trust anchor info certificate extension is a clue, but=20
> placement is what makes a trust anchor an apex.  This will be=20
> clarified in the next draft.
>=20
> An identity TA must be able to validate certification paths,=20
> so it must have name.  In an environment using the CCC spec=20
> for authorization, a management trust anchor would contain a=20
> CCC extension.  Other authorization mechanisms may have=20
> different hallmarks.
>=20
> <snip>
>=20
> > I like the idea of a TAF which can store information specific to
> particular applications, various management protocols=20
> > such as CMS, and other things moving forward. TAMP apparently then
> specifies specific authorizations and their meanings=20
> > but this doesn't limit or impact other uses? And=20
> importantly this type
> of construct results in a TAF which may be either=20
> > Apex, Management, or Identity or any combination thereof=20
> including new
> types in the future?
>=20
> Right.  TAs can be any combination of TA types (except that=20
> an apex is by definition a management TA) and could address=20
> various management protocols (like CMS) are defined.
>=20
> > This line of thought leads to some reflection on the [TAMP]=20
> discussion
> illustrated by Figure 4-1 might be even further >=20
> > refined. I appreciate the update from "Crypto Module" to=20
> "Trust Anchor
> Store" -- or maybe even a combination of the two=20
> > of them (this echoes my comment above about how the 802.1AR module
> sounds like a combination of both of these elements).=20
> > Perhaps my confusion is that in my mind a Trust Anchor Manager is
> communicating via TAMP with a TAMP service which is=20
> > then accessing the Trust Anchor Store. A picture is worth a thousand
> words:
>=20
>=20
> (my apologies if mail messes this up)
>       +---------+      +----------+
>       |         |      |          |
>       |         |      |          |
>       |         |      |          |
>       |         | TAMP |          |
>       | Trust   |<---->| TAMP     |
>       | Anchor  |      | Process  | OS & Application
>       | Manager |      |          | Service Interface
>       |         |      |          |      +----------+
>       |         |      |          |<---->|TAFs in a |
>       |         |      |          |      |Crypto    |
>       |         |      |          |      |Module    |
>       |         |      |          |      |& Store   |
>       +---------+      +----------+      +----------+
>=20
>=20
> > I haven't seen a discussion that the "OS & Application Service
> Interface" as being in scope. Drawing the diagram like >=20
> > this clarifies my impression that the TAF might be used by other
> applications and that those applications might benefit=20
> > from the TAF standardization. Given the recent changes to [TAF] I
> suspect things are moving in this direction?
>=20
> The diagram above is an accurate representation.  You are=20
> correct that the specs do not address the interface between=20
> the TA store and the applications.  Not shown in the diagram=20
> is how the TA is actually used (i.e., what an application=20
> does with a trust anchor once it retrieves it from the=20
> store).  There will be another short specification submitted=20
> soon that describes how to use TA-based constraints during=20
> certification path validation.
>=20
>=20

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-tamp-01.txt 
Date: Wed, 11 Mar 2009 15:47:50 -0400
From: "Carl Wallace" <[email-masked]>
To: "max pritikin" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

<snip>
> The latest [TAF] document appear to move away from specifically
categorizing Apex, Management and Identity trust=20
> anchors. I agree with this change. The [TAMP] draft still indicates
these three types though and I no longer see how=20
> they are distinguished. I do see that [TAMP, Section 1.3.2] indicates
that:
>   o  The trust anchor store MUST support the secure storage of exactly
>     one apex trust anchor.  The trust anchor store SHOULD support the
>     secure storage of at least one additional trust anchor.=20
> but not how it is identified as the Apex. Or as a management trust
anchor, or identity trust anchor. Is it expected that > this information
would be encoded into the TAF extensions field[s]? For example TAMP
would specify a specific extension > with these types indicated?

The terms describe the function of a trust anchor, not necessarily its
composition.

A trust anchor is identified as the apex by placement, similar to a
certificate that is recognized as a trust anchor by placing it in a
trust anchor store.  The presence of a Apex trust anchor info
certificate extension is a clue, but placement is what makes a trust
anchor an apex.  This will be clarified in the next draft.

An identity TA must be able to validate certification paths, so it must
have name.  In an environment using the CCC spec for authorization, a
management trust anchor would contain a CCC extension.  Other
authorization mechanisms may have different hallmarks.

<snip>

> I like the idea of a TAF which can store information specific to
particular applications, various management protocols=20
> such as CMS, and other things moving forward. TAMP apparently then
specifies specific authorizations and their meanings=20
> but this doesn't limit or impact other uses? And importantly this type
of construct results in a TAF which may be either=20
> Apex, Management, or Identity or any combination thereof including new
types in the future?

Right.  TAs can be any combination of TA types (except that an apex is
by definition a management TA) and could address various management
protocols (like CMS) are defined.

> This line of thought leads to some reflection on the [TAMP] discussion
illustrated by Figure 4-1 might be even further >=20
> refined. I appreciate the update from "Crypto Module" to "Trust Anchor
Store" -- or maybe even a combination of the two=20
> of them (this echoes my comment above about how the 802.1AR module
sounds like a combination of both of these elements).=20
> Perhaps my confusion is that in my mind a Trust Anchor Manager is
communicating via TAMP with a TAMP service which is=20
> then accessing the Trust Anchor Store. A picture is worth a thousand
words:

(my apologies if mail messes this up)
      +---------+      +----------+
      |         |      |          |
      |         |      |          |
      |         |      |          |
      |         | TAMP |          |
      | Trust   |<---->| TAMP     |
      | Anchor  |      | Process  | OS & Application
      | Manager |      |          | Service Interface
      |         |      |          |      +----------+
      |         |      |          |<---->|TAFs in a |
      |         |      |          |      |Crypto    |
      |         |      |          |      |Module    |
      |         |      |          |      |& Store   |
      +---------+      +----------+      +----------+

> I haven't seen a discussion that the "OS & Application Service
Interface" as being in scope. Drawing the diagram like >=20
> this clarifies my impression that the TAF might be used by other
applications and that those applications might benefit=20
> from the TAF standardization. Given the recent changes to [TAF] I
suspect things are moving in this direction?

The diagram above is an accurate representation.  You are correct that
the specs do not address the interface between the TA store and the
applications.  Not shown in the diagram is how the TA is actually used
(i.e., what an application does with a trust anchor once it retrieves it
from the store).  There will be another short specification submitted
soon that describes how to use TA-based constraints during certification
path validation.

Content-class: urn:content-classes:message
Subject: Suite B Certificate & CRL Profile
Date: Wed, 11 Mar 2009 15:38:11 -0400
From: "Zieglar, Lydia L." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9A280.E9BFD97D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We have recently submitted the next revision of the National Security
Agency's Suite B Certificate and CRL Profile to the IETF as an
Internet-Draft (individual submission).
=20
We encourage you to review the document and send comments to Lydia
Zieglar at [email-masked]
=20
You may find the document at:
=20
http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-profile-01
.txt
=20
Thanks,
Lydia Zieglar
=20
Lydia Zieglar
301-688-1028
[email-masked]
=20

------_=_NextPart_001_01C9A280.E9BFD97D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D464003319-11032009>We =
have recently=20
submitted the next revision of the National Security Agency's Suite B=20
Certificate and CRL Profile to the IETF as an Internet-Draft (individual =

submission).</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D464003319-11032009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D464003319-11032009>We =
encourage you to=20
review the document and send comments to Lydia Zieglar at <A=20
href=3D"mailto:[email-masked]">[email-masked]</A></SPAN><=
/FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D464003319-11032009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D464003319-11032009>You =
may find the=20
document at:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D464003319-11032009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-pro=
file-01.txt">http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cer=
t-profile-01.txt</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D464003319-11032009><FONT face=3DArial=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D464003319-11032009><FONT face=3DArial size=3D2>Lydia=20
Zieglar</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Lydia Zieglar</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>301-688-1028</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial =
size=3D2>[email-masked]</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C9A280.E9BFD97D--

Date: Wed, 11 Mar 2009 20:08:09 +0100
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
From: Stefan Santesson <[email-masked]>
To: Santosh Chokhani <[email-masked]>, ietf-pkix <[email-masked]>
Sender: [email-masked]

On the name issue I don't think names need to be mandatory.

If we for a second set aside what is right and pure and standards compliant
and stick to what is needed from a pure cryptographic and security
viewpoint, then there is no need for exact name matching in X.509 path
validation.

Long before UTF-8, name mismatch of Issuer/subject names in path processing
was a real problem. Some for example used T.61 Teletex to tag a string
carrying Latin-1 characters.

What many implementers did, including Microsoft, in order to be "liberal in
what you accept" was to ignore name mismatch as long as keys of the path
matched (could be used to validate certificates in the path). There was no
security problem with it and it worked a lot better.

So basically, I'm also fine with an optional DN.

/Stefan

On 3/8/09 1:24 AM, "Santosh Chokhani" <[email-masked]> wrote:

> 
> If making name optional meets the requirements of multiple environment,
> then it is a better standard than making it mandatory.
> 
> As to memory challenged, I encourage you to speak with some real
> implementers as they move their hardware tokens from 1024 bits to 2048
> bits RSA.  They do need bigger and costlier cards.  So, memory in all
> form factors is not free.
> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Eric Norman
>> Sent: Friday, March 06, 2009 3:59 PM
>> To: ietf-pkix
>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>> 
>> 
>> 
>> On Mar 6, 2009, at 2:17 PM, Santosh Chokhani wrote:
>> 
>>> 
>>> There are environments where the device may be space
>> challenged and/or
>>> the communication environment may be bandwidth challenged.
>>> 
>>> Thus, having only the required information in trust anchors
>> and TAMP 
>>> will be helpful.
>> 
>> Really?  How many bytes can be stored on a ESB memory stick nowadays?
>> How many bits can be stored in one square millimeter
>> nowadays?  How much time does it take to transfer a few
>> thousand bytes with USB or Bluetooth nowadays?  Are you
>> seriously suggesting that we need to design for folks whose
>> environment includes carrier pigeons or tin cans and string
>> as their communication mechanism?
>> 
>> TAMP may indeed be useful, but not in the area of saving resources.
>> Where it can be useful is to make it clearer which
>> information is necessary and which information can be ignored
>> for something to be a trust anchor and under what circumstances.
>> 
>> Eric Norman
>> 
>> 
> 

Date: Wed, 11 Mar 2009 13:56:14 +0100
Subject: Re: Call for agenda items & PRQP
From: Stefan Santesson <[email-masked]>
To: Massimiliano Pala <[email-masked]>, Stephen Kent <[email-masked]>, pkix <[email-masked]>
Sender: [email-masked]

Max,

What you say is very interesting. First of all sort out the IANA issue.
Secondly we should discuss a possible upgrade of this document to standards
track based on the deployment.

You have your time slot.

/Stefan

On 3/5/09 12:31 PM, "Massimiliano Pala" <[email-masked]>
wrote:

> Ciao Stefan, Steve, and pkix-wg,
> 
> I would need 10 mins for reporting on the activities about PRQP - we have been
> working both with the TERENA (TACAR) and Federal Bridge folks and they are
> going
> to deploy PRQP (at least as experimental). Some interest in the PRQP has also
> been expressed by some commercial vendors... so I think that the WG should be
> informed of these activities.
> 
> Also, from the collaboration with the DHC WG, we have changed the draft and it
> seems that we need IANA to assign identifiers for DHCP (both v4 and v6).
> 
> One concern that I have is that IANA would not be so keen in assigning DHCP
> service identifiers for an experimental-track protocol, but the deployment
> of PRQP is actually happening and I would like to have at least those
> identifiers
> standardized before this actually happens. I am not sure about what we shall
> do
> now. The PRQP will be included in the next release of OpenCA as well,
> therefore
> there will soon be a quite large installation base (besides the aforementioned
> communities).
> 
> Shall we move the status from experimental to standard track ? Is it too early
> ?
> I see that within the WG there is not much activity about PRQP, but in the
> real
> PKI world and Computing Grid communities the situation is different.
> 
> I would like to know the opinion of the chair(s) and the people in the WG...
> 
> Ciao,
> Max
> 
> 
> Stefan Santesson wrote:
>> IETF in San Francisco is coming up.
>> 
>> PKIX has a 2.5 hour session directly on the Monday morning March 23 at 0900
>> 
>> Please let me know if you have anything you whish to present at the meeting.
>> *_At least one representative of each active WG document MUST inform me
>> if you need a time slot for that document or not.
>> _*
>> I would like to have your request for timeslot by Wednesday March 11.
>> After that we can always do late adjustments but I appreciate to have
>> your request as early as possible.

Date: Wed, 11 Mar 2009 10:23:54 +0100
Subject: Re: draft-ietf-pkix-rfc3161bis-01.txt
From: Stefan Santesson <[email-masked]>
To: Peter Sylvester <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I would like to line up and express my concerns regarding the direction of
this document.

In principle I'm worried about the fundamental changes of concept and
terminology made in the update of an existing IETF standard.

While 3161 used TSA (Time Stamping Authority) as a collective term, 3161bis
uses three different terms:

TSA - TS Authority
TSU - TS Unit
TSS - TS Service

This is extremely confusing to me and appears unnecessary distinctions for
the sake of defining a protocol.

The change is motivated by RFC 3628 which has been upgraded as Normative.
But RFC 3628 is an Informational policy document and should never be
normative over the protocol standard.

I see several mixes of these new terms that appears confusing to me. For
example TSU is mentioned as being responsible for things where I would
suspect that any responsibility must reside with a TSA.

In section 4.3 the body text talk about TSU Messages, but the protocol
definitions define TSA Messages.

And it goes on like that throughout the document.

A more thorough discussion is needed here. My current view is that we
probably should revert completely back to the text of RFC 3161 and then just
do a minimum of technically well motivated changes. At this time I oppose
terminology alignment to RFC 3628.

/Stefan

On 3/4/09 6:22 PM, "Peter Sylvester" <[email-masked]> wrote:

> 
> I had the impression that thegoal of that texwt was an update
> concerning hash algorithms.
> 
> 
> One could expecte it would only contain an update to the ESScertid using
> ESSCertidV2 etc.
> 
> The actual texts corresponds roughly to an expired draft some
> years ago.
> 
>         - the document has been aligned with RFC 3628 to make the
>           difference between a time-stamping unit (TSU) and a TSA.
> 
> Thus, the text is not a small update of 3161 but introduces several
> new items, some of them seems questionable to me. Some problems
> which had been mentioned with RFC 3161 in the past, have not been
> addressed.
> 
> In 3161, a TSA is merely a technical service similar to what is
> said in 3161bis for a TSU. A TSA in 3161bis does not really
> have a defined technical role.
> 
> On the other hand the field tsa in a response refers to a TSA,
> and to a certficate that validates it. But a TSA does no longer
> have a certificate, only TSUs.
> 
> As a consequence, the following paragraph cannot mention TSA
> but at best a TSU.
> Besides that it should also mentiion ESSCertIDv2.)
> 
>     The purpose of the tsa field is to give a hint in identifying the
>     name of the TSA.  If present, it MUST correspond to one of the
>     subject names included in the certificate that is to be used to
>     verify the token.  However, the actual identification of the entity
>     that signed the response will always occur through the use of the
>     certificate identifier (ESSCertID Attribute) inside a
>     SigningCertificate attribute which is part of the signerInfo
>     (See Section 5 of [ESS]).
> 
> 
> Chapter 3.3 does not use the 2119 terminology in the first phrase but
> rather the ISO terminoilogy. 3.3 is not relevant for the function of
> a time stamp service. (Although it is likely that TSA actually
> have filled all the REQUIRED 'shall) attributes in the DN)
> 
> The following text is extremely fuzzy:
> 
>     The name of the issuing TSU shall contain an appropriate subset of
>     the following attributes (defined in ISO 9594-6 [ISO9594-6] and
>     ITU-T Recommendation X.520 [X.520]):
> 
>         - countryName;
>         - stateOrProvinceName;
>         - organizationName;
>         - commonName.
> 
> What means "appropriate subset". The text does not exclude
> other attributs. So in fact, it says: The TSU MUST have a subjectDN?
> 
> It is not defined what name identifies a TSA? for example, everything except
> the common name?
> 
> 4.3 :
> 
> As it had been mentioned before the socket protocol as it is defined
> has some problems: Since it was taken texto from CMP, there are some features
> that are may require some complexity in clients:
> Only 00, 05, and 06 seem useful to me. If a TSA/U is not able to sign
> a response within a few milliseconds with a TCP connection kept open,
> I wouldn't call this a service.
> For HTTP, a server cannot return a poll indication as a comparison.
> 
> If a client does not send a pollReq, what will happen with a pending
> response?
> 
> The protocol does not specify who terminates the connection. Is it the
> server that closes after one exchange?
> 
> If multiple requests and responses can be exchanged over the same connection,
> what is the dialogue model? request/response, pipelining, etc?
> 
> What is a TSU message? I think it should be TSP message. Old text was
> TSA, which was also somewhat wrong.
> 
> Security section point 1 seems not quite correct:
> 
> Instead of :
> it SHALL be set either to unspecified (0), affiliationChanged (3),
>        superseded (4) or cessationOfOperation (5).  In that case,
> 
> it should say
> 
> In the case when the reasonCode is set to either
>        affiliationChanged (3),
>        superseded (4) or cessationOfOperation (5)
> 
> Unspecified means that ther can be a key compromise IMO?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

To: [email-masked], [email-masked]
Subject: RFC 5480 on Elliptic Curve Cryptography Subject Public Key Information
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 10 Mar 2009 11:12:19 -0700 (PDT)
Sender: [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 5480

        Title:      Elliptic Curve Cryptography Subject Public 
                    Key Information 
        Author:     S. Turner, D. Brown,
                    K. Yiu, R. Housley,
                    T. Polk
        Status:     Standards Track
        Date:       March 2009
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked],
                    [email-masked], 
                    [email-masked]
        Pages:      20
        Characters: 36209
        Updates:    RFC3279

        I-D Tag:    draft-ietf-pkix-ecc-subpubkeyinfo-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5480.txt

This document specifies the syntax and semantics for the Subject
Public Key Information field in certificates that support Elliptic
Curve Cryptography.  This document updates Sections 2.3.5 and 5, and
the ASN.1 module of "Algorithms and Identifiers for the Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

Date: Tue, 10 Mar 2009 14:07:20 -0400
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc4055-update-02.txt
Sender: [email-masked]

This draft addresses three IESG DISCUSS comments and one from the SECDIR 
review:

#1 There's now introductory text to explain the who, what, where and why 
of the changes.  Without the background from the proto write up there 
was little context for the changes.

#2 The changes in section 3 now affect both the 2nd and 3rd paragraph.

#3 There were some changes to the abstract.

#4 The security considerations was expanded.

spt

[email-masked] wrote:
> 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		: Update for RSAES-OAEP Algorithm Parameters
> 	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
> 	Filename	: draft-ietf-pkix-rfc4055-update-02.txt
> 	Pages		: 7
> 	Date		: 2009-3-9
> 	
> This document updates RFC 4055.  It updates the conventions for using 
>    the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding 
>    (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key 
>    Infrastructure (PKI).  Specifically, it updates the conventions for 
>    algorithm parameters in an X.509 certificate's subjectPublicKeyInfo 
>    field.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc4055-update-02.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.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc4055-update-02.txt 
Date: Mon,  9 Mar 2009 14:45:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

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

	Title		: Update for RSAES-OAEP Algorithm Parameters
	Author(s)	: S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-rfc4055-update-02.txt
	Pages		: 7
	Date		: 2009-3-9
	
This document updates RFC 4055.  It updates the conventions for using 
   the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding 
   (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key 
   Infrastructure (PKI).  Specifically, it updates the conventions for 
   algorithm parameters in an X.509 certificate's subjectPublicKeyInfo 
   field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc4055-update-02.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-rfc4055-update-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-new-asn1-03.txt 
Date: Mon,  9 Mar 2009 14:15:02 -0700 (PDT)
Sender: [email-masked]

--NextPart

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

	Title           : New ASN.1 Modules for PKIX
	Author(s)       : P. Hoffman, J. Schaad
	Filename        : draft-ietf-pkix-new-asn1-03.txt
	Pages           : 119
	Date            : 2009-03-09

The PKIX certificate format, and many associated formats, are
expressed using ASN.1.  The current ASN.1 modules conform to the 1988
version of ASN.1.  This document updates those ASN.1 modules to
conform to the 2002 version of ASN.1.  There are no bits-on-the-wire
changes to any of the formats; this is simply a change to the syntax.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-asn1-03.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-new-asn1-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Sat, 7 Mar 2009 19:24:00 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "ietf-pkix" <[email-masked]>
Sender: [email-masked]

If making name optional meets the requirements of multiple environment,
then it is a better standard than making it mandatory.

As to memory challenged, I encourage you to speak with some real
implementers as they move their hardware tokens from 1024 bits to 2048
bits RSA.  They do need bigger and costlier cards.  So, memory in all
form factors is not free.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Eric Norman
> Sent: Friday, March 06, 2009 3:59 PM
> To: ietf-pkix
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
>=20
>=20
> On Mar 6, 2009, at 2:17 PM, Santosh Chokhani wrote:
>=20
> >
> > There are environments where the device may be space=20
> challenged and/or=20
> > the communication environment may be bandwidth challenged.
> >
> > Thus, having only the required information in trust anchors=20
> and TAMP=20
> > will be helpful.
>=20
> Really?  How many bytes can be stored on a ESB memory stick nowadays?
> How many bits can be stored in one square millimeter=20
> nowadays?  How much time does it take to transfer a few=20
> thousand bytes with USB or Bluetooth nowadays?  Are you=20
> seriously suggesting that we need to design for folks whose=20
> environment includes carrier pigeons or tin cans and string=20
> as their communication mechanism?
>=20
> TAMP may indeed be useful, but not in the area of saving resources.
> Where it can be useful is to make it clearer which=20
> information is necessary and which information can be ignored=20
> for something to be a trust anchor and under what circumstances.
>=20
> Eric Norman
>=20
>=20

Date: Fri, 06 Mar 2009 14:59:10 -0600
From: Eric Norman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
To: ietf-pkix <[email-masked]>
Sender: [email-masked]

On Mar 6, 2009, at 2:17 PM, Santosh Chokhani wrote:

>
> There are environments where the device may be space challenged and/or 
> the communication environment may be bandwidth challenged.
>
> Thus, having only the required information in trust anchors and TAMP 
> will be helpful.

Really?  How many bytes can be stored on a ESB memory stick nowadays?
How many bits can be stored in one square millimeter nowadays?  How
much time does it take to transfer a few thousand bytes with USB or
Bluetooth nowadays?  Are you seriously suggesting that we need to
design for folks whose environment includes carrier pigeons or tin
cans and string as their communication mechanism?

TAMP may indeed be useful, but not in the area of saving resources.
Where it can be useful is to make it clearer which information is
necessary and which information can be ignored for something to be
a trust anchor and under what circumstances.

Eric Norman

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Fri, 6 Mar 2009 15:17:47 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "Eric Norman" <[email-masked]>, "ietf-pkix" <[email-masked]>
Sender: [email-masked]

There are environments where the device may be space challenged and/or =
the communication environment may be bandwidth challenged.

Thus, having only the required information in trust anchors and TAMP =
will be helpful.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Eric Norman
> Sent: Friday, March 06, 2009 2:45 PM
> To: ietf-pkix
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
>=20
>=20
> On Mar 6, 2009, at 3:48 AM, Denis Pinkas wrote:
>=20
> > 1 - The draft states: "Though widely used, there is no=A0
> standard format=20
> > for representing trust anchor information".
> > This is untrue. Self-signed certificates are currently=20
> widely used to=20
> > represent TAs. It may simply be argued that other forms ("more=20
> > compact" as indicated) are also needed.
>=20
> Indeed, representation as self-signed certificates is almost=20
> universal.
> What I would like to point out, and what I think=20
> documentation should make clear, is that the "self-signed"=20
> part is not a requirement to be a trust anchor.  The ultimate=20
> decision about "trust" lies with the relying party, and I see=20
> no reason why a relying party should be denied the ability to=20
> use any public key they chose as a trust anchor, even if that=20
> public key is contained in a certificate that is not self-signed.
> This is not a syntactic thing.  In my mind it just a=20
> clarification of what often seems to be confusion between=20
> "must be represented" and "must be used".
>=20
> And on another topic.  Has the need for "more compact" been justified?
> Really?  If someone seriously thinks there is a need for more=20
> compactness nowadays, shouldn't they be talking to those XML folks?
>=20
> Eric Norman
>=20
>=20

Date: Fri, 06 Mar 2009 13:44:55 -0600
From: Eric Norman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
To: ietf-pkix <[email-masked]>
Sender: [email-masked]

On Mar 6, 2009, at 3:48 AM, Denis Pinkas wrote:

> 1 - The draft states: "Though widely used, there is no=A0standard =
format=20
> for representing trust anchor information".
> This is untrue. Self-signed certificates are currently widely used to=20=

> represent TAs. It may simply be argued that
> other forms ("more compact" as indicated) are also needed.

Indeed, representation as self-signed certificates is almost universal.
What I would like to point out, and what I think documentation should
make clear, is that the "self-signed" part is not a requirement to be
a trust anchor.  The ultimate decision about "trust" lies with the
relying party, and I see no reason why a relying party should be denied
the ability to use any public key they chose as a trust anchor, even
if that public key is contained in a certificate that is not=20
self-signed.
This is not a syntactic thing.  In my mind it just a clarification of
what often seems to be confusion between "must be represented" and "must
be used".

And on another topic.  Has the need for "more compact" been justified?
Really?  If someone seriously thinks there is a need for more=20
compactness
nowadays, shouldn't they be talking to those XML folks?

Eric Norman

Date: Fri, 6 Mar 2009 12:23:45 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: another WGLC
Sender: [email-masked]

Stephen Farrell just posted draft-ietf-pkix-other-certs-02 and would 
like to initiate a WGLC.  I see that there has already been one 
comment, so it's good to see folks are paying attention :-).

Let's make this WGLC longer than the usual 2 weeks, because of the 
impending IETF meeting.  WGLC will close for this document on April 
10.

Thanks,

Steve

Date: Fri, 6 Mar 2009 12:17:01 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: WGLC
Sender: [email-masked]

Folks,

Sean and Santosh have updated

draft-ietf-pkix-authorityclearanceconstraints-01.txt

in response to feedback received during the WGLC process.

I'd like to initiate a quick (1 week) second-pass WGLC on this document now.

Thanks,

Steve

Date: Fri, 06 Mar 2009 17:49:47 +0100
From: Julien Stern <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Sender: [email-masked]

Carl Wallace wrote:
>>> The booleans align with the inputs to the path validation algorithm.
>>> Ideally, those would have been integers too.
>> Hmm... That a tricky point I think. I agree that the 
>> validation algorithm has currently described takes booleans.
>>
>> However,
>> 1) It is allowed to augment the algorithm (and that would be 
>> a worthwhile augmentation)
>> 2) What are some existing algorithm doing?Iif the indicator 
>> is set to true, some will look at the extension in the trust 
>> anchor to initialize a value which will be an integer, and 
>> not a boolean anymore.
>>
>> So, if we leave them as boolean in the trust anchor, we will 
>> prevent trust anchor from defining these values, especially 
>> considering that the RFC explicitly states that the 
>> extensions which contains these elements should be ignored.
> 
> Even if the algorithm were augmented, we'd need to describe how to use
> the existing inputs.  Two possible options are:
> 
> 	- Require the values to be 0.  This would have the effect of
> setting the corresponding validation input flag to true.  Processing
> would fail if the extension is present and the value is not zero.  
> 	- Turn on the corresponding validation input flag given any
> SkipCerts value (i.e., presence of a field or extension corresponding to
> a validation input flag causes the flag to be set to true and absence
> causes the flag to be set to false).
> 
> The first option would also disallow using arbitrary CA certificates as
> a trust anchor if the certificate contains a SkipCerts > 0.  Though it
> could be used if the certificate were wrapped in a TrustAnchorInfo or
> just the TBSCertificate structure were used.  I prefer the second
> option.

Carl,

I agree. And indeed 5280 defines these flags as OPTIONAL, when taken 
from the certificate extension.

id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }

PolicyConstraints ::= SEQUENCE {
    requireExplicitPolicy           [0] SkipCerts OPTIONAL,
    inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

So, if we were to replace the booleans by integers, it would indeed be 
needed to make them OPTIONAL, and to set the value of the input flag to 
false if they are absent and true otherwise.

Regards,

--
Julien

Date: Fri, 6 Mar 2009 08:44:34 -0800
To: [email-masked], "ietf-pkix"<[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Sender: [email-masked]

At 10:48 AM +0100 3/6/09, Denis Pinkas wrote:
>1 - The draft states: "Though widely used, there is no standard format for representing trust anchor information".
>This is untrue. Self-signed certificates are currently widely used to represent TAs. It may simply be argued that
>other forms ("more compact" as indicated) are also needed.

Self-signed certs are widely used for representing the trust anchor keys, but not the rest of the information, such as what chains those keys can be used for. The latter is much more interesting than the former.

--Paul Hoffman, Director
--VPN Consortium

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-sha2-dsa-ecdsa-06.txt 
Date: Fri,  6 Mar 2009 08:00:01 -0800 (PST)
Sender: [email-masked]

--NextPart

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

	Title           : Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA
	Author(s)       : Q. Dang
	Filename        : draft-ietf-pkix-sha2-dsa-ecdsa-06.txt
	Pages           : 15
	Date            : 2009-03-06

This document supplements RFC 3279. It specifies 

 algorithm identifiers and ASN.1 encoding rules for 

 the Digital Signature Algorithm (DSA) and Elliptic 

 Curve Digital Signature Algorithm (ECDSA) digital 

 signatures when using SHA-224, SHA-256, SHA-384 or 

 SHA-512 as hashing algorithm. This specification 

 applies to the Internet X.509 Public Key  

 Infrastructure (PKI) when digital signatures are 

 used to sign certificates and certificate 

 revocation lists (CRLs).  

 The key words "MUST", "MUST NOT", "REQUIRED", 

 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 

 "RECOMMENDED", "MAY", and "OPTIONAL" in this 

 document are to be interpreted as described in 

 [RFC 2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-06.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-sha2-dsa-ecdsa-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Fri, 6 Mar 2009 10:38:13 -0500
From: "Carl Wallace" <[email-masked]>
To: "Julien Stern" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> > The booleans align with the inputs to the path validation algorithm.
> > Ideally, those would have been integers too.
>=20
> Hmm... That a tricky point I think. I agree that the=20
> validation algorithm has currently described takes booleans.
>=20
> However,
> 1) It is allowed to augment the algorithm (and that would be=20
> a worthwhile augmentation)
> 2) What are some existing algorithm doing?Iif the indicator=20
> is set to true, some will look at the extension in the trust=20
> anchor to initialize a value which will be an integer, and=20
> not a boolean anymore.
>=20
> So, if we leave them as boolean in the trust anchor, we will=20
> prevent trust anchor from defining these values, especially=20
> considering that the RFC explicitly states that the=20
> extensions which contains these elements should be ignored.

Even if the algorithm were augmented, we'd need to describe how to use
the existing inputs.  Two possible options are:

	- Require the values to be 0.  This would have the effect of
setting the corresponding validation input flag to true.  Processing
would fail if the extension is present and the value is not zero. =20
	- Turn on the corresponding validation input flag given any
SkipCerts value (i.e., presence of a field or extension corresponding to
a validation input flag causes the flag to be set to true and absence
causes the flag to be set to false).

The first option would also disallow using arbitrary CA certificates as
a trust anchor if the certificate contains a SkipCerts > 0.  Though it
could be used if the certificate were wrapped in a TrustAnchorInfo or
just the TBSCertificate structure were used.  I prefer the second
option. =20

Date: Fri, 6 Mar 2009 15:01:34 +0000
From: Stephen Farrell <[email-masked]>
To: "Manger, James H" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-other-certs-02.txt
Sender: [email-masked]

Manger, James H wrote:
> draft-ietf-pkix-other-certs-02.txt allows a cert to reference any number of other certs.
> 
> The cert and the other certs will often be issued by the same CA. It would be nice if the CA's DN didn't have to be repeated for every other cert. For instance, refer to each other cert by: cert hash, cert serial number, and an optional issuer DN. When the issuer DN is absent from a reference use the issuer DN from the certificate (or the previous reference).
> 
> The issuer DN in a reference is held in a SEQUENCE OF GeneralName. It would be tempting to treat an empty sequence as meaning use the cert DN. The hassle is than the sequence (GeneralNames) is defined with a SIZE (1..MAX) constraint.

Nice idea, thanks for pointing it out.

I guess if the optimisation was considered worthwhile we could
say that there should be 1 GeneralName that's a DN that's empty,
in which case the issuer of the containing cert is indicated.

> 
> Issuer DNs are often a few hundred bytes (10%-20% of cert), but perhaps avoiding duplication isn't worth adding any complexity for.

Right. At this point, I don't think that the change is worthwhile
mainly because it'd (I guess) mean that anyone wanting to implement
this would have to tweak their code for handling SCVPCertID for the
special case above. Again, I'm guessing, but I suspect that existing
code for that structure might barf on an empty DN.

However, if folks want that, I'd have no problem adding a scheme
like the above, but for now I think its best left out.

In any case, I'll add a note along the lines below (and an ack
to you) so that if this ever comes back onto the standards track,
that whoever's doing the work then can think about it.

Sound ok?

Stephen.

The SCVPCertID structure used here contains the issuer name for
the CA of the linked certificate. It may happen that that issuer
is also the issuer of the certificate containing the other-certificates
extension. If a new certificate were linked back to a number of old
certificates from that same CA, then there would be considerable
redundancy since there would be many copies of the same issuer name.

One suggestion raised was to have a convention where if the X.500 Name
in the SCVPCertID is an "empty" DN (see RFC5280) that that would
indicate that the same CA issued both the current and the linked
certificates.

Date: Fri, 6 Mar 2009 08:08:52 -0600
From: "Timothy J. Miller" <[email-masked]>
To: "David A. Cooper" <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Need help finding implementations of certain RFC 5280 features
Sender: [email-masked]

--------------ms050705050508090107050100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David A. Cooper wrote:

> 2) From Section 4.2.2.1 (Authority Information Access):
> 
>    HTTP server implementations accessed via the URI SHOULD specify the
>    media type application/pkix-cert [RFC2585] in the content-type header
>    field of the response for a single DER encoded certificate....
> 
> I have found several certificates that include an AIA extension with an 
> id-ad-caIssuers access method with an HTTP URI that points to a single 
> certificate, but none of the HTTP servers specify the media type as 
> application/pkix-cert.  Most specify the media type as 
> application/x-x509-ca-cert and a few specify the media type as text/plain.

Newer DoD certs contain an AIA caIssuers HTTP URI of the form:

http://crl.disa.mil/getsign?<URL encoded CA name>

e.g.:

http://crl.disa.mil/getsign?DOD%20CA-18

Which returns a MIME type of application/pkix-cert.  Also, crl.disa.mil 
is sometimes crl.gds.disa.mil, just because we like to change names a 
lot.  :)

Please be nice to the website; the DISA network providing CRLs is almost 
completely saturated.  If you do fetch a DoD CRL by way of example, 
stick to the one above; it has one of the smallest CRLs.

-- Tim

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

--------------ms050705050508090107050100--

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-pkix"<[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Fri, 6 Mar 2009 10:48:04 +0100
Sender: [email-masked]

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

Yesterday, I have seen an avalanche of e-mails on this draft.

The main issue is that this document has two different goals which should=
 be clearly advertised in the abstract:

It provides the controls needed to :

a) initialize an X.509 certification path validation algorithm implementa=
tion, and to=20
b) verify digital signatures in contexts where X.509 certificates are NOT=
 used.

The draft makes circumvolutions to address both cases. Quoted text:
"If the certificate is present, the subject name in the certificate MUST =
exactly match the X.500 distinguished name provided in the taName field, =
the public key MUST exactly match the public key in the pubKey field and =
the subjectKeyIdentifier extension, if present, MUST exactly match the ke=
y identifier in the keyId field".=20
It would be simpler and clearer to separate both cases and to have a CHOI=
CE between two simple structures from the very beginning.

Basically, I support Julien's view, saying that the name of the taTitle s=
hould be mandatory. However, it is only needed for case b).
When deciding to place a TA in a store, a human being may need to make a =
decision.
Currenty the keyId is only an octet string. This does not allow a human b=
eing to know to who the key belongs to.
On the contrary, taTitle is an UTF8String that can be easily displayed.

Besides these points, I would like to mention some other concerns on this=
 draft.

1 - The draft states: "Though widely used, there is no standard format fo=
r representing trust anchor information".
This is untrue. Self-signed certificates are currently widely used to rep=
resent TAs. It may simply be argued that=20
other forms ("more compact" as indicated) are also needed.

2 - For case a), a structure containing the hash of a self-signed certifi=
cate should also be considered.=20
This would diminish the size of the foot-print.

3 - For case b, the validity period of the TA is a fundamental informatio=
n.=20
The current structure does not allow to support it. It should.=20

Denis
 =20
----- Message re=E7u -----=20
De : owner-ietf-pkix=20
=C0 : i-d-announce=20
Date : 2009-03-04, 17:15:02
Sujet : I-D Action:draft-ietf-pkix-ta-format-01.txt

Pi=E8ce(s) Jointe(s) au message original :
  (1). draft-ietf-pkix-ta-format-01.txt

  Title : Trust Anchor Format
  Author(s) : R. Housley, et al.
  Filename : draft-ietf-pkix-ta-format-01.txt
  Pages : 17
  Date : 2009-03-04

This document describes a structure for representing trust anchor
information. A trust anchor is an authoritative entity represented
by a public key and associated data. The public key is used to
verify digital signatures and the associated data is used to
constrain the types of information or actions for which the trust
anchor is authoritative. The structures defined in this document are
intended to satisfy the format-related requirements defined in Trust
Anchor Management Requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-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_09030610480419520008280_002
Content-Type: text/html; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD><TITLE></TITLE>
<META content=3D"KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, =A9 Kurt=
 Senfer"=20
name=3DGENERATOR>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-=
1"></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=3D5 topMa=
rgin=3D5=20
#ffffff>
<DIV>Yesterday, I have seen an avalanche of e-mails on this draft.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The main issue is that this document has two different goals which s=
hould=20
be&nbsp;clearly advertised in the abstract:</DIV>
<DIV>&nbsp;</DIV>
<DIV>It provides the controls needed to :</DIV>
<DIV>&nbsp;</DIV>
<DIV>a) initialize an X.509 certification path validation algorithm=20
implementation, and to </DIV>
<DIV>b) verify digital signatures in contexts where X.509 certificates=20
are&nbsp;NOT used.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The draft makes circumvolutions to address both cases.&nbsp;Quoted=20
text:</DIV>
<DIV><PRE>"If the certificate is present, the<SPAN style=3D"mso-spacerun:=
 yes"> </SPAN>subject name in the certificate MUST exactly match <BR>the =
X.500 distinguished name provided in the taName field, the public key MUS=
T <BR>exactly match the public key in the pubKey field and the subjectKey=
Identifier extension, <BR>if present, MUST exactly match the <SPAN style=3D=
"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-font-family=
: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language: FR; mso=
-bidi-language: AR-SA">key identifier in the keyId field". </SPAN></PRE><=
/DIV>
<DIV>It would be simpler and clearer to separate both cases and to have a=
 CHOICE=20
between two simple structures from the very beginning.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Basically, I support Julien's view, saying that the name of the taTi=
tle=20
should be mandatory. However, it is only needed for case b).</DIV>
<DIV>When deciding to place a TA in a store, a human being may need to ma=
ke a=20
decision.</DIV>
<DIV>Currenty the keyId is only an octet string. This&nbsp;does not allow=
 a=20
human being to know to who the key belongs to.</DIV>
<DIV>On the contrary, taTitle is an UTF8String that can be easily=20
displayed.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Besides these points, I would like to mention&nbsp;some other&nbsp;c=
oncerns=20
on this draft.</DIV>
<DIV>&nbsp;</DIV>
<DIV>1 - The draft states: "Though widely used, there is no&nbsp;<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">standard=20
format for representing trust anchor information".</SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">This=20
is untrue. Self-signed certificates are currently widely used to represen=
t TAs.=20
It may simply be argued that <BR>other forms ("more compact" as indicated=
) are=20
also needed</SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">.</SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">2&nbsp;-=20
For case a), a structure containing the hash of&nbsp;a self-signed certif=
icate=20
should also be considered. </SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">This=20
would d<SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA">iminish</SPAN>=20
the size of the foot-print.</SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"></SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">3&nbsp;-=20
For case b, the&nbsp;validity period of the TA is a fundamental informati=
on.=20
<BR>The current structure does not allow to support it. </SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">It=20
should. </SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"></SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"></SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA"></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">Denis</SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language:=
 FR; mso-bidi-language: AR-SA">&nbsp;&nbsp;</SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-=
LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal">-----=20
  Message re=E7u ----- </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE=
-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: bl=
ack"><B>De=20
  :</B> <A href=3D"mailto :[email-masked]">owner-ietf-pkix<=
/A>=20
</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>=C0=20
  :</B> <A href=3D"mailto :[email-masked]">i-d-announce</A> </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Date=20
  :</B> 2009-03-04, 17:15:02</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Sujet=20
  :</B> I-D Action:draft-ietf-pkix-ta-format-01.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV>
  <DIV><U><STRONG>Pi=E8ce(s) Jointe(s) au message original :</STRONG></U>=
</DIV>
  <DIV>&nbsp;&nbsp;(1).&nbsp;draft-ietf-pkix-ta-format-01.txt</DIV><BR></=
DIV>
  <DIV>
  <DIV>&nbsp;&nbsp;Title : Trust Anchor Format<BR>&nbsp;&nbsp;Author(s) :=
 R.=20
  Housley, et al.<BR>&nbsp;&nbsp;Filename :=20
  draft-ietf-pkix-ta-format-01.txt<BR>&nbsp;&nbsp;Pages : 17<BR>&nbsp;&nb=
sp;Date=20
  : 2009-03-04<BR><BR>This document describes a structure for representin=
g trust=20
  anchor<BR>information. A trust anchor is an authoritative entity=20
  represented<BR>by a public key and associated data. The public key is u=
sed=20
  to<BR>verify digital signatures and the associated data is used=20
  to<BR>constrain the types of information or actions for which the=20
  trust<BR>anchor is authoritative. The structures defined in this docume=
nt=20
  are<BR>intended to satisfy the format-related requirements defined in=20
  Trust<BR>Anchor Management Requirements.<BR><BR>A URL for this Internet=
-Draft=20
  is:<BR><A=20
  href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-0=
1.txt">http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-01.t=
xt</A><BR><BR>Internet-Drafts=20
  are also available by anonymous FTP=20
  at:<BR>ftp://ftp.ietf.org/internet-drafts/<BR><BR>Below is the data whi=
ch will=20
  enable a MIME compliant mail reader<BR>implementation to automatically=20
  retrieve the ASCII version of=20
the<BR>Internet-Draft.<BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_09030610480419520008280_002--

From: "Manger, James H" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 6 Mar 2009 11:37:09 +1100
Subject: RE: I-D Action:draft-ietf-pkix-other-certs-02.txt
Accept-Language: en-US, en-AU
acceptlanguage: en-US, en-AU
Sender: [email-masked]

Date: Thu, 05 Mar 2009 17:55:18 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Need help finding implementations of certain RFC 5280 features
Sender: [email-masked]

All,

I have been asked to work on finding two independent implementations of 
every feature in RFC 5280 in order to support the process of advancing 
RFC 5280 to Draft Standard.  I have been fairly successful so far, but 
there are a lot of features in RFC 5280 that need to be covered.  So, 
this will likely be the first of many emails requesting help in finding 
implementations of certain features.

So, please let me know if you are aware of any certificates that satisfy 
either of the following requirements:

1) From Section 4.2.1.4 (Certificate Policies):

      An explicitText field includes the textual statement directly in
      the certificate.  The explicitText field is a string with a
      maximum size of 200 characters.  Conforming CAs SHOULD use the
      UTF8String encoding for explicitText, but MAY use IA5String.
      Conforming CAs MUST NOT encode explicitText as VisibleString or
      BMPString.  The explicitText string SHOULD NOT include any control
      characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
      the UTF8String encoding is used, all character sequences SHOULD be
      normalized according to Unicode normalization form C (NFC) [NFC].

I have found several certificates that include a userNotice policy 
qualifier with explicitText, but every one of them encodes the 
explicitText as VisibleString.

2) From Section 4.2.2.1 (Authority Information Access):

   HTTP server implementations accessed via the URI SHOULD specify the
   media type application/pkix-cert [RFC2585] in the content-type header
   field of the response for a single DER encoded certificate....

I have found several certificates that include an AIA extension with an 
id-ad-caIssuers access method with an HTTP URI that points to a single 
certificate, but none of the HTTP servers specify the media type as 
application/pkix-cert.  Most specify the media type as 
application/x-x509-ca-cert and a few specify the media type as text/plain.

Thanks in advance for any help you can give me locating certificates 
(and HTTP servers) that can be used to demonstrate the existence of 
implementations of these features.

Dave

Cc: [email-masked], [email-masked]
From: max pritikin <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-tamp-01.txt 
Date: Thu, 5 Mar 2009 11:30:43 -0600
Sender: [email-masked]

--Apple-Mail-32-269006191
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

The following questions concern the [TAMP], [TAF] and [TAMR] drafts  
(versions indicated below). I've been reading these documents to see  
how they line-up or conflict with the IEEE 802.1AR (Device Identity)  
draft that I am the editor for. This perspective colors my comments.

Broadly IEEE 802.1AR concerns itself with the shipping of a device  
complete with an X.509 certificate issued by the manufacturer. This  
may be accompanied by the manufacturer's certificate chain. Storage  
and use of associated private key material are within the module.  
802.1AR defines mechanisms for insertion and management of additional  
identity certificates issued by a local CA.

In this context I think the 802.1AR module is loosely analogous to a  
'trust anchor store' as described in [TAMR, Section 1] combined with  
the Cryptographic Module discussed in [TAMP, Section 1.3.1]. The 'TA  
manager' would use the 802.1AR defined service interface to interact  
with the module; and of course no 802.1AR limitations are made that  
prohibit additional service interface functionalities specific to TAMP  
(or any other management application) are defined.

The use of local CA issued certificates within 802.1AR appears  
consistent with the 'identity trust anchors'. The manufacturer  
installed certificate and certificate chain on the other hand could be  
described as some combination of the 'apex', 'management' and even  
'identity' trust anchors depending on future use. This is where my  
questions about these drafts arise. I'm like to know more about how  
you envision pre-installed credentials being catagorized.

On the subject of categorization reading these document has raised the  
following questions for me:

The latest [TAF] document appear to move away from specifically  
categorizing Apex, Management and Identity trust anchors. I agree with  
this change. The [TAMP] draft still indicates these three types though  
and I no longer see how they are distinguished. I do see that [TAMP,  
Section 1.3.2] indicates that:
    o  The trust anchor store MUST support the secure storage of exactly
       one apex trust anchor.  The trust anchor store SHOULD support the
       secure storage of at least one additional trust anchor.
but not how it is identified as the Apex. Or as a management trust  
anchor, or identity trust anchor. Is it expected that this information  
would be encoded into the TAF extensions field[s]? For example TAMP  
would specify a specific extension with these types indicated?

(I continue to be unsure how to relate this to the 802.1AR concepts of  
an 'initial device identity' installed during manufacturing vs a  
'local device identity' installed later.  But if these types are TAMP  
specific vs TAF specific perhaps that is less of a concern.)

I like the idea of a TAF which can store information specific to  
particular applications, various management protocols such as CMS, and  
other things moving forward. TAMP apparently then specifies specific  
authorizations and their meanings but this doesn't limit or impact  
other uses? And importantly this type of construct results in a TAF  
which may be either Apex, Management, or Identity or any combination  
thereof including new types in the future?

This line of thought leads to some reflection on the [TAMP] discussion  
illustrated by Figure 4-1 might be even further refined. I appreciate  
the update from "Crypto Module" to "Trust Anchor Store" -- or maybe  
even a combination of the two of them (this echoes my comment above  
about how the 802.1AR module sounds like a combination of both of  
these elements). Perhaps my confusion is that in my mind a Trust  
Anchor Manager is communicating via TAMP with a TAMP service which is  
then accessing the Trust Anchor Store. A picture is worth a thousand  
words:

(my apologies if mail messes this up)
       +---------+      +----------+
       |         |      |          |
       |         |      |          |
       |         |      |          |
       |         | TAMP |          |
       | Trust   |<---->| TAMP     |
       | Anchor  |      | Process  | OS & Application
       | Manager |      |          | Service Interface
       |         |      |          |      +----------+
       |         |      |          |<---->|TAFs in a |
       |         |      |          |      |Crypto    |
       |         |      |          |      |Module    |
       |         |      |          |      |& Store   |
       +---------+      +----------+      +----------+

I haven't seen a discussion that the "OS & Application Service  
Interface" as being in scope. Drawing the diagram like this clarifies  
my impression that the TAF might be used by other applications and  
that those applications might benefit from the TAF standardization.  
Given the recent changes to [TAF] I suspect things are moving in this  
direction?

Thanks for any clarifications,

- Max Pritikin

referenced documents:
[TAF] draft-ietf-pkix-ta-format-01
[TAMP] draft-ietf-pkix-tamp-01
[TAMR] draft-ietf-pkix-ta-mgmt-reqs-02

On Mar 4, 2009, at 10:15 AM, [email-masked] wrote:

> 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           : Trust Anchor Management Protocol (TAMP)
> 	Author(s)       : R. Housley, et al.
> 	Filename        : draft-ietf-pkix-tamp-01.txt
> 	Pages           : 84
> 	Date            : 2009-03-04
>
> This document describes a transport independent protocol for the
> management of trust anchors and community identifiers stored in a
> trust anchor store.  The protocol makes use of the Cryptographic
> Message Syntax (CMS), and a digital signature is used to provide
> integrity protection and data origin authentication.  The protocol
> can be used to manage trust anchor stores containing trust anchors
> represented as Certificate, TBSCertificate or TrustAnchorInfo
> objects.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-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.
> <mime-attachment>

--Apple-Mail-32-269006191
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div>The following questions =
concern the [TAMP], [TAF] and [TAMR] drafts (versions indicated below). =
I've been reading these documents to see how they line-up or conflict =
with the IEEE 802.1AR (Device Identity) draft that I am the editor for. =
This perspective colors my =
comments.&nbsp;</div><div><br></div><div>Broadly IEEE 802.1AR concerns =
itself with the shipping of a device complete with an X.509 certificate =
issued by the manufacturer. This may be accompanied by the =
manufacturer's certificate chain. Storage and use of associated private =
key material are within the module. 802.1AR defines mechanisms for =
insertion and management of additional identity certificates issued by a =
local CA.&nbsp;</div><div><br></div><div>In this context I think the =
802.1AR module is loosely analogous to a 'trust anchor store' as =
described in [TAMR, Section 1] combined with the Cryptographic Module =
discussed in [TAMP, Section 1.3.1]. The 'TA manager' would use the =
802.1AR defined service interface to interact with the module; and of =
course no 802.1AR limitations are made that prohibit additional service =
interface functionalities specific to TAMP (or any other management =
application) are defined.&nbsp;</div><div><br></div><div>The use of =
local CA issued certificates within 802.1AR appears consistent with the =
'identity trust anchors'. The manufacturer installed certificate and =
certificate chain on the other hand could be described as some =
combination of the 'apex', 'management' and even 'identity' trust =
anchors depending on future use. This is where my questions about these =
drafts arise. I'm like to know more about how you envision pre-installed =
credentials being catagorized.</div><div><br></div><div>On the subject =
of&nbsp;categorization&nbsp;reading these document has raised the =
following questions for me:</div><div><br></div><div>The latest [TAF] =
document appear to move away from specifically categorizing Apex, =
Management and Identity trust anchors. I agree with this change. The =
[TAMP] draft still indicates these three types though and I no longer =
see how they are distinguished. I do see that [TAMP, Section 1.3.2] =
indicates that:</div><div>&nbsp;&nbsp; o &nbsp;The trust anchor store =
MUST support the secure storage of exactly</div><div>&nbsp;&nbsp; &nbsp; =
&nbsp;one apex trust anchor. &nbsp;The trust anchor store SHOULD support =
the</div><div>&nbsp;&nbsp; &nbsp; &nbsp;secure storage of at least one =
additional trust anchor.&nbsp;</div><div>but not how it is identified as =
the Apex. Or as a management trust anchor, or identity trust anchor. Is =
it expected that this information would be encoded into the TAF =
extensions field[s]? For example TAMP would specify a specific extension =
with these types indicated?</div><div><br></div><div>(I continue to be =
unsure how to relate this to the 802.1AR concepts of an 'initial device =
identity' installed during manufacturing vs a 'local device identity' =
installed later. &nbsp;But if these types are TAMP specific vs TAF =
specific perhaps that is less of a concern.)</div><div><br></div><div>I =
like the idea of a TAF which can store information specific to =
particular applications, various management protocols such as CMS, and =
other things moving forward. TAMP apparently then specifies specific =
authorizations and their meanings but this doesn't limit or impact other =
uses? And importantly this type of construct results in a TAF which may =
be either Apex, Management, or Identity or any combination thereof =
including new types in the future?</div><div><br></div><div>This line of =
thought leads to some reflection on the [TAMP] discussion illustrated by =
Figure 4-1 might be even further refined. I appreciate the update from =
"Crypto Module" to "Trust Anchor Store" -- or maybe even a combination =
of the two of them (this echoes my comment above about how the 802.1AR =
module sounds like a combination of both of these elements). Perhaps my =
confusion is that in my mind a Trust Anchor Manager is communicating via =
TAMP with a TAMP service which is then accessing the Trust Anchor Store. =
A picture is worth a thousand words:</div><div><br></div><div>(my =
apologies if mail messes this up)</div><div><font =
class=3D"Apple-style-span" face=3D"Courier">&nbsp;&nbsp; &nbsp; =
&nbsp;+---------+ &nbsp; &nbsp; =
&nbsp;+----------+</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
| &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;|</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
| &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;|</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
| &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;|</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
| TAMP | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|</font></div><div><font =
class=3D"Apple-style-span" face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| =
Trust &nbsp; |&lt;---->| TAMP &nbsp; &nbsp; |</font></div><div><font =
class=3D"Apple-style-span" face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| =
Anchor &nbsp;| &nbsp; &nbsp; &nbsp;| Process &nbsp;| OS &amp; =
Application</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| Manager | &nbsp; &nbsp; =
&nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| Service =
Interface</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
| &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; =
&nbsp; &nbsp;+----------+</font></div><div><font =
class=3D"Apple-style-span" face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| =
&nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;|&lt;---->|TAFs in a |</font></div><div><font =
class=3D"Apple-style-span" face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| =
&nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;| &nbsp; &nbsp; &nbsp;|Crypto &nbsp; =
&nbsp;|</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; =
| &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; =
&nbsp; &nbsp;|Module &nbsp; &nbsp;|</font></div><div><font =
class=3D"Apple-style-span" face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;| =
&nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;| &nbsp; &nbsp; &nbsp;|&amp; Store &nbsp; =
|</font></div><div><font class=3D"Apple-style-span" =
face=3D"Courier">&nbsp;&nbsp; &nbsp; &nbsp;+---------+ &nbsp; &nbsp; =
&nbsp;+----------+ &nbsp; &nbsp; =
&nbsp;+----------+</font></div><div><br></div><div>I haven't seen a =
discussion that the "OS &amp; Application Service Interface" as being in =
scope. Drawing the diagram like this clarifies my impression that the =
TAF might be used by other applications and that those applications =
might benefit from the TAF standardization. Given the recent changes to =
[TAF] I suspect things are moving in this =
direction?</div><div><br></div><div>Thanks for any =
clarifications,</div><div><br></div><div>- Max =
Pritikin</div><div><br></div><div>referenced documents:</div><div>[TAF] =
draft-ietf-pkix-ta-format-01</div><div>[TAMP] =
draft-ietf-pkix-tamp-01</div><div>[TAMR] =
draft-ietf-pkix-ta-mgmt-reqs-02</div><div><br></div><br><div><div><br></di=
v><div>On Mar 4, 2009, at 10:15 AM, <a =
href=3D"mailto:[email-masked]">[email-masked]</a> =
wrote:</div><br><blockquote type=3D"cite"><div>A New Internet-Draft is =
available from the on-line Internet-Drafts directories.<br>This draft is =
a work item of the Public-Key Infrastructure (X.509) Working Group of =
the IETF.<br><br><br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Title =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: Trust =
Anchor Management Protocol (TAMP)<br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Author(s) =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: R. Housley, et al.<br><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Filename =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: =
draft-ietf-pkix-tamp-01.txt<br><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Pages =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: =
84<br><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>Date =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: =
2009-03-04<br><br>This document describes a transport independent =
protocol for the<br>management of trust anchors and community =
identifiers stored in a<br>trust anchor store. &nbsp;The protocol makes =
use of the Cryptographic<br>Message Syntax (CMS), and a digital =
signature is used to provide<br>integrity protection and data origin =
authentication. &nbsp;The protocol<br>can be used to manage trust anchor =
stores containing trust anchors<br>represented as Certificate, =
TBSCertificate or TrustAnchorInfo<br>objects.<br><br>A URL for this =
Internet-Draft is:<br><a =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-01.txt">h=
ttp://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-01.txt</a><br><br>=
Internet-Drafts are also available by anonymous FTP =
at:<br>ftp://ftp.ietf.org/internet-drafts/<br><br>Below is the data =
which will enable a MIME compliant mail reader<br>implementation to =
automatically retrieve the ASCII version of =
the<br>Internet-Draft.<br><span =
id=3D"cid:[email-masked]">&lt;mime-attachm=
ent></span></div></blockquote></div><br></body></html>=

--Apple-Mail-32-269006191--

Date: Thu, 05 Mar 2009 11:05:44 -0600
From: Eric Norman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
To: [email-masked]
Sender: [email-masked]

On Mar 5, 2009, at 9:46 AM, Carl Wallace wrote:

> Trust in the key is established by external means, i.e., manual check 
> or
> TAMP message verification.  DNs are generally not small.  The taName is
> optional to allow omission in situations where they are not used.  Why
> should a name be required since not all uses require a name?

Why not make a clear distinction between usage and inclusion?  If
information like a DN MUST be included in some structure, I don't
see why that implies that it MUST be used.  The part of the standard
that specifies usage can say that such information MUST or MAY be
ignored.

It seems to me that failing to make a clear distinction is getting
dangerously close to creating a situation where a creator of a
trust anchor will be required to prepare different structures
depending on usage.  I.e. there will be more structures flying
around.  Is this really a situation that y'all want?  Won't this
just lead to more confusion and more interoperability problems?

Personally, I don't see why trust anchors can't be specified with
the same format as X.509 certificates along with the proviso that
some components (like issuer, serial number, etc) may be ignored
in the validation algorithm.

Eric Norman

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Thu, 5 Mar 2009 12:05:38 -0500
From: "Carl Wallace" <[email-masked]>
To: "Julien Stern" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> > There are two means of implementing this with the current=20
> spec.  The=20
> > taTitle field can identify the TA using a string value.
>=20
> True. But if I do want to put a DN in there, I will bump into=20
> all the infamous Printable/BMP/UTF-8/etc encoding issues :)
>=20
>  > A subjectAltName extension could be included with any form=20
> of GeneralName.
> > Neither of these would enable path validation.
>=20
> Also true, but no-one else will understand this extension as=20
> no standard=20
> extension are defined in the draft. It will likely be mostly=20
> a "private"=20
> extension.

This can be clarified in the draft.=20

Date: Thu, 05 Mar 2009 18:01:29 +0100
From: Julien Stern <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: Tom Gindin <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Sender: [email-masked]

Carl Wallace wrote:
> <snip>
>> To sum things up:
>>
>> 1) It still believe that mandating the inclusion of the 
>> identity of the 
>> private key owner in one way or an other (possibly not a DN) 
>> would be nice.
>> 2) If everyone thinks that this identity can be omitted if 
>> implicit from 
>> the context, well, fine. A short paragraph explaining that 
>> could be nice.
> 
> Adding a paragraph to clarify this seems reasonable to me.
> 
>> 3) Providing a way to provide this identity (possibly under various 
>> forms: string, DN, etc) _without_ necessarily linking the presence of 
>> the DN to the fact that this TA can be used for X.509 
>> validation would 
>> certainly also be nice.

> There are two means of implementing this with the current spec.  The
> taTitle field can identify the TA using a string value.

True. But if I do want to put a DN in there, I will bump into all the 
infamous Printable/BMP/UTF-8/etc encoding issues :)

 > A subjectAltName extension could be included with any form of 
GeneralName.
> Neither of these would enable path validation.

Also true, but no-one else will understand this extension as no standard 
extension are defined in the draft. It will likely be mostly a "private" 
extension.

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Thu, 5 Mar 2009 11:47:21 -0500
From: "Carl Wallace" <[email-masked]>
To: "Julien Stern" <[email-masked]>
Cc: "Tom Gindin" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

<snip>
> To sum things up:
>=20
> 1) It still believe that mandating the inclusion of the=20
> identity of the=20
> private key owner in one way or an other (possibly not a DN)=20
> would be nice.
> 2) If everyone thinks that this identity can be omitted if=20
> implicit from=20
> the context, well, fine. A short paragraph explaining that=20
> could be nice.

Adding a paragraph to clarify this seems reasonable to me.

> 3) Providing a way to provide this identity (possibly under various=20
> forms: string, DN, etc) _without_ necessarily linking the presence of=20
> the DN to the fact that this TA can be used for X.509=20
> validation would=20
> certainly also be nice.

There are two means of implementing this with the current spec.  The
taTitle field can identify the TA using a string value.  A
subjectAltName extension could be included with any form of GeneralName.
Neither of these would enable path validation.

Date: Thu, 05 Mar 2009 17:44:54 +0100
From: Julien Stern <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Sender: [email-masked]

Russ Housley wrote:
> 
> Julien:
> 
>> I fully share your view that the "other policy information" should 
>> only be an optional part of the trust anchor. However, I feel that the 
>> name is a fundamental part of the trust anchor. A trust anchor without 
>> a name, in my opinion, would be like a certificate without a name.
> 
> I have no objection to the taName becoming a mandatory element of the 
> structure.  It is certainly needed for certification path construction 
> and validation.  However, in the TAMP context, there are messages that 
> are signed directly by the trust anchor.  In this case, a key identifier 
> without a name is sufficient.  This element is optional to allow for a 
> trust anchor that is able to sign such messages but not allowed to sign 
> certificates.  So, if the taName becomes non-optional, another mechanism 
> is needed to indicate whether the trust anchor can sign certificates.

Russ,

As explained into more details in my reply to Carl, my understanding 
from the draft was;

1) the identity of the private key owner is optional
2) the taName can optionally be used to identity him in a X.500 context

I am in disagreement with 1). I still think that a TA without a name 
(whichever its form, DN or not) would be like a certificate without a 
name. However, I seem to be the only one, so I'll stop.

Now, from what you say, I understand that if I put a DN, it will _also_ 
mean that this TA can be used for X.509 validation.

Isn't it a limitation to combine the identification of the owner with a 
DN and the authorization to perform X.509 validation with this TA?

Regards,

--
Julien

Date: Thu, 5 Mar 2009 11:31:15 -0500
To: Julien Stern <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Cc: [email-masked]
Sender: [email-masked]

At 7:43 PM +0100 3/4/09, Julien Stern wrote:
>[email-masked] wrote:
>>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           : Trust Anchor Format
>>	Author(s)       : R. Housley, et al.
>>	Filename        : draft-ietf-pkix-ta-format-01.txt
>>	Pages           : 17
>>	Date            : 2009-03-04
>>
>
>Hi again,
>
>separating from the previous email due to the nature of the comment: 
>this one is more "philosophical" :)
>
>This draft defines a trust anchor as a public key with additional data.
>
>I believe that the most common usage of the word "trust anchor" 
>denotes the _binding_ of a public key _and_ a name. A certificate 
>binds a name and a public key (along with other information) thanks 
>to a signature. A trust anchor binds them through direct trust.

A PKC, especially a v3 PKC, contains a number of attributes, of which 
name is often viewed as the most important. But not all PKIs view the 
subject name as the most important attribute, e.g., in the RPKI 
developed in the SIDR WG, the RFC 3779 extension are arguably the 
most important attributes. We have adopted this TA format for that 
work. So I think the current wording is appropriate.

In large part, motivation for not requiring a (subject) DN arises 
because of the intent to use this TA representation in the context of 
device management, where a key (but not a self-signed cert) makes 
sense.

Steve

Date: Thu, 05 Mar 2009 17:32:01 +0100
From: Julien Stern <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: Tom Gindin <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Sender: [email-masked]

Inline...

Carl Wallace wrote:
> Inline... 
> 
>> -----Original Message-----
>> From: Julien Stern [mailto:[email-masked]] 
>> Sent: Thursday, March 05, 2009 10:10 AM
>> To: Carl Wallace
>> Cc: Tom Gindin; [email-masked]
>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>
>> Carl,
>>
>> Thanks for your reply.
>> I'm starting to see some of the rationale better.
>>
>> What still slightly bothers me is the following:
>>
>> I keep on thinking it would bring major confusion to say that 
>> a trust anchor can be reduced to a public key. A trust anchor 
>> has to be an _identified_ public key, else it's just... 
>> well... a public key.
> 
> A TA is a public key and some constraints on its usage.  As referenced
> in this thread, a DN is just one form of constraint.

Carl,

While I do agree with a lot of what you say, I just cannot agree with 
this :) A TA is not just a public key possibly with constraints of 
usage. A public key can be "promoted" to a TA if you KNOWN and TRUST the 
entity controlling the corresponding public key. Now this "promotion" 
can be explicit (you click on something) or implicit (you receive some 
hardware device with the manufacturer key embedded). But whether 
implicit or explicit, the fact you known the identity of the private key 
owner (and that you trust it) is what differentiates a public key from a TA.

If you do not believe that the identity of the private key owner is a 
fundamental part of a TA, then we have a strong disagreement.

Otherwise, we probably only have a very minor disagreement.
- You say that this identity can be omitted from the TA information and 
can be inferred by external means
- I felt that this identity was such a fundamental aspect that it needed 
to be an integral part of the TA information

No big deal, in fact :)

And well, I agree that it you receive a hardware device with an embedded 
public key, the identity of the private key owner (the hardware 
manufacturer most likely) can be implicitly inferred... On the other 
hand, it does not cost so much to embed it.

At any rate, if there is a consensus that this identity can be omitted 
and implicit, let us stop the thread on this aspect.

Now, as regards the DN:
I originally understood it was _the_ way to identity the private key 
owner and that it was optional. Apparently, it serves a dual-purpose:
1) to identify the private key owner
2) to indicate the public key can be used for X.509 validation

One may view this as a limitation: I cannot state the identity of the 
key owner using a DN unless I want to use the public key for X.509 
validation.

To sum things up:

1) It still believe that mandating the inclusion of the identity of the 
private key owner in one way or an other (possibly not a DN) would be nice.
2) If everyone thinks that this identity can be omitted if implicit from 
the context, well, fine. A short paragraph explaining that could be nice.
3) Providing a way to provide this identity (possibly under various 
forms: string, DN, etc) _without_ necessarily linking the presence of 
the DN to the fact that this TA can be used for X.509 validation would 
certainly also be nice.

Regards,

--
Julien

>> Now, I feel I'm starting to understand why the keyIdentifier 
>> is always mandatory. Maybe you meant to be using this key 
>> identifier as a generic "name" for the key? In which case, we 
>> do have a difference between a public key and a trust anchor, 
>> e.g. the key is "identified". However, this keyIdentifier is 
>> usually directly inferred from the public key, so this 
>> "identification" is a weak one at best.
>>
>> The very beginning of the TA draft says: "A trust anchor is 
>> an authoritative entity represented by a public key and 
>> associated data."
>> The bare minimum currently allowed is the key and the keyIdentifier.
>>
>> I fail to see how the authoritative entity comes into play 
>> here. 
> 
> The authoritative entity associated with the TA comes into play by using
> the private key.  
> 
>> In all the examples you gave below, we may possibly go 
>> through a keyIdentifier instead of a DN to find the public 
>> key used to signing, but it does not make sense to use this 
>> key if it is an "anonymous" key.
> 
> Why?  That some signature schemes use a key identifier instead of a DN
> to locate the public key isn't a problem.  Even 5280 uses key identifier
> more than DN to find a key (where one CA has multiple certs).  The
> important thing is that the TA was obtained in a secure manner.  
> 
>> Maybe, an other way to highlight the difference in our views 
>> is that you assume the "identification" of the key can be 
>> performed by external means? In which case, a trust anchor 
>> could be a public key whose owner happens to be known by 
>> external means or be implicit from the context? 
>> And that I believe the identity of the "authoritative entity" 
>> should be explicitly stated in the TA?
> 
> Trust in the key is established by external means, i.e., manual check or
> TAMP message verification.  DNs are generally not small.  The taName is
> optional to allow omission in situations where they are not used.  Why
> should a name be required since not all uses require a name?   
>> Regards,
>>
>> --
>> Julien
>>
>>
>> Carl Wallace wrote:
>>> Inline...
>>>
>>>> -----Original Message-----
>>>> From: Julien Stern [mailto:[email-masked]]
>>>> Sent: Thursday, March 05, 2009 8:09 AM
>>>> To: Carl Wallace
>>>> Cc: Tom Gindin; [email-masked]
>>>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>>>
>>>> Carl,
>>>>
>>>> well, there may be strong "philosophical" disagreements 
>> from yourself 
>>>> and/or Tom of what a trust anchor is (which is fine
>>>> :) ), but could you give an example of an actual use of a trust 
>>>> anchor that do not require an identity?
>>> CMS does not use a DN to identify a signer.  Timestamps, firmware 
>>> packages and key packages are all examples of objects 
>> signed using CMS 
>>> that could be verified using a TA that is not named using a DN but 
>>> identified with a key identifier.  OCSP responses aren't 
>> signed using 
>>> CMS but can also identify a signer using a key identifier 
>> and may be 
>>> validated by a TA.
>>>  
>>>> Again, my humble personal view is that a PKI in general is 
>> before all 
>>>> used to link cryptographic key to identities. This can be done by 
>>>> direct trust (e.g. a trust anchor) or vouched by an other entity 
>>>> (e.g. a certificate). This is why I believe the identity is a 
>>>> fundamental part of a trust anchor.
>>>> Now the fact that this identity should be a DN is not as 
>> fundamental 
>>>> (it could be a string), but considering the global 
>> context, a DN is 
>>>> really what makes senses.
>>> You could choose to use a DN and/or a TA title in all TAs 
>> used in your 
>>> environment.
>>>  
>>>> I read the fact that omission of the taName precludes path 
>> validation 
>>>> (and I naturally concur), but I actually think that 
>> omission of that 
>>>> name precludes _any_ usage of the corresponding public 
>> key, and that 
>>>> therefore the DN should be made mandatory in all cases.
>>> The DN is required by 5280 for name chaining.  A DN is not 
>> required in 
>>> all cases where a TA could be used (see above) so making it 
>> mandatory 
>>> is not desirable.
>>>  
>>>> --
>>>> Julien
>>>>
>>>> Carl Wallace wrote:
>>>>> The draft notes that omission of the taName field precludes path 
>>>>> validation.  Given that TAs serve other purposes that don't
>>>> require DNs,
>>>>> making the field optional makes sense.  All three formats
>>>> in the draft
>>>>> support including a DN.  This allows the 5280 requirement to be
>>>>> satisfied with each structure.   
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] 
>>>>>> [mailto:[email-masked]] On Behalf Of Tom Gindin
>>>>>> Sent: Wednesday, March 04, 2009 8:41 PM
>>>>>> To: Julien Stern
>>>>>> Cc: [email-masked]
>>>>>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>>>>>
>>>>>>
>>>>>>         Julian:
>>>>>>
>>>>>>         I think you're wrong in believing that the name 
>> is central 
>>>>>> to the definition of a trust anchor.  I can have (and my browser 
>>>>>> may be shipped
>>>>>> with) several trust anchors issued by the same organization, and 
>>>>>> the names which distinguish them are (to me as the 
>> manager of the 
>>>>>> trust store) quite arbitrary.  A typical example is that 
>> there are 
>>>>>> two separate CA certificates from Entrust with CN="Entrust.net 
>>>>>> Secure Server Certification Authority".  Their OU's are slightly 
>>>>>> different, and one of them has a Country attribute.
>>>>>>         While philosophically I completely disagree with 
>> you, RFC 
>>>>>> 5280 section 6.1.1 point d-1 requires that the trust 
>> anchor have an 
>>>>>> issuer name, as does the same section in 3280.
>>>>>>  Thus, no trust anchor definition which does not include 
>> an issuer 
>>>>>> name can be used by our own existing algorithms.  I 
>> think that's a 
>>>>>> pretty good reason for PKIX to require the presence of a 
>> DN in this 
>>>>>> definition.
>>>>>>
>>>>>>                 Tom Gindin
>>>>>>
>>>>>> P.S. - These views are mine personally, and not 
>> necessarily those 
>>>>>> of my employer
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Julien Stern <[email-masked]> Sent by: 
>>>>>> [email-masked]
>>>>>> 03/04/2009 01:43 PM
>>>>>>
>>>>>> To
>>>>>>
>>>>>> cc
>>>>>> [email-masked]
>>>>>> Subject
>>>>>> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [email-masked] wrote:
>>>>>>> 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           : Trust Anchor Format
>>>>>>>                Author(s)       : R. Housley, et al.
>>>>>>>                Filename        : 
>> draft-ietf-pkix-ta-format-01.txt
>>>>>>>                Pages           : 17
>>>>>>>                Date            : 2009-03-04
>>>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> separating from the previous email due to the nature of
>>>> the comment: 
>>>>>> this one is more "philosophical" :)
>>>>>>
>>>>>> This draft defines a trust anchor as a public key with 
>> additional 
>>>>>> data.
>>>>>>
>>>>>> I believe that the most common usage of the word "trust anchor" 
>>>>>> denotes the _binding_ of a public key _and_ a name. A 
>> certificate 
>>>>>> binds a name and a public key (along with other 
>> information) thanks 
>>>>>> to a signature. A trust anchor binds them through direct trust.
>>>>>>
>>>>>> And indeed, the definition in X.509 is:
>>>>>>
>>>>>> trust anchor: A trust anchor is a set of the following
>>>> information in
>>>>>> addition to the public key: algorithm identifier, public key 
>>>>>> parameters (if applicable), distinguished name of the 
>> holder of the
>>>> associated
>>>>>> private key (i.e., the subject CA) and optionally a validity 
>>>>>> period. The trust anchor may be provided in the form of a 
>>>>>> self-signed
>>>> certificate.
>>>>>> A trust anchor is trusted by a certificate using system
>>>> and used for
>>>>>> validating certificates in certification paths.
>>>>>>
>>>>>>
>>>>>> I assume that you did not choose to make the DN optional without 
>>>>>> reason.
>>>>>> But is that really something that we would like to have? 
>> Are there 
>>>>>> really cases where we want to use a public key without 
>> explicitly 
>>>>>> knowing whom it belongs to? Isn't there a risk to spread
>>>> confusion on
>>>>>> what a "trust anchor" is?
>>>>>>
>>>>>> Granted, this RFC could define a Trust Anchor in a more
>>>> global scope,
>>>>>> without a need to bind it to a DN, but I'm (very
>>>> personally) not sure
>>>>>> this is a great idea and I believe that mandating the 
>> presence of a 
>>>>>> DN would not bring a strong limitation.
>>>>>>
>>>>>> Have you considered moving the taName from the 
>> CertPathControls to 
>>>>>> the main structure (TrustAnchorInfo) and keeping the 
>>>>>> CertPathControls structure for fine tuning of the X.509 input 
>>>>>> algorithm?
>>>>>>
>>>>>> (And along the same lines, why is the KeyIdentifier
>>>> mandatory and not
>>>>>> optional?)
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> --
>>>>>> Julien
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
> 

Date: Thu, 5 Mar 2009 08:29:42 -0800
To: Julien Stern <[email-masked]>, Carl Wallace <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Cc: Tom Gindin <[email-masked]>, [email-masked]
Sender: [email-masked]

At 4:09 PM +0100 3/5/09, Julien Stern wrote:
>I keep on thinking it would bring major confusion to say that a trust anchor can be reduced to a public key. A trust anchor has to be an _identified_ public key, else it's just... well... a public key.

A trust anchor is a public key and some policy information related to the key, namely what the relying party can use the trust anchor to validate. That policy information is not the same for all applications, so specifying a single structure for it would be meaningless: it would be an octet hole that is filled in application by application.

I support the current structure in the draft: it allows each application to specify its policy in a way that is appropriate for the application, yet gives an interoperable format for trust anchors that work well beyond typical PKIX uses.

--Paul Hoffman, Director
--VPN Consortium

Date: Thu, 05 Mar 2009 15:48:20 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-other-certs-02.txt
Sender: [email-masked]

Just to save you time, this is basically the same as before
but with the editorial comments removed and I've asked the
chairs to start a WGLC for it at the appropriate time.

S.

[email-masked] wrote:
> 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           : Other Certificates Extension
> 	Author(s)       : S. Farrell
> 	Filename        : draft-ietf-pkix-other-certs-02.txt
> 	Pages           : 8
> 	Date            : 2009-03-05
> 
> Some applications that associate state information with public key
> certificates can benefit from a way to link together a set of
> certificates belonging to the same end entity that can safely be
> considered to be equivalent for the purposes of referencing that
> application state information.  This memo defines a certificate
> extension that allows applications to establish the required linkage
> without introducing a new application protocol data unit.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-other-certs-02.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.

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Thu, 5 Mar 2009 10:46:10 -0500
From: "Carl Wallace" <[email-masked]>
To: "Julien Stern" <[email-masked]>
Cc: "Tom Gindin" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Inline...=20

> -----Original Message-----
> From: Julien Stern [mailto:[email-masked]]=20
> Sent: Thursday, March 05, 2009 10:10 AM
> To: Carl Wallace
> Cc: Tom Gindin; [email-masked]
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
> Carl,
>=20
> Thanks for your reply.
> I'm starting to see some of the rationale better.
>=20
> What still slightly bothers me is the following:
>=20
> I keep on thinking it would bring major confusion to say that=20
> a trust anchor can be reduced to a public key. A trust anchor=20
> has to be an _identified_ public key, else it's just...=20
> well... a public key.

A TA is a public key and some constraints on its usage.  As referenced
in this thread, a DN is just one form of constraint.
=20
> Now, I feel I'm starting to understand why the keyIdentifier=20
> is always mandatory. Maybe you meant to be using this key=20
> identifier as a generic "name" for the key? In which case, we=20
> do have a difference between a public key and a trust anchor,=20
> e.g. the key is "identified". However, this keyIdentifier is=20
> usually directly inferred from the public key, so this=20
> "identification" is a weak one at best.
>
> The very beginning of the TA draft says: "A trust anchor is=20
> an authoritative entity represented by a public key and=20
> associated data."
> The bare minimum currently allowed is the key and the keyIdentifier.
>=20
> I fail to see how the authoritative entity comes into play=20
> here.=20

The authoritative entity associated with the TA comes into play by using
the private key. =20

> In all the examples you gave below, we may possibly go=20
> through a keyIdentifier instead of a DN to find the public=20
> key used to signing, but it does not make sense to use this=20
> key if it is an "anonymous" key.

Why?  That some signature schemes use a key identifier instead of a DN
to locate the public key isn't a problem.  Even 5280 uses key identifier
more than DN to find a key (where one CA has multiple certs).  The
important thing is that the TA was obtained in a secure manner. =20

> Maybe, an other way to highlight the difference in our views=20
> is that you assume the "identification" of the key can be=20
> performed by external means? In which case, a trust anchor=20
> could be a public key whose owner happens to be known by=20
> external means or be implicit from the context?=20
> And that I believe the identity of the "authoritative entity"=20
> should be explicitly stated in the TA?

Trust in the key is established by external means, i.e., manual check or
TAMP message verification.  DNs are generally not small.  The taName is
optional to allow omission in situations where they are not used.  Why
should a name be required since not all uses require a name?  =20
=20
> Regards,
>=20
> --
> Julien
>=20
>=20
> Carl Wallace wrote:
> > Inline...
> >=20
> >> -----Original Message-----
> >> From: Julien Stern [mailto:[email-masked]]
> >> Sent: Thursday, March 05, 2009 8:09 AM
> >> To: Carl Wallace
> >> Cc: Tom Gindin; [email-masked]
> >> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> >>
> >> Carl,
> >>
> >> well, there may be strong "philosophical" disagreements=20
> from yourself=20
> >> and/or Tom of what a trust anchor is (which is fine
> >> :) ), but could you give an example of an actual use of a trust=20
> >> anchor that do not require an identity?
> >=20
> > CMS does not use a DN to identify a signer.  Timestamps, firmware=20
> > packages and key packages are all examples of objects=20
> signed using CMS=20
> > that could be verified using a TA that is not named using a DN but=20
> > identified with a key identifier.  OCSP responses aren't=20
> signed using=20
> > CMS but can also identify a signer using a key identifier=20
> and may be=20
> > validated by a TA.
> > =20
> >> Again, my humble personal view is that a PKI in general is=20
> before all=20
> >> used to link cryptographic key to identities. This can be done by=20
> >> direct trust (e.g. a trust anchor) or vouched by an other entity=20
> >> (e.g. a certificate). This is why I believe the identity is a=20
> >> fundamental part of a trust anchor.
> >> Now the fact that this identity should be a DN is not as=20
> fundamental=20
> >> (it could be a string), but considering the global=20
> context, a DN is=20
> >> really what makes senses.
> >=20
> > You could choose to use a DN and/or a TA title in all TAs=20
> used in your=20
> > environment.
> > =20
> >> I read the fact that omission of the taName precludes path=20
> validation=20
> >> (and I naturally concur), but I actually think that=20
> omission of that=20
> >> name precludes _any_ usage of the corresponding public=20
> key, and that=20
> >> therefore the DN should be made mandatory in all cases.
> >=20
> > The DN is required by 5280 for name chaining.  A DN is not=20
> required in=20
> > all cases where a TA could be used (see above) so making it=20
> mandatory=20
> > is not desirable.
> > =20
> >> --
> >> Julien
> >>
> >> Carl Wallace wrote:
> >>> The draft notes that omission of the taName field precludes path=20
> >>> validation.  Given that TAs serve other purposes that don't
> >> require DNs,
> >>> making the field optional makes sense.  All three formats
> >> in the draft
> >>> support including a DN.  This allows the 5280 requirement to be
> >>> satisfied with each structure.  =20
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked]=20
> >>>> [mailto:[email-masked]] On Behalf Of Tom Gindin
> >>>> Sent: Wednesday, March 04, 2009 8:41 PM
> >>>> To: Julien Stern
> >>>> Cc: [email-masked]
> >>>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> >>>>
> >>>>
> >>>>         Julian:
> >>>>
> >>>>         I think you're wrong in believing that the name=20
> is central=20
> >>>> to the definition of a trust anchor.  I can have (and my browser=20
> >>>> may be shipped
> >>>> with) several trust anchors issued by the same organization, and=20
> >>>> the names which distinguish them are (to me as the=20
> manager of the=20
> >>>> trust store) quite arbitrary.  A typical example is that=20
> there are=20
> >>>> two separate CA certificates from Entrust with CN=3D"Entrust.net=20
> >>>> Secure Server Certification Authority".  Their OU's are slightly=20
> >>>> different, and one of them has a Country attribute.
> >>>>         While philosophically I completely disagree with=20
> you, RFC=20
> >>>> 5280 section 6.1.1 point d-1 requires that the trust=20
> anchor have an=20
> >>>> issuer name, as does the same section in 3280.
> >>>>  Thus, no trust anchor definition which does not include=20
> an issuer=20
> >>>> name can be used by our own existing algorithms.  I=20
> think that's a=20
> >>>> pretty good reason for PKIX to require the presence of a=20
> DN in this=20
> >>>> definition.
> >>>>
> >>>>                 Tom Gindin
> >>>>
> >>>> P.S. - These views are mine personally, and not=20
> necessarily those=20
> >>>> of my employer
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Julien Stern <[email-masked]> Sent by:=20
> >>>> [email-masked]
> >>>> 03/04/2009 01:43 PM
> >>>>
> >>>> To
> >>>>
> >>>> cc
> >>>> [email-masked]
> >>>> Subject
> >>>> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> [email-masked] wrote:
> >>>>> 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           : Trust Anchor Format
> >>>>>                Author(s)       : R. Housley, et al.
> >>>>>                Filename        :=20
> draft-ietf-pkix-ta-format-01.txt
> >>>>>                Pages           : 17
> >>>>>                Date            : 2009-03-04
> >>>>>
> >>>> Hi again,
> >>>>
> >>>> separating from the previous email due to the nature of
> >> the comment:=20
> >>>> this one is more "philosophical" :)
> >>>>
> >>>> This draft defines a trust anchor as a public key with=20
> additional=20
> >>>> data.
> >>>>
> >>>> I believe that the most common usage of the word "trust anchor"=20
> >>>> denotes the _binding_ of a public key _and_ a name. A=20
> certificate=20
> >>>> binds a name and a public key (along with other=20
> information) thanks=20
> >>>> to a signature. A trust anchor binds them through direct trust.
> >>>>
> >>>> And indeed, the definition in X.509 is:
> >>>>
> >>>> trust anchor: A trust anchor is a set of the following
> >> information in
> >>>> addition to the public key: algorithm identifier, public key=20
> >>>> parameters (if applicable), distinguished name of the=20
> holder of the
> >> associated
> >>>> private key (i.e., the subject CA) and optionally a validity=20
> >>>> period. The trust anchor may be provided in the form of a=20
> >>>> self-signed
> >> certificate.
> >>>> A trust anchor is trusted by a certificate using system
> >> and used for
> >>>> validating certificates in certification paths.
> >>>>
> >>>>
> >>>> I assume that you did not choose to make the DN optional without=20
> >>>> reason.
> >>>> But is that really something that we would like to have?=20
> Are there=20
> >>>> really cases where we want to use a public key without=20
> explicitly=20
> >>>> knowing whom it belongs to? Isn't there a risk to spread
> >> confusion on
> >>>> what a "trust anchor" is?
> >>>>
> >>>> Granted, this RFC could define a Trust Anchor in a more
> >> global scope,
> >>>> without a need to bind it to a DN, but I'm (very
> >> personally) not sure
> >>>> this is a great idea and I believe that mandating the=20
> presence of a=20
> >>>> DN would not bring a strong limitation.
> >>>>
> >>>> Have you considered moving the taName from the=20
> CertPathControls to=20
> >>>> the main structure (TrustAnchorInfo) and keeping the=20
> >>>> CertPathControls structure for fine tuning of the X.509 input=20
> >>>> algorithm?
> >>>>
> >>>> (And along the same lines, why is the KeyIdentifier
> >> mandatory and not
> >>>> optional?)
> >>>>
> >>>> Regards,
> >>>>
> >>>> --
> >>>> Julien
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >=20
> >=20
>=20

Date: Thu, 05 Mar 2009 09:00:46 -0500
To: Julien Stern <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Cc: [email-masked]
Sender: [email-masked]

Julien:

>I fully share your view that the "other policy information" should 
>only be an optional part of the trust anchor. However, I feel that 
>the name is a fundamental part of the trust anchor. A trust anchor 
>without a name, in my opinion, would be like a certificate without a name.

I have no objection to the taName becoming a mandatory element of the 
structure.  It is certainly needed for certification path 
construction and validation.  However, in the TAMP context, there are 
messages that are signed directly by the trust anchor.  In this case, 
a key identifier without a name is sufficient.  This element is 
optional to allow for a trust anchor that is able to sign such 
messages but not allowed to sign certificates.  So, if the taName 
becomes non-optional, another mechanism is needed to indicate whether 
the trust anchor can sign certificates.

Russ

Date: Thu, 05 Mar 2009 16:09:35 +0100
From: Julien Stern <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: Tom Gindin <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Sender: [email-masked]

Carl,

Thanks for your reply.
I'm starting to see some of the rationale better.

What still slightly bothers me is the following:

I keep on thinking it would bring major confusion to say that a trust 
anchor can be reduced to a public key. A trust anchor has to be an 
_identified_ public key, else it's just... well... a public key.

Now, I feel I'm starting to understand why the keyIdentifier is always 
mandatory. Maybe you meant to be using this key identifier as a generic 
"name" for the key? In which case, we do have a difference between a 
public key and a trust anchor, e.g. the key is "identified". However, 
this keyIdentifier is usually directly inferred from the public key, so 
this "identification" is a weak one at best.

The very beginning of the TA draft says: "A trust anchor is an 
authoritative entity represented by a public key and associated data."
The bare minimum currently allowed is the key and the keyIdentifier.

I fail to see how the authoritative entity comes into play here. In all 
the examples you gave below, we may possibly go through a keyIdentifier 
instead of a DN to find the public key used to signing, but it does not 
make sense to use this key if it is an "anonymous" key.

Maybe, an other way to highlight the difference in our views is that you 
assume the "identification" of the key can be performed by external 
means? In which case, a trust anchor could be a public key whose owner 
happens to be known by external means or be implicit from the context? 
And that I believe the identity of the "authoritative entity" should be 
explicitly stated in the TA?

Regards,

--
Julien

Carl Wallace wrote:
> Inline...
> 
>> -----Original Message-----
>> From: Julien Stern [mailto:[email-masked]] 
>> Sent: Thursday, March 05, 2009 8:09 AM
>> To: Carl Wallace
>> Cc: Tom Gindin; [email-masked]
>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>
>> Carl,
>>
>> well, there may be strong "philosophical" disagreements from 
>> yourself and/or Tom of what a trust anchor is (which is fine 
>> :) ), but could you give an example of an actual use of a 
>> trust anchor that do not require an identity?
> 
> CMS does not use a DN to identify a signer.  Timestamps, firmware
> packages and key packages are all examples of objects signed using CMS
> that could be verified using a TA that is not named using a DN but
> identified with a key identifier.  OCSP responses aren't signed using
> CMS but can also identify a signer using a key identifier and may be
> validated by a TA. 
>  
>> Again, my humble personal view is that a PKI in general is 
>> before all used to link cryptographic key to identities. This 
>> can be done by direct trust (e.g. a trust anchor) or vouched 
>> by an other entity (e.g. a certificate). This is why I 
>> believe the identity is a fundamental part of a trust anchor. 
>> Now the fact that this identity should be a DN is not as 
>> fundamental (it could be a string), but considering the 
>> global context, a DN is really what makes senses.
> 
> You could choose to use a DN and/or a TA title in all TAs used in your
> environment.
>  
>> I read the fact that omission of the taName precludes path 
>> validation (and I naturally concur), but I actually think 
>> that omission of that name precludes _any_ usage of the 
>> corresponding public key, and that therefore the DN should be 
>> made mandatory in all cases.
> 
> The DN is required by 5280 for name chaining.  A DN is not required in
> all cases where a TA could be used (see above) so making it mandatory is
> not desirable.
>  
>> --
>> Julien
>>
>> Carl Wallace wrote:
>>> The draft notes that omission of the taName field precludes path
>>> validation.  Given that TAs serve other purposes that don't 
>> require DNs,
>>> making the field optional makes sense.  All three formats 
>> in the draft
>>> support including a DN.  This allows the 5280 requirement to be
>>> satisfied with each structure.   
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] 
>>>> [mailto:[email-masked]] On Behalf Of Tom Gindin
>>>> Sent: Wednesday, March 04, 2009 8:41 PM
>>>> To: Julien Stern
>>>> Cc: [email-masked]
>>>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>>>
>>>>
>>>>         Julian:
>>>>
>>>>         I think you're wrong in believing that the name is 
>>>> central to the definition of a trust anchor.  I can have (and 
>>>> my browser may be shipped
>>>> with) several trust anchors issued by the same organization, 
>>>> and the names which distinguish them are (to me as the  
>>>> manager of the trust store) quite arbitrary.  A typical 
>>>> example is that there are two separate CA certificates from 
>>>> Entrust with CN="Entrust.net Secure Server Certification 
>>>> Authority".  Their OU's are slightly different, and one of 
>>>> them has a Country attribute.
>>>>         While philosophically I completely disagree with you, 
>>>> RFC 5280 section 6.1.1 point d-1 requires that the trust 
>>>> anchor have an issuer name, as does the same section in 3280. 
>>>>  Thus, no trust anchor definition which does not include an 
>>>> issuer name can be used by our own existing algorithms.  I 
>>>> think that's a pretty good reason for PKIX to require the 
>>>> presence of a DN in this definition.
>>>>
>>>>                 Tom Gindin
>>>>
>>>> P.S. - These views are mine personally, and not necessarily 
>>>> those of my employer
>>>>
>>>>
>>>>
>>>>
>>>> Julien Stern <[email-masked]> 
>>>> Sent by: [email-masked]
>>>> 03/04/2009 01:43 PM
>>>>
>>>> To
>>>>
>>>> cc
>>>> [email-masked]
>>>> Subject
>>>> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [email-masked] wrote:
>>>>> 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           : Trust Anchor Format
>>>>>                Author(s)       : R. Housley, et al.
>>>>>                Filename        : draft-ietf-pkix-ta-format-01.txt
>>>>>                Pages           : 17
>>>>>                Date            : 2009-03-04
>>>>>
>>>> Hi again,
>>>>
>>>> separating from the previous email due to the nature of 
>> the comment: 
>>>> this one is more "philosophical" :)
>>>>
>>>> This draft defines a trust anchor as a public key with 
>>>> additional data.
>>>>
>>>> I believe that the most common usage of the word "trust 
>>>> anchor" denotes 
>>>> the _binding_ of a public key _and_ a name. A certificate 
>>>> binds a name 
>>>> and a public key (along with other information) thanks to a 
>>>> signature. A 
>>>> trust anchor binds them through direct trust.
>>>>
>>>> And indeed, the definition in X.509 is:
>>>>
>>>> trust anchor: A trust anchor is a set of the following 
>> information in 
>>>> addition to the public key: algorithm identifier, public key 
>>>> parameters 
>>>> (if applicable), distinguished name of the holder of the 
>> associated 
>>>> private key (i.e., the subject CA) and optionally a validity 
>>>> period. The 
>>>> trust anchor may be provided in the form of a self-signed 
>> certificate.
>>>> A trust anchor is trusted by a certificate using system 
>> and used for 
>>>> validating certificates in certification paths.
>>>>
>>>>
>>>> I assume that you did not choose to make the DN optional 
>>>> without reason. 
>>>> But is that really something that we would like to have? Are there 
>>>> really cases where we want to use a public key without explicitly 
>>>> knowing whom it belongs to? Isn't there a risk to spread 
>> confusion on 
>>>> what a "trust anchor" is?
>>>>
>>>> Granted, this RFC could define a Trust Anchor in a more 
>> global scope, 
>>>> without a need to bind it to a DN, but I'm (very 
>> personally) not sure 
>>>> this is a great idea and I believe that mandating the 
>>>> presence of a DN 
>>>> would not bring a strong limitation.
>>>>
>>>> Have you considered moving the taName from the 
>>>> CertPathControls to the 
>>>> main structure (TrustAnchorInfo) and keeping the CertPathControls 
>>>> structure for fine tuning of the X.509 input algorithm?
>>>>
>>>> (And along the same lines, why is the KeyIdentifier 
>> mandatory and not 
>>>> optional?)
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Julien
>>>>
>>>>
>>>>
>>>>
>>>
>>
> 
> 

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-other-certs-02.txt 
Date: Thu,  5 Mar 2009 06:00:01 -0800 (PST)
Sender: [email-masked]

--NextPart

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

	Title           : Other Certificates Extension
	Author(s)       : S. Farrell
	Filename        : draft-ietf-pkix-other-certs-02.txt
	Pages           : 8
	Date            : 2009-03-05

Some applications that associate state information with public key
certificates can benefit from a way to link together a set of
certificates belonging to the same end entity that can safely be
considered to be equivalent for the purposes of referencing that
application state information.  This memo defines a certificate
extension that allows applications to establish the required linkage
without introducing a new application protocol data unit.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-other-certs-02.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-other-certs-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Thu, 5 Mar 2009 08:34:42 -0500
From: "Carl Wallace" <[email-masked]>
To: "Julien Stern" <[email-masked]>
Cc: "Tom Gindin" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Inline...

> -----Original Message-----
> From: Julien Stern [mailto:[email-masked]]=20
> Sent: Thursday, March 05, 2009 8:09 AM
> To: Carl Wallace
> Cc: Tom Gindin; [email-masked]
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
> Carl,
>=20
> well, there may be strong "philosophical" disagreements from=20
> yourself and/or Tom of what a trust anchor is (which is fine=20
> :) ), but could you give an example of an actual use of a=20
> trust anchor that do not require an identity?

CMS does not use a DN to identify a signer.  Timestamps, firmware
packages and key packages are all examples of objects signed using CMS
that could be verified using a TA that is not named using a DN but
identified with a key identifier.  OCSP responses aren't signed using
CMS but can also identify a signer using a key identifier and may be
validated by a TA.=20
=20
> Again, my humble personal view is that a PKI in general is=20
> before all used to link cryptographic key to identities. This=20
> can be done by direct trust (e.g. a trust anchor) or vouched=20
> by an other entity (e.g. a certificate). This is why I=20
> believe the identity is a fundamental part of a trust anchor.=20
> Now the fact that this identity should be a DN is not as=20
> fundamental (it could be a string), but considering the=20
> global context, a DN is really what makes senses.

You could choose to use a DN and/or a TA title in all TAs used in your
environment.
=20
> I read the fact that omission of the taName precludes path=20
> validation (and I naturally concur), but I actually think=20
> that omission of that name precludes _any_ usage of the=20
> corresponding public key, and that therefore the DN should be=20
> made mandatory in all cases.

The DN is required by 5280 for name chaining.  A DN is not required in
all cases where a TA could be used (see above) so making it mandatory is
not desirable.
=20
> --
> Julien
>=20
> Carl Wallace wrote:
> > The draft notes that omission of the taName field precludes path
> > validation.  Given that TAs serve other purposes that don't=20
> require DNs,
> > making the field optional makes sense.  All three formats=20
> in the draft
> > support including a DN.  This allows the 5280 requirement to be
> > satisfied with each structure.  =20
> >=20
> >> -----Original Message-----
> >> From: [email-masked]=20
> >> [mailto:[email-masked]] On Behalf Of Tom Gindin
> >> Sent: Wednesday, March 04, 2009 8:41 PM
> >> To: Julien Stern
> >> Cc: [email-masked]
> >> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> >>
> >>
> >>         Julian:
> >>
> >>         I think you're wrong in believing that the name is=20
> >> central to the definition of a trust anchor.  I can have (and=20
> >> my browser may be shipped
> >> with) several trust anchors issued by the same organization,=20
> >> and the names which distinguish them are (to me as the =20
> >> manager of the trust store) quite arbitrary.  A typical=20
> >> example is that there are two separate CA certificates from=20
> >> Entrust with CN=3D"Entrust.net Secure Server Certification=20
> >> Authority".  Their OU's are slightly different, and one of=20
> >> them has a Country attribute.
> >>         While philosophically I completely disagree with you,=20
> >> RFC 5280 section 6.1.1 point d-1 requires that the trust=20
> >> anchor have an issuer name, as does the same section in 3280.=20
> >>  Thus, no trust anchor definition which does not include an=20
> >> issuer name can be used by our own existing algorithms.  I=20
> >> think that's a pretty good reason for PKIX to require the=20
> >> presence of a DN in this definition.
> >>
> >>                 Tom Gindin
> >>
> >> P.S. - These views are mine personally, and not necessarily=20
> >> those of my employer
> >>
> >>
> >>
> >>
> >> Julien Stern <[email-masked]>=20
> >> Sent by: [email-masked]
> >> 03/04/2009 01:43 PM
> >>
> >> To
> >>
> >> cc
> >> [email-masked]
> >> Subject
> >> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> [email-masked] wrote:
> >>> A New Internet-Draft is available from the on-line=20
> Internet-Drafts=20
> >> directories.
> >>> This draft is a work item of the Public-Key=20
> Infrastructure (X.509)=20
> >> Working Group of the IETF.
> >>>
> >>>                Title           : Trust Anchor Format
> >>>                Author(s)       : R. Housley, et al.
> >>>                Filename        : draft-ietf-pkix-ta-format-01.txt
> >>>                Pages           : 17
> >>>                Date            : 2009-03-04
> >>>
> >> Hi again,
> >>
> >> separating from the previous email due to the nature of=20
> the comment:=20
> >> this one is more "philosophical" :)
> >>
> >> This draft defines a trust anchor as a public key with=20
> >> additional data.
> >>
> >> I believe that the most common usage of the word "trust=20
> >> anchor" denotes=20
> >> the _binding_ of a public key _and_ a name. A certificate=20
> >> binds a name=20
> >> and a public key (along with other information) thanks to a=20
> >> signature. A=20
> >> trust anchor binds them through direct trust.
> >>
> >> And indeed, the definition in X.509 is:
> >>
> >> trust anchor: A trust anchor is a set of the following=20
> information in=20
> >> addition to the public key: algorithm identifier, public key=20
> >> parameters=20
> >> (if applicable), distinguished name of the holder of the=20
> associated=20
> >> private key (i.e., the subject CA) and optionally a validity=20
> >> period. The=20
> >> trust anchor may be provided in the form of a self-signed=20
> certificate.
> >> A trust anchor is trusted by a certificate using system=20
> and used for=20
> >> validating certificates in certification paths.
> >>
> >>
> >> I assume that you did not choose to make the DN optional=20
> >> without reason.=20
> >> But is that really something that we would like to have? Are there=20
> >> really cases where we want to use a public key without explicitly=20
> >> knowing whom it belongs to? Isn't there a risk to spread=20
> confusion on=20
> >> what a "trust anchor" is?
> >>
> >> Granted, this RFC could define a Trust Anchor in a more=20
> global scope,=20
> >> without a need to bind it to a DN, but I'm (very=20
> personally) not sure=20
> >> this is a great idea and I believe that mandating the=20
> >> presence of a DN=20
> >> would not bring a strong limitation.
> >>
> >> Have you considered moving the taName from the=20
> >> CertPathControls to the=20
> >> main structure (TrustAnchorInfo) and keeping the CertPathControls=20
> >> structure for fine tuning of the X.509 input algorithm?
> >>
> >> (And along the same lines, why is the KeyIdentifier=20
> mandatory and not=20
> >> optional?)
> >>
> >> Regards,
> >>
> >> --
> >> Julien
> >>
> >>
> >>
> >>
> >=20
> >=20
>=20
>=20

Date: Thu, 05 Mar 2009 14:18:44 +0100
From: Julien Stern <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Sender: [email-masked]

Carl Wallace wrote:
> <snip>
>> One first comment regarding the CertPolicyFlags:
>>
>> They are defined as:
>>
>> CertPolicyFlags ::= BIT STRING {
>>        inhibitPolicyMapping   (0),
>>        requireExplicitPolicy  (1),
>>        inhibitAnyPolicy       (2) }
>>
>> But in 5280, they are integer, not booleans, for example:
>>
>> PolicyConstraints ::= SEQUENCE {
>>       requireExplicitPolicy   [0]     SkipCerts OPTIONAL,
>>       inhibitPolicyMapping    [1]     SkipCerts OPTIONAL }
>>
>> SkipCerts ::= INTEGER (0..MAX)
>>
>> I believe that we should keep them integers to keep the full 
>> generality (unless I missed a point).
> 
> The booleans align with the inputs to the path validation algorithm.
> Ideally, those would have been integers too.

Hmm... That a tricky point I think. I agree that the validation 
algorithm has currently described takes booleans.

However,
1) It is allowed to augment the algorithm (and that would be a 
worthwhile augmentation)
2) What are some existing algorithm doing?Iif the indicator is set to 
true, some will look at the extension in the trust anchor to initialize 
a value which will be an integer, and not a boolean anymore.

So, if we leave them as boolean in the trust anchor, we will prevent 
trust anchor from defining these values, especially considering that the 
RFC explicitly states that the extensions which contains these elements 
should be ignored.

--
Julien

Date: Thu, 05 Mar 2009 14:09:20 +0100
From: Julien Stern <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: Tom Gindin <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Sender: [email-masked]

Carl,

well, there may be strong "philosophical" disagreements from yourself 
and/or Tom of what a trust anchor is (which is fine :) ), but could you 
give an example of an actual use of a trust anchor that do not require 
an identity?

Again, my humble personal view is that a PKI in general is before all 
used to link cryptographic key to identities. This can be done by direct 
trust (e.g. a trust anchor) or vouched by an other entity (e.g. a 
certificate). This is why I believe the identity is a fundamental part 
of a trust anchor. Now the fact that this identity should be a DN is not 
as fundamental (it could be a string), but considering the global 
context, a DN is really what makes senses.

I read the fact that omission of the taName precludes path validation 
(and I naturally concur), but I actually think that omission of that 
name precludes _any_ usage of the corresponding public key, and that 
therefore the DN should be made mandatory in all cases.

--
Julien

Carl Wallace wrote:
> The draft notes that omission of the taName field precludes path
> validation.  Given that TAs serve other purposes that don't require DNs,
> making the field optional makes sense.  All three formats in the draft
> support including a DN.  This allows the 5280 requirement to be
> satisfied with each structure.   
> 
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Tom Gindin
>> Sent: Wednesday, March 04, 2009 8:41 PM
>> To: Julien Stern
>> Cc: [email-masked]
>> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>
>>
>>         Julian:
>>
>>         I think you're wrong in believing that the name is 
>> central to the definition of a trust anchor.  I can have (and 
>> my browser may be shipped
>> with) several trust anchors issued by the same organization, 
>> and the names which distinguish them are (to me as the  
>> manager of the trust store) quite arbitrary.  A typical 
>> example is that there are two separate CA certificates from 
>> Entrust with CN="Entrust.net Secure Server Certification 
>> Authority".  Their OU's are slightly different, and one of 
>> them has a Country attribute.
>>         While philosophically I completely disagree with you, 
>> RFC 5280 section 6.1.1 point d-1 requires that the trust 
>> anchor have an issuer name, as does the same section in 3280. 
>>  Thus, no trust anchor definition which does not include an 
>> issuer name can be used by our own existing algorithms.  I 
>> think that's a pretty good reason for PKIX to require the 
>> presence of a DN in this definition.
>>
>>                 Tom Gindin
>>
>> P.S. - These views are mine personally, and not necessarily 
>> those of my employer
>>
>>
>>
>>
>> Julien Stern <[email-masked]> 
>> Sent by: [email-masked]
>> 03/04/2009 01:43 PM
>>
>> To
>>
>> cc
>> [email-masked]
>> Subject
>> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>>
>>
>>
>>
>>
>>
>>
>> [email-masked] wrote:
>>> 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           : Trust Anchor Format
>>>                Author(s)       : R. Housley, et al.
>>>                Filename        : draft-ietf-pkix-ta-format-01.txt
>>>                Pages           : 17
>>>                Date            : 2009-03-04
>>>
>> Hi again,
>>
>> separating from the previous email due to the nature of the comment: 
>> this one is more "philosophical" :)
>>
>> This draft defines a trust anchor as a public key with 
>> additional data.
>>
>> I believe that the most common usage of the word "trust 
>> anchor" denotes 
>> the _binding_ of a public key _and_ a name. A certificate 
>> binds a name 
>> and a public key (along with other information) thanks to a 
>> signature. A 
>> trust anchor binds them through direct trust.
>>
>> And indeed, the definition in X.509 is:
>>
>> trust anchor: A trust anchor is a set of the following information in 
>> addition to the public key: algorithm identifier, public key 
>> parameters 
>> (if applicable), distinguished name of the holder of the associated 
>> private key (i.e., the subject CA) and optionally a validity 
>> period. The 
>> trust anchor may be provided in the form of a self-signed certificate.
>> A trust anchor is trusted by a certificate using system and used for 
>> validating certificates in certification paths.
>>
>>
>> I assume that you did not choose to make the DN optional 
>> without reason. 
>> But is that really something that we would like to have? Are there 
>> really cases where we want to use a public key without explicitly 
>> knowing whom it belongs to? Isn't there a risk to spread confusion on 
>> what a "trust anchor" is?
>>
>> Granted, this RFC could define a Trust Anchor in a more global scope, 
>> without a need to bind it to a DN, but I'm (very personally) not sure 
>> this is a great idea and I believe that mandating the 
>> presence of a DN 
>> would not bring a strong limitation.
>>
>> Have you considered moving the taName from the 
>> CertPathControls to the 
>> main structure (TrustAnchorInfo) and keeping the CertPathControls 
>> structure for fine tuning of the X.509 input algorithm?
>>
>> (And along the same lines, why is the KeyIdentifier mandatory and not 
>> optional?)
>>
>> Regards,
>>
>> --
>> Julien
>>
>>
>>
>>
> 
> 

Date: Thu, 05 Mar 2009 13:59:38 +0100
From: Julien Stern <[email-masked]>
To: Tom Gindin <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Sender: [email-masked]

Tom,

you are having me slightly confused here. You say that a name is not 
central to the definition of a trust anchor, but you quote examples of 
trust anchors that includes names. Also, I fail to see any examples of 
trust anchors without names.

I think just as you do that PKIX should require the presence of a DN and 
I was wondering why this DN was not simply always mandatory. What is the 
use of a key not linked to an identity?

Regards,

--
Julien

Tom Gindin wrote:
>         Julian:
> 
>         I think you're wrong in believing that the name is central to the 
> definition of a trust anchor.  I can have (and my browser may be shipped 
> with) several trust anchors issued by the same organization, and the names 
> which distinguish them are (to me as the  manager of the trust store) 
> quite arbitrary.  A typical example is that there are two separate CA 
> certificates from Entrust with CN="Entrust.net Secure Server Certification 
> Authority".  Their OU's are slightly different, and one of them has a 
> Country attribute.
>         While philosophically I completely disagree with you, RFC 5280 
> section 6.1.1 point d-1 requires that the trust anchor have an issuer 
> name, as does the same section in 3280.  Thus, no trust anchor definition 
> which does not include an issuer name can be used by our own existing 
> algorithms.  I think that's a pretty good reason for PKIX to require the 
> presence of a DN in this definition.
> 
>                 Tom Gindin
> 
> P.S. - These views are mine personally, and not necessarily those of my 
> employer
> 
> 
> 
> 
> Julien Stern <[email-masked]> 
> Sent by: [email-masked]
> 03/04/2009 01:43 PM
> 
> To
> 
> cc
> [email-masked]
> Subject
> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> 
> 
> 
> 
> 
> 
> 
> [email-masked] wrote:
>> 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           : Trust Anchor Format
>>                Author(s)       : R. Housley, et al.
>>                Filename        : draft-ietf-pkix-ta-format-01.txt
>>                Pages           : 17
>>                Date            : 2009-03-04
>>
> 
> Hi again,
> 
> separating from the previous email due to the nature of the comment: 
> this one is more "philosophical" :)
> 
> This draft defines a trust anchor as a public key with additional data.
> 
> I believe that the most common usage of the word "trust anchor" denotes 
> the _binding_ of a public key _and_ a name. A certificate binds a name 
> and a public key (along with other information) thanks to a signature. A 
> trust anchor binds them through direct trust.
> 
> And indeed, the definition in X.509 is:
> 
> trust anchor: A trust anchor is a set of the following information in 
> addition to the public key: algorithm identifier, public key parameters 
> (if applicable), distinguished name of the holder of the associated 
> private key (i.e., the subject CA) and optionally a validity period. The 
> trust anchor may be provided in the form of a self-signed certificate.
> A trust anchor is trusted by a certificate using system and used for 
> validating certificates in certification paths.
> 
> 
> I assume that you did not choose to make the DN optional without reason. 
> But is that really something that we would like to have? Are there 
> really cases where we want to use a public key without explicitly 
> knowing whom it belongs to? Isn't there a risk to spread confusion on 
> what a "trust anchor" is?
> 
> Granted, this RFC could define a Trust Anchor in a more global scope, 
> without a need to bind it to a DN, but I'm (very personally) not sure 
> this is a great idea and I believe that mandating the presence of a DN 
> would not bring a strong limitation.
> 
> Have you considered moving the taName from the CertPathControls to the 
> main structure (TrustAnchorInfo) and keeping the CertPathControls 
> structure for fine tuning of the X.509 input algorithm?
> 
> (And along the same lines, why is the KeyIdentifier mandatory and not 
> optional?)
> 
> Regards,
> 
> --
> Julien
> 
> 
> 

Date: Thu, 05 Mar 2009 13:55:11 +0100
From: Julien Stern <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Sender: [email-masked]

Russ,

Comments in line.

Regards,

--
Julien

Russ Housley wrote:
> 
> Julien:
> 
> X.509 did not originally include a definition of trust anchor.  RFC 2459 
> follow this example, and it caused problems when describing 
> certification path validation.  Since RFC 3280 added a lot of material 
> on this topic, a definition was needed.  RFC 3280 includes:
> 
>    In section 6.1, the text describes basic path validation.  Valid
>    paths begin with certificates issued by a trust anchor.  The
>    algorithm requires the public key of the CA, the CA's name, and any
>    constraints upon the set of paths which may be validated using this
>    key.
> 
> I consider these constraints to be additional data.  The RFC 3280 
> definition is saying what is needed in a trust anchor for the path 
> validation algorithm.  Constraints are implemented through settings in 
> the path validation algorithm.  However, I do not see anything in this 
> text that says other policy information cannot be part of a trust 
> anchor.  The text you quote includes validity period, and I consider 
> this to be an example of such policy information.

I fully share your view that the "other policy information" should only 
be an optional part of the trust anchor. However, I feel that the name 
is a fundamental part of the trust anchor. A trust anchor without a 
name, in my opinion, would be like a certificate without a name.

> RFC 2459, RFC 3280, and RFC 5280 have all required CA certificates to 
> include a Distinguished Name.  This is important for constructing a 
> certification path and for identifying a particular certificate in a CRL.
> 
> The taName is needed for certification path construction and 
> validation.  I do not really care if it is placed in a separate OPTIONAL 
> element of TrustAnchorInfo.  How would this change help you?

Well, again, I was wondering about moving the taName up one level, but 
to keep it mandatory not OPTIONAL. I mean, in which use cases would you 
need a key which is not linked to an identity?

> TAMP requires a key identifier.  This format was originally embedded in 
> TAMP.  I guess this linkage remains.  I do point out that a key 
> identifier could be computed from the public key using the technique 
> described in RFC 5280, so this is not an onerous requirement.

OK. Fair enough. Thanks for the clarification.

> Russ
> 
> 
> At 01:43 PM 3/4/2009, Julien Stern wrote:
> 
>> [email-masked] wrote:
>>> 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           : Trust Anchor Format
>>>         Author(s)       : R. Housley, et al.
>>>         Filename        : draft-ietf-pkix-ta-format-01.txt
>>>         Pages           : 17
>>>         Date            : 2009-03-04
>>
>> Hi again,
>>
>> separating from the previous email due to the nature of the comment: 
>> this one is more "philosophical" :)
>>
>> This draft defines a trust anchor as a public key with additional data.
>>
>> I believe that the most common usage of the word "trust anchor" 
>> denotes the _binding_ of a public key _and_ a name. A certificate 
>> binds a name and a public key (along with other information) thanks to 
>> a signature. A trust anchor binds them through direct trust.
>>
>> And indeed, the definition in X.509 is:
>>
>> trust anchor: A trust anchor is a set of the following information in 
>> addition to the public key: algorithm identifier, public key 
>> parameters (if applicable), distinguished name of the holder of the 
>> associated private key (i.e., the subject CA) and optionally a 
>> validity period. The trust anchor may be provided in the form of a 
>> self-signed certificate.
>> A trust anchor is trusted by a certificate using system and used for 
>> validating certificates in certification paths.
>>
>>
>> I assume that you did not choose to make the DN optional without 
>> reason. But is that really something that we would like to have? Are 
>> there really cases where we want to use a public key without 
>> explicitly knowing whom it belongs to? Isn't there a risk to spread 
>> confusion on what a "trust anchor" is?
>>
>> Granted, this RFC could define a Trust Anchor in a more global scope, 
>> without a need to bind it to a DN, but I'm (very personally) not sure 
>> this is a great idea and I believe that mandating the presence of a DN 
>> would not bring a strong limitation.
>>
>> Have you considered moving the taName from the CertPathControls to the 
>> main structure (TrustAnchorInfo) and keeping the CertPathControls 
>> structure for fine tuning of the X.509 input algorithm?
>>
>> (And along the same lines, why is the KeyIdentifier mandatory and not 
>> optional?)
>>
>> Regards,
>>
>> -- 
>> Julien
>>
> 

Date: Thu, 5 Mar 2009 06:42:03 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: message from SangHwan Park, forwarded to the list
Sender: [email-masked]

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

>Dear David A. Cooper and Kemp, David,
>
>First, I'd like to thank you for the comments.
>
>I've included my responses in blue in-line below for each item.
>
>Thank you.
>
>---------------------
>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.
>
>Park) In "An architecture of Pseudonymous e-Commerce", the CA A you 
>mentioned above knows of the links between user's real identity and 
>pseudonymous subject name of certificate. It means that CA A can 
>trace user's real identity with the certificate with pseudonymous 
>certificate that is used. The main differences from the "An 
>architecture of Pseudonymous e-Commerce" is that TAC can secure the 
>anonymity not only in the issuance processes but also in the usages 
>of certificate, separating AI and BI's duties with the help of  both 
>threshold and blind signature scheme. The paper you inquired just 
>focuses on the usage of certificate, not on the anonymity in the 
>issuing processes.
>
>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?
>Park) With the technology of threshold and blind signature scheme, 
>we can separate the duties of which each AI or BI takes. In other 
>words, AI and BI have its shares of the private keys beforehand; 
>subscribers authenticates to BI using his/her real identity and 
>requests TAC to AI with the Token issued by BI. AI and BI 
>bilaterally digital-signs TAC with the threshold signature scheme. 
>The blind signature is used to let BI be blind to the contents of 
>TAC in order to prevent BI from linking the real identity to subject 
>pseudonymous name.
>
>- 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>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.
>Park) You can refer to the blind signing protocol of Chapter 4.2 in 
>the attached pdf above.
>It might be difficult to understand how DSA blind signing protocols work.
>
>- 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.)"?
>
>Park) We'll reword the phrases as you suggested.
>
>- 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).
>Park) We'll revise the Step 4 accordingly to the Step 6.
>
>- 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.
>Park) Right.
>
>- 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.
>Park) We'll revise the text to cite only OCSP, not SCVP.
>
>
>- 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].
>
>Park) We'll revise the text, as you and Kemp, David suggested.
>
>- 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".
>Park) We'll revise the text.
>
>- 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".
>Park) We'll revise the text.
>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.
>
>Park) We will specify a distinct contentType (OID) for each message 
>as an easy approach to distinguishing message types
>- 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.
>Park) We've adopted the term 'Anonymous' to imply the meaning of 
>privacy protection in PKI to RP, beyond the general meaning of the 
>name which is not real whose definition of the term 'pseudonymous' 
>in the subject field.
>
>- 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.
>Park) The threshold scheme(combined with blind signature) is the 
>principal technology for implementing TAC. Even though its adoption 
>makes the protocols and operations complex, this document proposes 
>the experimental mechanisms to achieve the anonymity not only for 
>issuance process but also usage transactions of certificate.
>
>
>-------------------
>SangHwan Park
>Senior Researcher / CISA / CISSP / ITIL
>Korea Information Security Agency(KISA)
>+82-2-405-5428, <mailto:[email-masked]>[email-masked]
>
--============_-975869171==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>message from SangHwan Park, forwarded to the
list</title></head><body>
<blockquote type="cite" cite><font size="-1">Dear David A. Cooper and
Kemp, David,</font></blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">First, I</font><font
face="Times New Roman">'</font>d like to thank you for the
comments.</blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">I've included my
responses in blue in-line below for each item.</font></blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">Thank
you.</font></blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font
size="-1">---------------------</font></blockquote>
<blockquote type="cite" cite><font size="-1">Section 3
(Requirements):</font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">- This section begins by
stating that the &quot;document describes a</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> new separation-of-authority
model&quot;.<font face="Times New Roman">&nbsp;</font> How does the
model in this</blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font> document differ from the one in [13], &quot;An
Architecture for</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> Pseudonymous
e-Commerce&quot;?<font face="Times New Roman">&nbsp;</font> What
properties does the protocol</blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font> in this document have that the protocol in
[13] does not?</blockquote>
<blockquote type="cite" cite><font size="-1"><b>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).</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">This is
incorrect.</font><font face="Times New Roman">&nbsp;</font> In
&quot;An Architecture for Pseudonymous e-Commerce&quot;, the
subscriber requests a certificate from CA A (i.e., the BI).<font
face="Times New Roman">&nbsp;</font> The subscriber authenticates to
CA A using his/her real identity.<font
face="Times New Roman">&nbsp;</font> CA A issues certificate A to the
subscriber with a pseudonymous subject name.<font
face="Times New Roman">&nbsp;</font> The subscriber then requests a
certificate from CA B (i.e., the AI).<font
face="Times New Roman">&nbsp;</font> The subscriber authenticates to
CA B using certificate A.<font face="Times New Roman">&nbsp;</font> 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).<font face="Times New Roman">&nbsp;</font> The
subscriber then uses certificate B to authenticate him/herself during
normal transactions.<font face="Times New Roman">&nbsp;</font> 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.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>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.</blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
In</b></font><font face="Times New Roman" color="#000080"><b>
"</b></font><font color="#000080"><b>An architecture of Pseudonymous
e-Commerce<font face="Times New Roman">"</font>, the CA A you
mentioned above knows of the links between user<font
face="Times New Roman">'</font>s real identity and pseudonymous
subject name of certificate. It means that CA A can trace user<font
face="Arial">'</font>s real identity with the certificate with
pseudonymous certificate that is used. The main differences from
the<font face="Arial"> "</font>An architecture of Pseudonymous
e-Commerce<font face="Times New Roman">"</font> is that TAC can
secure the anonymity not only in the issuance processes but also in
the usages of certificate, separating AI and BI<font
face="Times New Roman">'</font>s duties with the help of<font
face="Times New Roman"> &nbsp;</font>both threshold and blind
signature scheme. The paper you inquired just focuses on the usage of
certificate, not on the anonymity in the issuing
processes.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">Section 5 (Issuing a
TAC):</font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">- The protocol involves a
complicated scheme involving split</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> signatures and blind
signatures.<font face="Times New Roman">&nbsp;</font> The use of split
signatures</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> complicates the issuance of both
certificates and CRLs, yet</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> the need for this scheme is not
clear.<font face="Times New Roman">&nbsp;</font> It was
previously</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> argued that the split signature
scheme prevents the CA from</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> issuing a certificate to a user
by itself, which could</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> result in a non-traceable
certificate.<font face="Times New Roman">&nbsp;</font> However, the
CA</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> could still create a
non-traceable certificate by simply</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> not maintaining the link between
the TAC and the Token.</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> An untrustworthy CA could even
use a Token issued by the BI</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> to one user as the basis for
issuing a certificate to a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> different user.<font
face="Times New Roman">&nbsp;</font> Similarly, a BI could issue a
Token to a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> user without first identifying
that user.<font face="Times New Roman">&nbsp;</font> Since both the
AI</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> and BI need to cooperate to
identify the user associated with</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> a TAC, there is no benefit in
trying to prevent the AI from</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> issuing a non-traceable
certificate, as there is no way to</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> force the AI (or BI) from
cooperating in the tracing of a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> certificate if the AI (or BI)
simply chooses not the store</blockquote>
<blockquote type="cite" cite>the information required to perform the
trace.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>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.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">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?</font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
With the technology of threshold and blind signature scheme, we can
separate the duties of which each AI or BI takes. In other words, AI
and BI have its shares of the private keys beforehand; subscribers
authenticates to BI using his/her real identity and requests TAC to AI
with the Token issued by BI. AI and BI bilaterally digital-signs TAC
with the threshold signature scheme. The blind signature is used to
let BI be blind to the contents of TAC in order to prevent BI from
linking the real identity to subject pseudonymous
name.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5 says that
&quot;Blinding is also defined for signature</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font> algorithms like DSA, but the explanation is
more complex, since</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> DSA does not natively encrypt
data.&quot;<font face="Times New Roman">&nbsp;</font> Can a reference
be</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> provided?<font
face="Times New Roman">&nbsp;</font> I can only find references to
papers that propose</blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font> blinding schemes for variants of
DSA.</blockquote>
<blockquote type="cite" cite><font size="-1"><b>You can refer to the
blind DSA signature based on MacKenzie and Reiter,</b></font> <a
href="http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf"><font
size="-1"
color="#0000FF"><u><b
>http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf</b></u></font></a
><font size="-1"><b>.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">This paper seems to
describe a threshold signature scheme (in particular two-party
generation of DSA signatures), not a blind signature
scheme.</font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
You can refer to the blind signing protocol of Chapter 4.2 in the
attached pdf above.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>It
might be difficult to understand how DSA blind signing protocols
work.</b></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.1, Step 1
states &quot;The signature on a Token is</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> generated by the BI using a
private key employed only for</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> this purpose.&quot;<font
face="Times New Roman">&nbsp;</font> Step 2 states &quot;The signature
(SignatureValue</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> of SignerInfo) is generated using
the BI's private signature</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> key, corresponding to the public
key present in the BI's</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> certificate. (Note that this
certificate is just a certificate</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> suitable for use with TLS, and is
NOT the split-key certificate</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> used to verify a
TAC.)&quot;<font face="Times New Roman">&nbsp;</font> May the BI use
the same private key</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> and certificate to sign Tokens
and for TLS authentication?<font face="Times New Roman">&nbsp;</font>
If</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> not (as stated in Step 1), then
why is it necessary for the</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> certificate corresponding to the
Token signing key to be</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> &quot;suitable for use with
TLS&quot;?<font face="Times New Roman">&nbsp;</font> Many other places
in the document</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> state that certificates used to
verify signatures on CMS</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> messages should be &quot;suitable
for use with TLS&quot;.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>There are several questions
here:</b></blockquote>
<blockquote type="cite" cite><font
size="-1"><b><br></b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><b>- 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.</b></font></blockquote>
<blockquote type="cite" cite><font
size="-1"><b><br></b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><b>-</b></font><font
face="Times New Roman"><b>&nbsp;</b></font><b> we use the phrase
&quot;suitable for use with TLS&quot; 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.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">Why not say</font><font
face="Times New Roman"> "</font>(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.)<font
face="Times New Roman">"</font>?</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><font color="#000080"><b>Park) We<font
face="Times New Roman">'</font>ll reword the phrases as you
suggested.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.1, Step 6
states:</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;&nbsp;&nbsp;&nbsp;</font> Note that the user should be
prepared to accommodate delays</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> in the
certificate issuance process. For example, a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> connection
between the user and the AI might fail sometime</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> after the user
submits a certificate request at the end of</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> Step 3 and
before the AI returns the certificate at the end</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> of Step 6. If
this happens, the user should resubmit the</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> request. The AI
and BI retain sufficient state to be able to</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> match the
resubmitted request to the original request, and</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> respond
accordingly.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> This seem appropriate, but it is
contradicted by the following</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> text in Section 5.1, Step
4:</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> Next, the AI
compares the received Token against a cache of</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> recent (i.e.,
not &quot;timed out&quot;), validated Tokens. If a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> duplicate is
detected, the certificate request is rejected as</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> a
replay.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>The comments in step 4 are design
guidance; they don't impose specific constraints on how long an AI
holds onto a Token.<font face="Times New Roman">&nbsp;</font> We can
revise the step 6 text to note that although the AI and BI maintain
state, they do not do so forever.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">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).</font><font
face="Times New Roman">&nbsp;</font> The problem is that Step 4 says
that &quot;If a duplicate is detected, the certificate request is
rejected as a replay&quot;.<font face="Times New Roman">&nbsp;</font>
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).</blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
We</b></font><font face="Times New Roman"
color="#000080"><b>'</b></font><font color="#000080"><b>ll revise the
Step 4 accordingly to the Step 6.</b></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.2, Step A
states that &quot;we propose creating a second</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> CA, under the TAC CA and have it
be the CRL issuer for the EE</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> certificates issued by the TAC
CA.&quot;<font face="Times New Roman">&nbsp;</font> However, the
actual</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> proposal is to create a second
(CRL signing only) key for the</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> CA, not to create a second
CA.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>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.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">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.</font><font face="Times New Roman">&nbsp;</font> You have a single
CA with two keys, one for signing certificates and one for signing
CRLs.</blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
Right.</b></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.2, Step A
states that &quot;If the AI uses OCSP [14] or</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> SCVP [15] to convey the
revocation status of TACs, an equivalent</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> procedure is
employed.&quot;<font face="Times New Roman">&nbsp;</font> SCVP cannot
be used by a CA to convey</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> status information in the same
way that CRLs and OCSP can, and</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> so it should not be mentioned
here.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>SCVP responses are more<font
face="Times New Roman">&nbsp;</font> 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.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">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.</font><font
face="Times New Roman">&nbsp;</font> Section 5.2, Step A is describing
(1), which is appropriate for OCSP but not SCVP.<font
face="Times New Roman">&nbsp;</font> 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.</blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
We</b></font><font face="Times New Roman"
color="#000080"><b>'</b></font><font color="#000080"><b>ll revise the
text to cite only OCSP, not SCVP.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.3.1,
Attributes: &quot;This attribute contains</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> X509v3 Certificate
Extensions.&quot;<font face="Times New Roman">&nbsp;</font> Which
attribute?<font face="Times New Roman">&nbsp;</font> Not
the</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> id-kisa-tac attribute mentioned
in the previous sentence?<font face="Times New Roman">&nbsp;</font>
Is</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> inclusion of extension in the
PKCS10 optional or are there</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> certain extensions that must be
included?</blockquote>
<blockquote type="cite" cite><font size="-1"><b>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.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">The biggest problem is
simply that the text says &quot;this attribute&quot; and I cannot what
tell which attribute it means by &quot;this&quot;.</font><font
face="Times New Roman">&nbsp;</font> Perhaps the text could be
reworded as (if my proposed rewording is technically
correct):</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font>
Attributes</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font
> PKCS10[3] defines the attributes field as key-value pairs<font
face="Times New Roman">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;</font> where the key is an OID and
the value's structure depends on the<font
face="Times New Roman">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;</font> key.<font
face="Times New Roman">&nbsp;</font> The Attributes field MUST include
the id-kisa-tac attribute,</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;</font> which holds the Token and
is defined below.<font face="Times New Roman">&nbsp;</font> The
Attributes field</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;</font> MAY also contain X509v3
Certificate Extensions that the subscriber</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;</font> would like to have included
in the certificate.<font face="Times New Roman">&nbsp;&nbsp;</font>
The profile for</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;</font> extensions in certificate
requests is specified in the RFC5280[2].</blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
We</b></font><font face="Times New Roman"
color="#000080"><b>'</b></font><font color="#000080"><b>ll revise the
text, as you and Kemp, David suggested.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000080">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.3.1
says:</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;</font> This profile
applies the following additional constraints to<font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font> fields
that MAY appear in a CertificationRequest Object:</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font
> signatureAlgorithm</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font
> This field specifies the signature algorithm.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> What does this mean?<font
face="Times New Roman">&nbsp;</font> The signatureAlgorithm is
mandatory and</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> this text does not impose any
constraints on the field.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>We'll fix the text to reflect the fact
that this is a mandatory field.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">Why not simply delete
this?</font><font face="Times New Roman">&nbsp;</font> 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 &quot;additional
constraint&quot;.</blockquote>
<blockquote type="cite" cite><font color="#000080"><b>Park) We<font
face="Times New Roman">'</font>ll revise the
text.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- Section 5.3.2,
Extensions: Is inclusion of extension optional</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> or are there certain extensions
that must be included?</blockquote>
<blockquote type="cite" cite><font size="-1"><b>See the reply above
for 5.3.1.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">As above, the text about
Extensions should simply be deleted unless the document will impose
&quot;additional constraints&quot;.</font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
We</b></font><font face="Times New Roman"
color="#000080"><b>'</b></font><font color="#000080"><b>ll revise the
text.</b></font></blockquote>
<blockquote type="cite" cite><font
size="-1">General:</font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1"><b>We'll review the
document and fix the citation errors.</b></font></blockquote>
<blockquote type="cite" cite><font
size="-1"><b><br></b></font></blockquote>
<blockquote type="cite" cite><font size="-1">- The protocol messages
defined in this document all use the</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> same basic format: a CMS signed
data object.<font face="Times New Roman">&nbsp;</font> For all of
these</blockquote>
<blockquote type="cite" cite>messages, the eContentType is specified
as id-data and</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> (presumably) the MIME type is
application/pkcs7-mime, perhaps</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> with the parameter
smime-type=signed-data.<font face="Times New Roman">&nbsp;</font> Each
of the</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> protocol messages should have its
own MIME type and/or</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> eContentType.<font
face="Times New Roman">&nbsp;</font> Otherwise, there is no way for
the recipient to</blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font> know how to process the data.</blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1"><b>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.</b></font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">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.</font></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
We will specify a distinct contentType (OID) for each message as an
easy approach to distinguishing message types</b></font></blockquote>
<blockquote type="cite" cite><font size="-1">- Referring to the
certificates issued using this protocol as</font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> anonymous rather than
pseudonymous is confusing.<font face="Times New Roman">&nbsp;</font>
The editors</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> note in the Introduction that
pseudonymous is the correct term,</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> but still choose to use the
misleading term &quot;anonymous&quot;.<font
face="Times New Roman">&nbsp;</font> I do</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> not agree that the terms are
commonly used interchangeably, and</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> believe that the use of the
correct term, pseudonymous, would</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> make the privacy properties of
the certificates more clear.</blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font> People already understand the idea of using
different names</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> (pseudonyms) in different
contexts in order to increase privacy.</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> Anonymity is achieved by not
identifying (authenticating)</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> oneself at all, not by
identifying oneself using a pseudonym.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite><b>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.</b></blockquote>
<blockquote type="cite" cite><font size="-1"><br></font></blockquote>
<blockquote type="cite" cite><font size="-1">I have never heard this
definition of pseudonymous.</font><font
face="Times New Roman">&nbsp;</font> 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.</blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
We</b></font><font face="Times New Roman"
color="#000080"><b>'</b></font><font color="#000080"><b>ve adopted the
term<font face="Times New Roman"> '</font>Anonymous<font
face="Times New Roman">'</font> to imply the meaning of privacy
protection in PKI to RP, beyond the general meaning of the name which
is not real whose definition of the term<font face="Times New Roman">
'</font>pseudonymous<font face="Times New Roman">'</font> in the
subject field.</b></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
color="#000000">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font size="-1">- The protocol should
allow for the possibility of rekey.</font><font
face="Times New Roman">&nbsp;</font> In many</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> cases, users will want to use the
same pseudonym for an</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> extended period of time.<font
face="Times New Roman">&nbsp;</font> For example, many people use
a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> pseudonym when posting to message
boards or when selling items</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> on-line (e.g., on eBay).<font
face="Times New Roman">&nbsp;</font> People who earn good reputations
as</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> sellers would not want to have to
periodically change</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> pseudonyms.<font
face="Times New Roman">&nbsp;</font> A TAC for these users would allow
them perform</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> strong authentication to prevent
others from accessing their</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> accounts.<font
face="Times New Roman">&nbsp;</font> The TAC would allow the sellers
to keep their true</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> identities a secret while at the
same time reassuring buyers</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> that sellers' true identities
could be determined in case a</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> seller committed fraud.<font
face="Times New Roman">&nbsp;</font> While this type of scenario may
not</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> have been the original motivation
for TAC, is there any reason</blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font> that it should not be
supported?</blockquote>
<blockquote type="cite" cite><font size="-1"><b>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.</b></font></blockquote>
<blockquote type="cite" cite><font
size="-1"><b><br></b></font></blockquote>
<blockquote type="cite" cite>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.<font face="Times New Roman">&nbsp;</font> 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.</blockquote>
<blockquote type="cite" cite><font size="-1" color="#000080"><b>Park)
The threshold scheme(combined with blind signature) is the principal
technology for implementing TAC. Even though its adoption makes the
protocols and operations complex, this document proposes the
experimental mechanisms to achieve the anonymity not only for issuance
process but also usage transactions of
certificate.</b></font></blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"
size="-1">&nbsp;</font></blockquote>
<blockquote type="cite" cite><font
size="-1">-------------------</font></blockquote>
<blockquote type="cite" cite><font size="-1">SangHwan</font>
Park</blockquote>
<blockquote type="cite" cite><font size="-1">Senior Researcher / CISA
/ CISSP / ITIL</font></blockquote>
<blockquote type="cite" cite><font size="-1">Korea Information
Security Agency(KISA)</font></blockquote>
<blockquote type="cite" cite><font size="-1">+82-2-405-5428,</font> <a
href="mailto:[email-masked]"><font
size="-1">[email-masked]</font></a></blockquote>
<blockquote type="cite" cite><font
size="-1">&nbsp;</font></blockquote>
</body>
</html>
--============_-975869171==_ma============--

Date: Thu, 05 Mar 2009 06:31:01 -0500
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: Stefan Santesson <[email-masked]>, Stephen Kent <[email-masked]>, pkix <[email-masked]>
Subject: Re: Call for agenda items & PRQP
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030202080706010903050505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ciao Stefan, Steve, and pkix-wg,

I would need 10 mins for reporting on the activities about PRQP - we have been
working both with the TERENA (TACAR) and Federal Bridge folks and they are going
to deploy PRQP (at least as experimental). Some interest in the PRQP has also
been expressed by some commercial vendors... so I think that the WG should be
informed of these activities.

Also, from the collaboration with the DHC WG, we have changed the draft and it
seems that we need IANA to assign identifiers for DHCP (both v4 and v6).

One concern that I have is that IANA would not be so keen in assigning DHCP
service identifiers for an experimental-track protocol, but the deployment
of PRQP is actually happening and I would like to have at least those identifiers
standardized before this actually happens. I am not sure about what we shall do
now. The PRQP will be included in the next release of OpenCA as well, therefore
there will soon be a quite large installation base (besides the aforementioned
communities).

Shall we move the status from experimental to standard track ? Is it too early ?
I see that within the WG there is not much activity about PRQP, but in the real
PKI world and Computing Grid communities the situation is different.

I would like to know the opinion of the chair(s) and the people in the WG...

Ciao,
Max

Stefan Santesson wrote:
> IETF in San Francisco is coming up.
> 
> PKIX has a 2.5 hour session directly on the Monday morning March 23 at 0900
> 
> Please let me know if you have anything you whish to present at the meeting.
> *_At least one representative of each active WG document MUST inform me 
> if you need a time slot for that document or not.
> _*
> I would like to have your request for timeslot by Wednesday March 11.
> After that we can always do late adjustments but I appreciate to have 
> your request as early as possible.

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

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

--------------ms030202080706010903050505--

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Wed, 4 Mar 2009 21:48:08 -0500
From: "Carl Wallace" <[email-masked]>
To: "Tom Gindin" <[email-masked]>, "Julien Stern" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

The draft notes that omission of the taName field precludes path
validation.  Given that TAs serve other purposes that don't require DNs,
making the field optional makes sense.  All three formats in the draft
support including a DN.  This allows the 5280 requirement to be
satisfied with each structure.  =20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Tom Gindin
> Sent: Wednesday, March 04, 2009 8:41 PM
> To: Julien Stern
> Cc: [email-masked]
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
>=20
>         Julian:
>=20
>         I think you're wrong in believing that the name is=20
> central to the definition of a trust anchor.  I can have (and=20
> my browser may be shipped
> with) several trust anchors issued by the same organization,=20
> and the names which distinguish them are (to me as the =20
> manager of the trust store) quite arbitrary.  A typical=20
> example is that there are two separate CA certificates from=20
> Entrust with CN=3D"Entrust.net Secure Server Certification=20
> Authority".  Their OU's are slightly different, and one of=20
> them has a Country attribute.
>         While philosophically I completely disagree with you,=20
> RFC 5280 section 6.1.1 point d-1 requires that the trust=20
> anchor have an issuer name, as does the same section in 3280.=20
>  Thus, no trust anchor definition which does not include an=20
> issuer name can be used by our own existing algorithms.  I=20
> think that's a pretty good reason for PKIX to require the=20
> presence of a DN in this definition.
>=20
>                 Tom Gindin
>=20
> P.S. - These views are mine personally, and not necessarily=20
> those of my employer
>=20
>=20
>=20
>=20
> Julien Stern <[email-masked]>=20
> Sent by: [email-masked]
> 03/04/2009 01:43 PM
>=20
> To
>=20
> cc
> [email-masked]
> Subject
> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts=20
> directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509)=20
> Working Group of the IETF.
> >=20
> >=20
> >                Title           : Trust Anchor Format
> >                Author(s)       : R. Housley, et al.
> >                Filename        : draft-ietf-pkix-ta-format-01.txt
> >                Pages           : 17
> >                Date            : 2009-03-04
> >=20
>=20
> Hi again,
>=20
> separating from the previous email due to the nature of the comment:=20
> this one is more "philosophical" :)
>=20
> This draft defines a trust anchor as a public key with=20
> additional data.
>=20
> I believe that the most common usage of the word "trust=20
> anchor" denotes=20
> the _binding_ of a public key _and_ a name. A certificate=20
> binds a name=20
> and a public key (along with other information) thanks to a=20
> signature. A=20
> trust anchor binds them through direct trust.
>=20
> And indeed, the definition in X.509 is:
>=20
> trust anchor: A trust anchor is a set of the following information in=20
> addition to the public key: algorithm identifier, public key=20
> parameters=20
> (if applicable), distinguished name of the holder of the associated=20
> private key (i.e., the subject CA) and optionally a validity=20
> period. The=20
> trust anchor may be provided in the form of a self-signed certificate.
> A trust anchor is trusted by a certificate using system and used for=20
> validating certificates in certification paths.
>=20
>=20
> I assume that you did not choose to make the DN optional=20
> without reason.=20
> But is that really something that we would like to have? Are there=20
> really cases where we want to use a public key without explicitly=20
> knowing whom it belongs to? Isn't there a risk to spread confusion on=20
> what a "trust anchor" is?
>=20
> Granted, this RFC could define a Trust Anchor in a more global scope,=20
> without a need to bind it to a DN, but I'm (very personally) not sure=20
> this is a great idea and I believe that mandating the=20
> presence of a DN=20
> would not bring a strong limitation.
>=20
> Have you considered moving the taName from the=20
> CertPathControls to the=20
> main structure (TrustAnchorInfo) and keeping the CertPathControls=20
> structure for fine tuning of the X.509 input algorithm?
>=20
> (And along the same lines, why is the KeyIdentifier mandatory and not=20
> optional?)
>=20
> Regards,
>=20
> --
> Julien
>=20
>=20
>=20
>=20

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Wed, 4 Mar 2009 21:16:25 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "Tom Gindin" <[email-masked]>, "Julien Stern" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

May be two wrongs can make a right since if a name should be required in
a TA, it is the subject and not issuer name.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Tom Gindin
> Sent: Wednesday, March 04, 2009 8:41 PM
> To: Julien Stern
> Cc: [email-masked]
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
>=20
>         Julian:
>=20
>         I think you're wrong in believing that the name is=20
> central to the definition of a trust anchor.  I can have (and=20
> my browser may be shipped
> with) several trust anchors issued by the same organization,=20
> and the names which distinguish them are (to me as the =20
> manager of the trust store) quite arbitrary.  A typical=20
> example is that there are two separate CA certificates from=20
> Entrust with CN=3D"Entrust.net Secure Server Certification=20
> Authority".  Their OU's are slightly different, and one of=20
> them has a Country attribute.
>         While philosophically I completely disagree with you,=20
> RFC 5280 section 6.1.1 point d-1 requires that the trust=20
> anchor have an issuer name, as does the same section in 3280.=20
>  Thus, no trust anchor definition which does not include an=20
> issuer name can be used by our own existing algorithms.  I=20
> think that's a pretty good reason for PKIX to require the=20
> presence of a DN in this definition.
>=20
>                 Tom Gindin
>=20
> P.S. - These views are mine personally, and not necessarily=20
> those of my employer
>=20
>=20
>=20
>=20
> Julien Stern <[email-masked]>=20
> Sent by: [email-masked]
> 03/04/2009 01:43 PM
>=20
> To
>=20
> cc
> [email-masked]
> Subject
> Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts=20
> directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509)=20
> Working Group of the IETF.
> >=20
> >=20
> >                Title           : Trust Anchor Format
> >                Author(s)       : R. Housley, et al.
> >                Filename        : draft-ietf-pkix-ta-format-01.txt
> >                Pages           : 17
> >                Date            : 2009-03-04
> >=20
>=20
> Hi again,
>=20
> separating from the previous email due to the nature of the comment:=20
> this one is more "philosophical" :)
>=20
> This draft defines a trust anchor as a public key with=20
> additional data.
>=20
> I believe that the most common usage of the word "trust=20
> anchor" denotes=20
> the _binding_ of a public key _and_ a name. A certificate=20
> binds a name=20
> and a public key (along with other information) thanks to a=20
> signature. A=20
> trust anchor binds them through direct trust.
>=20
> And indeed, the definition in X.509 is:
>=20
> trust anchor: A trust anchor is a set of the following information in=20
> addition to the public key: algorithm identifier, public key=20
> parameters=20
> (if applicable), distinguished name of the holder of the associated=20
> private key (i.e., the subject CA) and optionally a validity=20
> period. The=20
> trust anchor may be provided in the form of a self-signed certificate.
> A trust anchor is trusted by a certificate using system and used for=20
> validating certificates in certification paths.
>=20
>=20
> I assume that you did not choose to make the DN optional=20
> without reason.=20
> But is that really something that we would like to have? Are there=20
> really cases where we want to use a public key without explicitly=20
> knowing whom it belongs to? Isn't there a risk to spread confusion on=20
> what a "trust anchor" is?
>=20
> Granted, this RFC could define a Trust Anchor in a more global scope,=20
> without a need to bind it to a DN, but I'm (very personally) not sure=20
> this is a great idea and I believe that mandating the=20
> presence of a DN=20
> would not bring a strong limitation.
>=20
> Have you considered moving the taName from the=20
> CertPathControls to the=20
> main structure (TrustAnchorInfo) and keeping the CertPathControls=20
> structure for fine tuning of the X.509 input algorithm?
>=20
> (And along the same lines, why is the KeyIdentifier mandatory and not=20
> optional?)
>=20
> Regards,
>=20
> --
> Julien
>=20
>=20
>=20
>=20

To: Julien Stern <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
From: Tom Gindin <[email-masked]>
Date: Wed, 4 Mar 2009 20:41:19 -0500
Sender: [email-masked]

        Julian:

        I think you're wrong in believing that the name is central to the 
definition of a trust anchor.  I can have (and my browser may be shipped 
with) several trust anchors issued by the same organization, and the names 
which distinguish them are (to me as the  manager of the trust store) 
quite arbitrary.  A typical example is that there are two separate CA 
certificates from Entrust with CN="Entrust.net Secure Server Certification 
Authority".  Their OU's are slightly different, and one of them has a 
Country attribute.
        While philosophically I completely disagree with you, RFC 5280 
section 6.1.1 point d-1 requires that the trust anchor have an issuer 
name, as does the same section in 3280.  Thus, no trust anchor definition 
which does not include an issuer name can be used by our own existing 
algorithms.  I think that's a pretty good reason for PKIX to require the 
presence of a DN in this definition.

                Tom Gindin

P.S. - These views are mine personally, and not necessarily those of my 
employer

Julien Stern <[email-masked]> 
Sent by: [email-masked]
03/04/2009 01:43 PM

To

cc
[email-masked]
Subject
Re: I-D Action:draft-ietf-pkix-ta-format-01.txt

[email-masked] wrote:
> 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           : Trust Anchor Format
>                Author(s)       : R. Housley, et al.
>                Filename        : draft-ietf-pkix-ta-format-01.txt
>                Pages           : 17
>                Date            : 2009-03-04
> 

Hi again,

separating from the previous email due to the nature of the comment: 
this one is more "philosophical" :)

This draft defines a trust anchor as a public key with additional data.

I believe that the most common usage of the word "trust anchor" denotes 
the _binding_ of a public key _and_ a name. A certificate binds a name 
and a public key (along with other information) thanks to a signature. A 
trust anchor binds them through direct trust.

And indeed, the definition in X.509 is:

trust anchor: A trust anchor is a set of the following information in 
addition to the public key: algorithm identifier, public key parameters 
(if applicable), distinguished name of the holder of the associated 
private key (i.e., the subject CA) and optionally a validity period. The 
trust anchor may be provided in the form of a self-signed certificate.
A trust anchor is trusted by a certificate using system and used for 
validating certificates in certification paths.

I assume that you did not choose to make the DN optional without reason. 
But is that really something that we would like to have? Are there 
really cases where we want to use a public key without explicitly 
knowing whom it belongs to? Isn't there a risk to spread confusion on 
what a "trust anchor" is?

Granted, this RFC could define a Trust Anchor in a more global scope, 
without a need to bind it to a DN, but I'm (very personally) not sure 
this is a great idea and I believe that mandating the presence of a DN 
would not bring a strong limitation.

Have you considered moving the taName from the CertPathControls to the 
main structure (TrustAnchorInfo) and keeping the CertPathControls 
structure for fine tuning of the X.509 input algorithm?

(And along the same lines, why is the KeyIdentifier mandatory and not 
optional?)

Regards,

--
Julien

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-authorityclearanceconstraints-01.txt 
Date: Wed,  4 Mar 2009 16:30:01 -0800 (PST)
Sender: [email-masked]

--NextPart

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

	Title		: Clearance Attribute and Authority Clearance Constraints 
Certificate Extension
	Author(s)	: S. Chokhani, S. Turner
	Filename	: draft-ietf-pkix-authorityclearanceconstraints-01.txt
	Pages		: 19
	Date		: 2009-3-4
	
This document defines the syntax and semantics for the Clearance 
   attribute and the Authority Clearance Constraints extension in X.509 
   certificates.  The Clearance attribute is used to indicate the 
   clearance held by the subject.  The Clearance attribute may appear in 
   the subject directory attributes extension of a public key 
   certificate or in the attributes field of an attribute certificate.  
   The Authority Clearance Constraints certificate extension values in a 
   Trust Anchor (TA), CA public key certificates, and an Attribute 
   Authority (AA) public key certificate in a public key certification 
   path constrain the effective Clearance of the subject.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-authorityclearanceconstraints-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-authorityclearanceconstraints-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Date: Wed, 04 Mar 2009 17:58:53 -0500
To: Julien Stern <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Cc: [email-masked]
Sender: [email-masked]

Julien:

X.509 did not originally include a definition of trust anchor.  RFC 
2459 follow this example, and it caused problems when describing 
certification path validation.  Since RFC 3280 added a lot of 
material on this topic, a definition was needed.  RFC 3280 includes:

    In section 6.1, the text describes basic path validation.  Valid
    paths begin with certificates issued by a trust anchor.  The
    algorithm requires the public key of the CA, the CA's name, and any
    constraints upon the set of paths which may be validated using this
    key.

I consider these constraints to be additional data.  The RFC 3280 
definition is saying what is needed in a trust anchor for the path 
validation algorithm.  Constraints are implemented through settings 
in the path validation algorithm.  However, I do not see anything in 
this text that says other policy information cannot be part of a 
trust anchor.  The text you quote includes validity period, and I 
consider this to be an example of such policy information.

RFC 2459, RFC 3280, and RFC 5280 have all required CA certificates to 
include a Distinguished Name.  This is important for constructing a 
certification path and for identifying a particular certificate in a CRL.

The taName is needed for certification path construction and 
validation.  I do not really care if it is placed in a separate 
OPTIONAL element of TrustAnchorInfo.  How would this change help you?

TAMP requires a key identifier.  This format was originally embedded 
in TAMP.  I guess this linkage remains.  I do point out that a key 
identifier could be computed from the public key using the technique 
described in RFC 5280, so this is not an onerous requirement.

Russ

At 01:43 PM 3/4/2009, Julien Stern wrote:

>[email-masked] wrote:
>>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           : Trust Anchor Format
>>         Author(s)       : R. Housley, et al.
>>         Filename        : draft-ietf-pkix-ta-format-01.txt
>>         Pages           : 17
>>         Date            : 2009-03-04
>
>Hi again,
>
>separating from the previous email due to the nature of the comment: 
>this one is more "philosophical" :)
>
>This draft defines a trust anchor as a public key with additional data.
>
>I believe that the most common usage of the word "trust anchor" 
>denotes the _binding_ of a public key _and_ a name. A certificate 
>binds a name and a public key (along with other information) thanks 
>to a signature. A trust anchor binds them through direct trust.
>
>And indeed, the definition in X.509 is:
>
>trust anchor: A trust anchor is a set of the following information 
>in addition to the public key: algorithm identifier, public key 
>parameters (if applicable), distinguished name of the holder of the 
>associated private key (i.e., the subject CA) and optionally a 
>validity period. The trust anchor may be provided in the form of a 
>self-signed certificate.
>A trust anchor is trusted by a certificate using system and used for 
>validating certificates in certification paths.
>
>
>I assume that you did not choose to make the DN optional without 
>reason. But is that really something that we would like to have? Are 
>there really cases where we want to use a public key without 
>explicitly knowing whom it belongs to? Isn't there a risk to spread 
>confusion on what a "trust anchor" is?
>
>Granted, this RFC could define a Trust Anchor in a more global 
>scope, without a need to bind it to a DN, but I'm (very personally) 
>not sure this is a great idea and I believe that mandating the 
>presence of a DN would not bring a strong limitation.
>
>Have you considered moving the taName from the CertPathControls to 
>the main structure (TrustAnchorInfo) and keeping the 
>CertPathControls structure for fine tuning of the X.509 input algorithm?
>
>(And along the same lines, why is the KeyIdentifier mandatory and 
>not optional?)
>
>Regards,
>
>--
>Julien
>

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-ocspagility-00.txt 
Date: Wed,  4 Mar 2009 14:30:02 -0800 (PST)
Sender: [email-masked]

--NextPart

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

	Title           : OCSP Algorithm Agility
	Author(s)       : P. Hallam-Baker
	Filename        : draft-ietf-pkix-ocspagility-00.txt
	Pages           : 7
	Date            : 2009-03-04

The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspagility-00.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-ocspagility-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-format-01.txt
Date: Wed, 4 Mar 2009 15:23:33 -0500
From: "Carl Wallace" <[email-masked]>
To: "Julien Stern" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

<snip>
> One first comment regarding the CertPolicyFlags:
>=20
> They are defined as:
>=20
> CertPolicyFlags ::=3D BIT STRING {
>        inhibitPolicyMapping   (0),
>        requireExplicitPolicy  (1),
>        inhibitAnyPolicy       (2) }
>=20
> But in 5280, they are integer, not booleans, for example:
>=20
> PolicyConstraints ::=3D SEQUENCE {
>       requireExplicitPolicy   [0]     SkipCerts OPTIONAL,
>       inhibitPolicyMapping    [1]     SkipCerts OPTIONAL }
>=20
> SkipCerts ::=3D INTEGER (0..MAX)
>=20
> I believe that we should keep them integers to keep the full=20
> generality (unless I missed a point).

The booleans align with the inputs to the path validation algorithm.
Ideally, those would have been integers too.
=20
> On a more global note, I noticed some time ago that a=20
> document from ETSI (namely ETSI 102 272) defined a fairly=20
> similar (albeit simpler) structure. It dates from 2003, but=20
> could provide some interesting bits.
> For those interested, here is the link:=20
> http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=3D19571
>=20
>=20
> For those interested, but lazy, here are the relevant "raw=20
> ASN.1" bits:
>=20
> CertificateTrustPoint ::=3D SEQUENCE {
>      trustpoint              Certificate,
>      pathLenConstraint   [0] PathLenConstraint   OPTIONAL,
>      acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, --=20
> If not present "any policy"
>      nameConstraints     [2] NameConstraints     OPTIONAL,
>      policyConstraints   [3] PolicyConstraints   OPTIONAL }
>=20
> PathLenConstraint ::=3D INTEGER (0..MAX)
> AcceptablePolicySet ::=3D SEQUENCE OF CertPolicyId CertPolicyId=20
> ::=3D OBJECT IDENTIFIER
>=20
> NameConstraints ::=3D SEQUENCE {
>            permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
>            excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }
> GeneralSubtrees ::=3D SEQUENCE SIZE (1..MAX) OF GeneralSubtree=20
> GeneralSubtree ::=3D SEQUENCE {
>            base                    GeneralName,
>            minimum         [0]     BaseDistance DEFAULT 0,
>            maximum         [1]     BaseDistance OPTIONAL }
> BaseDistance ::=3D INTEGER (0..MAX)
>=20
> PolicyConstraints ::=3D SEQUENCE {
>          requireExplicitPolicy    [0] SkipCerts OPTIONAL,
>          inhibitPolicyMapping     [1] SkipCerts OPTIONAL }
> SkipCerts ::=3D INTEGER (0..MAX)
>=20
>=20
>=20
> I like the fact that the certificate is optional in the TA=20
> draft, and that it can be defined as a pure DN/Public Key=20
> pair. I've always thought the direct inclusion of a=20
> self-signed certificate led to possible unclarities as=20
> regards treatment of extensions. But anyway, always=20
> interesting to compare with what exists ...

Thanks for the reference.   =20

Date: Wed, 04 Mar 2009 19:43:46 +0100
From: Julien Stern <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Sender: [email-masked]

[email-masked] wrote:
> 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           : Trust Anchor Format
> 	Author(s)       : R. Housley, et al.
> 	Filename        : draft-ietf-pkix-ta-format-01.txt
> 	Pages           : 17
> 	Date            : 2009-03-04
> 

Hi again,

separating from the previous email due to the nature of the comment: 
this one is more "philosophical" :)

This draft defines a trust anchor as a public key with additional data.

I believe that the most common usage of the word "trust anchor" denotes 
the _binding_ of a public key _and_ a name. A certificate binds a name 
and a public key (along with other information) thanks to a signature. A 
trust anchor binds them through direct trust.

And indeed, the definition in X.509 is:

trust anchor: A trust anchor is a set of the following information in 
addition to the public key: algorithm identifier, public key parameters 
(if applicable), distinguished name of the holder of the associated 
private key (i.e., the subject CA) and optionally a validity period. The 
trust anchor may be provided in the form of a self-signed certificate.
A trust anchor is trusted by a certificate using system and used for 
validating certificates in certification paths.

I assume that you did not choose to make the DN optional without reason. 
But is that really something that we would like to have? Are there 
really cases where we want to use a public key without explicitly 
knowing whom it belongs to? Isn't there a risk to spread confusion on 
what a "trust anchor" is?

Granted, this RFC could define a Trust Anchor in a more global scope, 
without a need to bind it to a DN, but I'm (very personally) not sure 
this is a great idea and I believe that mandating the presence of a DN 
would not bring a strong limitation.

Have you considered moving the taName from the CertPathControls to the 
main structure (TrustAnchorInfo) and keeping the CertPathControls 
structure for fine tuning of the X.509 input algorithm?

(And along the same lines, why is the KeyIdentifier mandatory and not 
optional?)

Regards,

--
Julien

Date: Wed, 04 Mar 2009 19:19:31 +0100
From: Julien Stern <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
Sender: [email-masked]

[email-masked] wrote:
> 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           : Trust Anchor Format
> 	Author(s)       : R. Housley, et al.
> 	Filename        : draft-ietf-pkix-ta-format-01.txt
> 	Pages           : 17
> 	Date            : 2009-03-04
> 

Hi,

Nice work. Thanks.

One first comment regarding the CertPolicyFlags:

They are defined as:

CertPolicyFlags ::= BIT STRING {
       inhibitPolicyMapping   (0),
       requireExplicitPolicy  (1),
       inhibitAnyPolicy       (2) }

But in 5280, they are integer, not booleans, for example:

PolicyConstraints ::= SEQUENCE {
      requireExplicitPolicy   [0]     SkipCerts OPTIONAL,
      inhibitPolicyMapping    [1]     SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

I believe that we should keep them integers to keep the full generality 
(unless I missed a point).

On a more global note, I noticed some time ago that a document from ETSI 
(namely ETSI 102 272) defined a fairly similar (albeit simpler) 
structure. It dates from 2003, but could provide some interesting bits.
For those interested, here is the link: 
http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=19571

For those interested, but lazy, here are the relevant "raw ASN.1" bits:

CertificateTrustPoint ::= SEQUENCE {
     trustpoint              Certificate,
     pathLenConstraint   [0] PathLenConstraint   OPTIONAL,
     acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, -- If not 
present "any policy"
     nameConstraints     [2] NameConstraints     OPTIONAL,
     policyConstraints   [3] PolicyConstraints   OPTIONAL }

PathLenConstraint ::= INTEGER (0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER

NameConstraints ::= SEQUENCE {
           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
           base                    GeneralName,
           minimum         [0]     BaseDistance DEFAULT 0,
           maximum         [1]     BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)

PolicyConstraints ::= SEQUENCE {
         requireExplicitPolicy    [0] SkipCerts OPTIONAL,
         inhibitPolicyMapping     [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)

I like the fact that the certificate is optional in the TA draft, and 
that it can be defined as a pure DN/Public Key pair. I've always thought 
the direct inclusion of a self-signed certificate led to possible 
unclarities as regards treatment of extensions. But anyway, always 
interesting to compare with what exists ...

Regards,

--
Julien

Date: Wed, 04 Mar 2009 18:22:25 +0100
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: draft-ietf-pkix-rfc3161bis-01.txt
Sender: [email-masked]

I had the impression that thegoal of that texwt was an update
concerning hash algorithms.

One could expecte it would only contain an update to the ESScertid using
ESSCertidV2 etc.

The actual texts corresponds roughly to an expired draft some
years ago.

        - the document has been aligned with RFC 3628 to make the
          difference between a time-stamping unit (TSU) and a TSA.

Thus, the text is not a small update of 3161 but introduces several
new items, some of them seems questionable to me. Some problems
which had been mentioned with RFC 3161 in the past, have not been
addressed.

In 3161, a TSA is merely a technical service similar to what is
said in 3161bis for a TSU. A TSA in 3161bis does not really
have a defined technical role.

On the other hand the field tsa in a response refers to a TSA,
and to a certficate that validates it. But a TSA does no longer
have a certificate, only TSUs.

As a consequence, the following paragraph cannot mention TSA
but at best a TSU.
Besides that it should also mentiion ESSCertIDv2.)

    The purpose of the tsa field is to give a hint in identifying the
    name of the TSA.  If present, it MUST correspond to one of the
    subject names included in the certificate that is to be used to
    verify the token.  However, the actual identification of the entity
    that signed the response will always occur through the use of the
    certificate identifier (ESSCertID Attribute) inside a
    SigningCertificate attribute which is part of the signerInfo
    (See Section 5 of [ESS]).

Chapter 3.3 does not use the 2119 terminology in the first phrase but
rather the ISO terminoilogy. 3.3 is not relevant for the function of
a time stamp service. (Although it is likely that TSA actually
have filled all the REQUIRED 'shall) attributes in the DN)

The following text is extremely fuzzy:

    The name of the issuing TSU shall contain an appropriate subset of
    the following attributes (defined in ISO 9594-6 [ISO9594-6] and
    ITU-T Recommendation X.520 [X.520]):

        - countryName;
        - stateOrProvinceName;
        - organizationName;
        - commonName.

What means "appropriate subset". The text does not exclude
other attributs. So in fact, it says: The TSU MUST have a subjectDN?

It is not defined what name identifies a TSA? for example, everything except
the common name?

4.3 :

As it had been mentioned before the socket protocol as it is defined
has some problems: Since it was taken texto from CMP, there are some features
that are may require some complexity in clients:
Only 00, 05, and 06 seem useful to me. If a TSA/U is not able to sign
a response within a few milliseconds with a TCP connection kept open,
I wouldn't call this a service.
For HTTP, a server cannot return a poll indication as a comparison.

If a client does not send a pollReq, what will happen with a pending
response?

The protocol does not specify who terminates the connection. Is it the
server that closes after one exchange?

If multiple requests and responses can be exchanged over the same connection,
what is the dialogue model? request/response, pipelining, etc?

What is a TSU message? I think it should be TSP message. Old text was
TSA, which was also somewhat wrong.

Security section point 1 seems not quite correct:

Instead of :
it SHALL be set either to unspecified (0), affiliationChanged (3),
       superseded (4) or cessationOfOperation (5).  In that case,

it should say

In the case when the reasonCode is set to either
       affiliationChanged (3),
       superseded (4) or cessationOfOperation (5)

Unspecified means that ther can be a key compromise IMO?

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-ta-format-01.txt 
Date: Wed,  4 Mar 2009 08:15:02 -0800 (PST)
Sender: [email-masked]

--NextPart

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

	Title           : Trust Anchor Format
	Author(s)       : R. Housley, et al.
	Filename        : draft-ietf-pkix-ta-format-01.txt
	Pages           : 17
	Date            : 2009-03-04

This document describes a structure for representing trust anchor
information.  A trust anchor is an authoritative entity represented
by a public key and associated data.  The public key is used to
verify digital signatures and the associated data is used to
constrain the types of information or actions for which the trust
anchor is authoritative.  The structures defined in this document are
intended to satisfy the format-related requirements defined in Trust
Anchor Management Requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-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-ta-format-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-ta-mgmt-reqs-03.txt 
Date: Wed,  4 Mar 2009 08:15:02 -0800 (PST)
Sender: [email-masked]

--NextPart

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

	Title           : Trust Anchor Management Requirements
	Author(s)       : R. Reddy, C. Wallace
	Filename        : draft-ietf-pkix-ta-mgmt-reqs-03.txt
	Pages           : 19
	Date            : 2009-03-04

A trust anchor represents an authoritative entity via a public key
and associated data.  The public key is used to verify digital
signatures and the associated data is used to constrain the types of
information for which the trust anchor is authoritative.  A relying
party uses trust anchors to determine if a digitally signed object is
valid by verifying a digital signature using the trust anchor's
public key, and by enforcing the constraints expressed in the
associated data for the trust anchor.  This document describes some
of the problems associated with the lack of a standard trust anchor
management mechanism and defines requirements for data formats and
push-based protocols designed to address these problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-reqs-03.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-ta-mgmt-reqs-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-tamp-01.txt 
Date: Wed,  4 Mar 2009 08:15:02 -0800 (PST)
Sender: [email-masked]

--NextPart

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

	Title           : Trust Anchor Management Protocol (TAMP)
	Author(s)       : R. Housley, et al.
	Filename        : draft-ietf-pkix-tamp-01.txt
	Pages           : 84
	Date            : 2009-03-04

This document describes a transport independent protocol for the
management of trust anchors and community identifiers stored in a
trust anchor store.  The protocol makes use of the Cryptographic
Message Syntax (CMS), and a digital signature is used to provide
integrity protection and data origin authentication.  The protocol
can be used to manage trust anchor stores containing trust anchors
represented as Certificate, TBSCertificate or TrustAnchorInfo
objects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-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-tamp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Date: Tue, 03 Mar 2009 12:29:14 +0100
Subject: Call for agenda items
From: Stefan Santesson <[email-masked]>
To: IETF-pkix <[email-masked]>
Sender: [email-masked]

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

--B_3318928155_3051272
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: quoted-printable

IETF=20in=20San=20Francisco=20is=20coming=20up.

PKIX=20has=20a=202.5=20hour=20session=20directly=20on=20the=20Monday=20mor=
ning=20March=2023=20at=200900

Please=20let=20me=20know=20if=20you=20have=20anything=20you=20whish=20to=20=
present=20at=20the=20meeting.
At=20least=20one=20representative=20of=20each=20active=20WG=20document=20M=
UST=20inform=20me=20if=20you
need=20a=20time=20slot=20for=20that=20document=20or=20not.
=20
I=20would=20like=20to=20have=20your=20request=20for=20timeslot=20by=20Wedn=
esday=20March=2011.
After=20that=20we=20can=20always=20do=20late=20adjustments=20but=20I=20app=
reciate=20to=20have=20your
request=20as=20early=20as=20possible.

Thank=20you.

/Stefan

This=20email=20was=20received=20from=20the=20INTERNET=20and=20scanned=20by=
=20the=20Government=20Secure=20Intranet=20anti-virus=20service=20supplied=20=
by=20Cable&Wireless=20in=20partnership=20with=20MessageLabs.=20(CCTM=20Cer=
tificate=20Number=202007/11/0032.)=20In=20case=20of=20problems,=20please=20=
call=20your=20organisation=92s=20IT=20Helpdesk.=20
Communications=20via=20the=20GSi=20may=20be=20automatically=20logged,=20mo=
nitored=20and/or=20recorded=20for=20legal=20purposes.

**************************************************************************=
**
Communications=20with=20GCHQ=20may=20be=20monitored=20and/or=20recorded=20=

for=20system=20efficiency=20and=20other=20lawful=20purposes.=20Any=20views=
=20or=20
opinions=20expressed=20in=20this=20e-mail=20do=20not=20necessarily=20refle=
ct=20GCHQ=20
policy.=20=20This=20email,=20and=20any=20attachments,=20is=20intended=20fo=
r=20the=20
attention=20of=20the=20addressee(s)=20only.=20Its=20unauthorised=20use,=20=

disclosure,=20storage=20or=20copying=20is=20not=20permitted.=20=20If=20you=
=20are=20not=20the
intended=20recipient,=20please=20notify=[email-masked].=20=20=

This=20information=20is=20exempt=20from=20disclosure=20under=20the=20Freed=
om=20of=20
Information=20Act=202000=20and=20may=20be=20subject=20to=20exemption=20und=
er
other=20UK=20information=20legislation.=20Refer=20disclosure=20requests=20=
to=20
GCHQ=20on=2001242=20221491=20ext=2030306=20(non-secure)=20or=20email
[email-masked]

**************************************************************************=
**

______________________________________________________________________
This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec=
urity=20System.
For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema=
il=20
______________________________________________________________________
--B_3318928155_3051272
Content-type: text/html; charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Call=20for=20agenda=20items</TITLE>
</HEAD>
<BODY>
<FONT=20FACE=3D"Calibri,=20Verdana,=20Helvetica,=20Arial"><SPAN=20STYLE=3D=
'font-size:11pt'>IETF=20in=20San=20Francisco=20is=20coming=20up.<BR>
<BR>
PKIX=20has=20a=202.5=20hour=20session=20directly=20on=20the=20Monday=20mor=
ning=20March=2023=20at=200900<BR>
<BR>
Please=20let=20me=20know=20if=20you=20have=20anything=20you=20whish=20to=20=
present=20at=20the=20meeting.<BR>
<B><U>At=20least=20one=20representative=20of=20each=20active=20WG=20docume=
nt=20MUST=20inform=20me=20if=20you=20need=20a=20time=20slot=20for=20that=20=
document=20or=20not.<BR>
</U></B>=20<BR>
I=20would=20like=20to=20have=20your=20request=20for=20timeslot=20by=20Wedn=
esday=20March=2011.<BR>
After=20that=20we=20can=20always=20do=20late=20adjustments=20but=20I=20app=
reciate=20to=20have=20your=20request=20as=20early=20as=20possible.<BR>
<BR>
Thank=20you.<BR>
<BR>
/Stefan</SPAN></FONT>

<BR>
This=20email=20was=20received=20from=20the=20INTERNET=20and=20scanned=20by=
=20the=20Government=20Secure=20Intranet=20anti-virus=20service=20supplied=20=
by=20Cable&Wireless=20in=20partnership=20with=20MessageLabs.=20(CCTM=20Cer=
tificate=20Number=202007/11/0032.)=20In=20case=20of=20problems,=20please=20=
call=20your=20organisation=92s=20IT=20Helpdesk.=20<BR>
Communications=20via=20the=20GSi=20may=20be=20automatically=20logged,=20mo=
nitored=20and/or=20recorded=20for=20legal=20purposes.<BR>
<CODE><FONT=20SIZE=3D3><BR>
<BR>
**************************************************************************=
**<BR>
Communications=20with=20GCHQ=20may=20be=20monitored=20and/or=20recorded=20=
<BR>
for=20system=20efficiency=20and=20other=20lawful=20purposes.=20Any=20views=
=20or=20<BR>
opinions=20expressed=20in=20this=20e-mail=20do=20not=20necessarily=20refle=
ct=20GCHQ=20<BR>
policy.=20=20This=20email,=20and=20any=20attachments,=20is=20intended=20fo=
r=20the=20<BR>
attention=20of=20the=20addressee(s)=20only.=20Its=20unauthorised=20use,=20=
<BR>
disclosure,=20storage=20or=20copying=20is=20not=20permitted.=20=20If=20you=
=20are=20not=20the<BR>
intended=20recipient,=20please=20notify=[email-masked].=20=20=
<BR>
<BR>
This=20information=20is=20exempt=20from=20disclosure=20under=20the=20Freed=
om=20of=20<BR>
Information=20Act=202000=20and=20may=20be=20subject=20to=20exemption=20und=
er<BR>
other=20UK=20information=20legislation.=20Refer=20disclosure=20requests=20=
to=20<BR>
GCHQ=20on=2001242=20221491=20ext=2030306=20(non-secure)=20or=20email<BR>
[email-masked]<BR>
<BR>
**************************************************************************=
**<BR>
</FONT></CODE>

<BR>
______________________________________________________________________<BR>=

This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec=
urity=20System.<BR>
For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema=
il=20<BR>
______________________________________________________________________<BR>=

</BODY>
</HTML>

--B_3318928155_3051272--

Date: Tue, 03 Mar 2009 12:29:14 +0100
Subject: Call for agenda items
From: Stefan Santesson <[email-masked]>
To: IETF-pkix <[email-masked]>
Sender: [email-masked]

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

--B_3318928155_3051272
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

IETF in San Francisco is coming up.

PKIX has a 2.5 hour session directly on the Monday morning March 23 at 0900

Please let me know if you have anything you whish to present at the meeting.
At least one representative of each active WG document MUST inform me if you
need a time slot for that document or not.
 
I would like to have your request for timeslot by Wednesday March 11.
After that we can always do late adjustments but I appreciate to have your
request as early as possible.

Thank you.

/Stefan

--B_3318928155_3051272
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Call for agenda items</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>IETF in San Francisco is coming up.<BR>
<BR>
PKIX has a 2.5 hour session directly on the Monday morning March 23 at 0900=
<BR>
<BR>
Please let me know if you have anything you whish to present at the meeting=
.<BR>
<B><U>At least one representative of each active WG document MUST inform me=
 if you need a time slot for that document or not.<BR>
</U></B> <BR>
I would like to have your request for timeslot by Wednesday March 11.<BR>
After that we can always do late adjustments but I appreciate to have your =
request as early as possible.<BR>
<BR>
Thank you.<BR>
<BR>
/Stefan</SPAN></FONT>
</BODY>
</HTML>

--B_3318928155_3051272--