Subject: RE: Absent keyUsage in certificates

From: "David Cross" <[email-masked]>
Date: Mon, 30 May 2005 22:57:58 -0700

I agree for CA certificates, the Key Usage extension MUST be asserted.
However, in client (end entity) certificates, this is extremely
disadvantageous as it makes deployments and future application
consumption difficult.  In fact, many many companies and oragnizations
have demanded the acceptance and usage by applications EE certs with
this extension absent to indicate all purposes. 

David B. Cross 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sam Roberts
Sent: Monday, May 30, 2005 7:25 AM
To: [email-masked]
Subject: Re: Absent keyUsage in certificates

Wrote Peter Gutmann <[email-masked]>, on Mon, May 30, 2005 at
09:04:15PM +1200:
> If anyone from Verisign-called-Thawte is reading this, could you 
> please fix your certs to include the keyUsage extension?  They're 
> currently being issued without any keyUsage indication (or at least 
> some of them are), which is causing some debate about how to apply 
> them (the contact details I have for someone at Verisign seem to be
out of date).
> 
> Also, could the current wording around keyUsage in bride-of-3280 be 
> improved to indicate what the correct usage is if the extension is 
> absent?  Squinting at the text sideways, it currently says that the 
> key can be used for anything
> *except* cert and CRL verification, a rather strange 
> allow-some/deny-some interpretation when it's more normal to have a 
> default of either allow-all or deny-all (fail-open/fail-closed) in the

> absence of any further instructions,

I agree that allow-all or deny-all is sensible, and special-casing two
of the bits would be weird, but isn't allow-all what is specified now?

This interpretation is based on the validation rules, section 6.1.4,
rule (n):

  If a key usage extension is present, verify that the keyCertSign bit
  is set.

I can't see anything that says that absence of Key Usage should trigger
chain validation failure.  Its a long RFC, an you point to the text you
are "squinting sideways" at?

> but this is quite hard to see for anyone who doesn't already know in 
> advance how keyUsage works.  The sentence "Conforming CAs MUST include

> this extension in certificates that contain public keys that are used 
> to validate digital signatures on other public key certificates or
CRLs" is particularly obtuse.
> 
> I would suggest adding either:
> 
>   Conforming CAs MUST include this extension in all certificates.

Why MUST an end-entity cert include a Key Usage, not including it is a
good way of specifying allow-all. You want to forbid allow-all?

Cheers,
Sam

--
http://www.certicom.com

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 31 May 2005 20:56:51 +1200

"David Cross" <[email-masked]> writes:

>disadvantageous as it makes deployments and future application consumption
>difficult.

In what way?  Why can't you just set all the flags that make sense (e.g. all
encryption and signing flags for an RSA key)?  At the moment the few certs
I've seen with keyUsage absent seem to be more an indication of CA error than
an intent to allow them to be used for any purpose (e.g. ones that have no
X.509 keyUsage but do have a Netscape keyUsage that doesn't match an all-
purpose usage, or ones where the CA, when questioned, admitted that that
wasn't at all what they'd intended).  Making keyUsage mandatory everywhere
would make the CA's intent explicit.

>In fact, many many companies and oragnizations have demanded the acceptance
>and usage by applications EE certs with this extension absent to indicate all
>purposes.

All purposes except cert/CRL signing, you mean.  Or do they really want to
use them for all purposes, including cert/CRL signing/verification?

Peter.

---

From: Sam Roberts <[email-masked]>
Date: Tue, 31 May 2005 09:44:33 -0400

> use them for all purposes, including cert/CRL signing/verification?

cert signing requires a BasicConstraints, so its disallowed for other
reasons even if the KeyUsage is absent.

I don't see the problem you would like to fix. Are you saying that its
easier for a CA to mistakenly not include a KeyUsage than it is to
mistakenly include a KeyUsage with all bits set?

Since I regularly see certs that don't obey PKIX MUST encoding rules,
and we have to be able to "work" with them anyhow, other than allowing
us to gripe about certs we see that are wrong, I don't see how this
change will help or hinder implementors.

So, I'll bow out of the discussion.

Cheers,
Sam

-- 
http://www.certicom.com

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 31 May 2005 20:56:51 +1200

Peter.

Content-class: urn:content-classes:message
Subject: RE: Absent keyUsage in certificates
Date: Tue, 31 May 2005 16:31:08 -0700
From: "David Cross" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Sorry for delayed reply, I am travelling.  Yes, you are correct, they
don't want to use EE certs for CRL or cetr signing which also require
basic constraints to be set.  But many companies don't want to
anticipate the purpose when they issue a 5 year smartcard, etc. 

David B. Cross 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Gutmann
Sent: Tuesday, May 31, 2005 1:57 AM
To: David Cross; [email-masked]; [email-masked]
Subject: RE: Absent keyUsage in certificates

"David Cross" <[email-masked]> writes:

>consumption difficult.

In what way?  Why can't you just set all the flags that make sense (e.g.
all encryption and signing flags for an RSA key)?  At the moment the few
certs I've seen with keyUsage absent seem to be more an indication of CA
error than an intent to allow them to be used for any purpose (e.g. ones
that have no
X.509 keyUsage but do have a Netscape keyUsage that doesn't match an
all- purpose usage, or ones where the CA, when questioned, admitted that
that wasn't at all what they'd intended).  Making keyUsage mandatory
everywhere would make the CA's intent explicit.

>In fact, many many companies and oragnizations have demanded the 
>acceptance and usage by applications EE certs with this extension 
>absent to indicate all purposes.

All purposes except cert/CRL signing, you mean.  Or do they really want
to use them for all purposes, including cert/CRL signing/verification?

Peter.

Date: Tue, 31 May 2005 18:13:42 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: WG Last Call is closed: AIA CRL extension
Cc: Denis Pinkas <[email-masked]>, Stefan Santesson <[email-masked]>, Russ Housley <[email-masked]>, [email-masked]
Sender: [email-masked]

Folks,

The WG has achieved rough consensus on the AIA CRL extension ID.  The 
editors will be submitting a new ID incorporating the changes agreed to on 
list.  When that ID appears, I will forward it to the appropriate Area 
Director for progression.

Thanks,

Tim Polk

At 04:36 PM 5/25/2005 +0200, Denis Pinkas wrote:

>Stefan and Russ,
>
>>Denis,
>
>>I discussed this with Russ and our conclusion is that if this resolves
>>your last call issues, then we can live with deleting these sentences.
>
>If so, my concern is solved.
>
>Thanks,
>
>Denis
>
>PS: Stefan, we do not need to meet anymore next week on this topic,
>     and we can spend more time to enjoy some good food on the
>     French Riviera.  :-)
>
>>Stefan Santesson
>>Program Manager, Standards Liaison
>>Windows Security
>>
>>
>>>On Behalf Of Denis Pinkas
>>>Sent: den 25 maj 2005 00:47
>>>To: Russ Housley
>>>Cc: [email-masked]
>>>Subject: Re: WG Last Call: AIA CRL extension
>>>
>>>
>>>Russ,
>>>
>>>Two points:
>>>
>>>1. The current text in the security considerations section contains
>>>    text which suggest a solution to the problem but which is not.
>>>    At least the two following sentences SHALL be deleted:
>>>
>>>    " As means of reducing problems and security issues related to
>>issuer
>>
>>>    name collisions, CA names SHOULD be formed in a way that reduce
>>the
>>
>>>    likelihood of name collisions.  Implementations validating CRLs
>>>    MUST ensure that the certification path of the target certificate
>>>    and the CRL issuer certification path used to validate the target
>>>    certificate, terminate at the same trust anchor".
>>>
>>>2. We strongly agree that 3280bis MUST address this issue and
>>currently
>>
>>>    it does not do it correctly (otherwise we would not have this
>>>    loooong discussion), ... that we can continue within the scope
>>>    of 3280bis.
>>>
>>>Denis
>>>
>>>
>>>>Julien & Tom:
>>>>
>>>>Two points:
>>>>
>>>>1.  I understand this scenario.  The change that you advocate as a
>>>>countermeasure will prevent Indirect CRLs from working in scenarios
>>that
>>
>>>>are intended.
>>>>
>>>>2.  This observation has noting to do with the CRL AIA extension.
>>The
>>
>>>>attacker is inserting the bogus revocation information into the
>>>>repository.  Any relying party that uses that repository (when using
>>the
>>
>>>>CRL AIA extension or any other configuration information to locate
>>it)
>>
>>>>will get the bogus revocation information.
>>>>
>>>>If this is a concern, then it needs to be addressed in RFC3280bis,
>>not
>>
>>>>here.
>>>>
>>>>Russ
>>>>
>>>>At 12:38 PM 5/24/2005, Julien Stern wrote:
>>>>
>>>>
>>>>>On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
>>>>>
>>>>>>        There is one scenario permitted by the "same trust
>>anchor"
>>
>>>rule
>>>
>>>>>>for CRL signers which seems to me to be a serious security hole.
>>>>>
>>>>>Let us
>>>>>
>>>>>>assume a valid CA which is a direct subordinate of one of the
>>RP's
>>
>>>>>trust
>>>>>
>>>>>>anchors.  This CA issues separate CRL's and ARL's, in a quite
>>usual
>>
>>>>>way,
>>>>>
>>>>>>and issues cross certificates.  After months or years of
>>operation,
>>
>>>it
>>>
>>>>>>revokes one of its cross certificates because the subject's
>>operator
>>
>>>>>has
>>>>>
>>>>>>gone rogue.  That rogue subject then issues a fraudulent CRL
>>Signing
>>
>>>>>>certificate with the DN that the superior certificate has been
>>using
>>
>>>to
>>>
>>>>>>sign ARL's, a public key which it has newly generated, and
>>various
>>
>>>>>>extensions including an SKID.  It then issues an updated copy of
>>an
>>
>>>old
>>>
>>>>>>ARL under the fraudulent CRL signer's certificate and with an
>>AKID
>>
>>>>>>matching the fraudulent signer's SKID.  If the rogue can break
>>into
>>
>>>the
>>>
>>>>>>repository where the CRL is expected, this fraudulently issued
>>CRL
>>
>>>will
>>>
>>>>>>probably be validated whether it contains an AIA or not.  It will
>>>>>>certainly pass the "same trust anchor" condition.
>>>>>>        This scenario, in which a rogue CA issues an ARL
>>certifiying
>>
>>>>>that
>>>>>
>>>>>>its primary certificate has not been revoked and gets the ARL
>>>>>
>>>>>accepted, is
>>>>>
>>>>>>possible under "same trust anchor" but not under "signed by path
>>>>>
>>>>>member".
>>>>>
>>>>>I agree with the validity of this scenario. I believe this is very
>>>>>close to the issue I attempted to bring on the list a short time
>>ago.
>>
>>>>>Of course, it assumes the existence of a rogue CA at some point in
>>>time.
>>>
>>>>>Note that the CRL could be directly inserted into a "long term"
>>>>>signature (according to RFC3126 for example). This does not require
>>>>>a repository break-in and makes the "attack" even more realistic.
>>>>>
>>>>>Regards.
>>>>>
>>>>>--
>>>>>Julien Stern
>>>>>
>>>>>
>>>>>>                Tom Gindin
>>>>>>
>>>>>>----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
>>-----
>>
>>>>>>
>>>>>>Tom Gindin
>>>>>>05/23/2005 10:46 PM
>>>>>>
>>>>>>        To:     [email-masked]
>>>>>>        cc:     [email-masked], [email-masked],
>>>[email-masked],
>>>
>>>>>>[email-masked]
>>>>>>        From:   Tom Gindin/Watson/IBM@IBMUS
>>>>>>        Subject:        Re: WG Last Call: AIA CRL extension
>>>>>>
>>>>>>        Tim:
>>>>>>
>>>>>>        I should probably have brought this up earlier, but are
>>we
>>
>>>>>certain
>>>>>
>>>>>>that "same trust anchor" is a strong enough check that the CRL
>>>>>
>>>>>signer is
>>>>>
>>>>>>the one expected by the issuing CA?  While I was not in San Diego
>>>when
>>>
>>>>>>this wording was included in the 3280 series, I do not really
>>think
>>
>>>>>that
>>>>>
>>>>>>that check is strong enough.  I would suggest instead that the
>>CRL
>>
>>>>>>signer's certificate needs to be directly issued by one of the
>>CA's
>>
>>>>>in the
>>>>>
>>>>>>certification path back to the trust anchor used for the
>>>certificate's
>>>
>>>>>>verification, or by that anchor itself, unless people have
>>practical
>>
>>>>>>experience with CA structures which that rule would prohibit.
>>>>>
>>>>>Forcing the
>>>>>
>>>>>>CRL to be issued by the CA itself (as I understand Denis to have
>>>>>>suggested) prohibits the reasonable case where the CRL is issued
>>by a
>>
>>>>>>hierarchical superior, so it is IMHO too strict.
>>>>>>        I am personally not sure, FWIW, that a CRL should be
>>>>>
>>>>>permitted to
>>>>>
>>>>>>be signed by a second-cousin certificate of the issuer's
>>>>>
>>>>>certificate.  By
>>>>>
>>>>>>analogy to the use of the terms in families, "sibling"
>>certificates
>>
>>>>>would
>>>>>
>>>>>>have the same issuer, "first-cousin" certificates would be issued
>>by
>>
>>>>>>siblings, and "second-cousin" certificates would be issued by
>>first
>>
>>>>>>cousins - so they are both three levels down from the same trust
>>>>>
>>>>>anchor,
>>>>>
>>>>>>or from the last common CA in their paths.  This issue is not
>>newly
>>
>>>>>caused
>>>>>
>>>>>>by CRL AIA, since the same issue can arise with CRL's containing
>>only
>>
>>>>>>AKID.  AIA only allows RP's to build a path (whether right or
>>wrong)
>>
>>>>>more
>>>>>
>>>>>>quickly.
>>>>>>        In any case, nothing more than a note in Security
>>>>>
>>>>>Considerations
>>>>>
>>>>>>is appropriate in any of our RFC's other than 3280 and its
>>successor.
>>
>>>>>>        Tom Gindin
>>>>>>P.S. -  The above views are mine, and not necessarily those of my
>>>>>
>>>>>employer
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Tim Polk <[email-masked]>
>>>>>>Sent by: [email-masked]
>>>>>>05/10/2005 05:27 PM
>>>>>>
>>>>>>        To:     [email-masked]
>>>>>>        cc:     [email-masked], [email-masked],
>>>>>
>>>>>[email-masked]
>>>>>
>>>>>>        Subject:        WG Last Call: AIA CRL extension
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>This message initiates working group Last Call for the
>>specification
>>
>>>>>>"Internet X.509 Public Key Infrastructure: Authority Information
>>>Access
>>>
>>>>>>CRL
>>>>>>Extension".  While some issues raised in the working group are
>>>>>
>>>>>unresolved,
>>>>>
>>>>>>the editors believe that rough consensus supports the current
>>>>>>specification.
>>>>>>
>>>>>>The URL for this Internet-Draft is:
>>>>>>
>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
>>>>>>
>>>>>>Last Call will run for (at least) two weeks. That is, Last Call
>>will
>>
>>>>>not
>>>>>
>>>>>>close before May 24.
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>Tim Polk
>>>>>>
>>>>
>

Date: Tue, 31 May 2005 10:30:37 -0400
From: Steve Hanna <[email-masked]>
To: "David A. Cooper" <[email-masked]>
CC: Peter Gutmann <[email-masked]>, pkix <[email-masked]>
Subject: Re: Absent keyUsage in certificates
Sender: [email-masked]

This is a good example of Jon Postel's advice:

Be liberal in what you accept, and conservative in what you send.

CAs should set keyUsage but relying parties
should not require it to be set (unless
explicitly configured to do so).

Of course, there must be limits to an RP's
"liberalism". An RP should not accept a purported
CA certificate that contains a keyUsage extension
that doesn't have the keyCertSign bit set.

Thanks,

Steve

David A. Cooper wrote:
> 
> Peter,
> 
> This seems to be an issue that has caused confusion for several people, 
> as Sam Roberts pointed out to me in another forum 
> (http://cio.nist.gov/esd/emaildir/lists/pkits/msg00108.html).
> 
> When the keyUsage extension is absent, then the key can be used for any 
> purpose (except as restricted by the basicConstraints, extendedKeyUsage, 
> certificatePolicies, etc. extensions as Stefan mentioned).
> 
> The text that you quoted was intentionally written as "Conforming CAs 
> MUST ..." because it is a requirement that ONLY applies to CAs.  So, 
> section 4 and 6 are not contradictory.  The text from section 4 that you 
> quoted imposes a requirement on CAs, but does not apply to relying 
> parties.  The text that Sam quoted from section 6 is part of the path 
> validation algorithm, which is used by relying parties but not CAs.
> 
> The basic idea is that while the PKIX Certificate and CRL profile (RFC 
> 3280, 3280bis) imposes stricter certificate and CRL generation 
> requirements than X.509 does, there is no requirement to reject a 
> certification path that is valid under X.509 simply because it was not 
> issued in conformance with the PKIX profile.  While it would be nice if 
> every CA followed the PKIX profile of X.509, I don't think PKIX should 
> mandate that certificates be rejected simply because they were issued in 
> accordance with a profile of X.509 that does not conform to the PKIX 
> profile.  This is the reason that the path validation algorithm in RFC 
> 3280 and 3280bis was designed to accept any certification path that is 
> valid under X.509 and it does not include checks to verify that 
> certificates were issued in conformance to the PKIX profile.  So, even 
> if PKIX required all certificates to include a keyUsage extension, this 
> could only be a requirement for conforming CAs, not relying parties.
> 
> Sam suggested that I add text to section 6 of 3280bis clearly stating 
> that the PKIX path validation algorithm is designed to accept any 
> certification path that is valid under X.509, not just those that were 
> issued in conformance with the PKIX profile.  He made the suggestion a 
> few days after the -00 draft was originally submitted, but I intend to 
> include this text in the -01 draft.
> 
> As to your question about whether section 4 takes precedence over 
> section 6 or vice versa, I don't think there is a real answer.  In 
> general, section 6 provides the definitive explanation of how to perform 
> certification path validation.  However, section 6 does not repeat all 
> of the details from section 4.  For example, section 6.1.3 steps (b) and 
> (c) and section 6.1.4 step (g) discuss the processing of name 
> constraints, but one must read section 4.2.1.10 to understand the rules 
> for applying name constraints to each name form.  On the other hand, 
> while section 4.2.1.11 provides a good textual description of the 
> policyConstraints extension, this section does not provide enough detail 
> to implement the path validation algorithm.  So, if you want a general 
> understanding of the extension, read section 4.  If you want to 
> implement the code to process the extension, read section 6.
> 
> BTW, if there are places where section 6 contradicts section 4, please 
> point them out so that they can be fixed.  But remember that the 
> algorithm in section 6 was not intended to verify that CAs issued 
> certificates and CRLs in conformance with section 4.  So, if there is a 
> requirement in section 4 of the form "conforming CAs MUST ...", there 
> may not be a corresponding requirement imposed in relying parties.
> 
> Dave
> 
> Peter Gutmann wrote:
> 
>> Sam Roberts <[email-masked]> writes:
>>
>>> agree that allow-all or deny-all is sensible, and special-casing two 
>>> of the
>>> bits would be weird, but isn't allow-all what is specified now?
>>
>>
>> Nope. See below.
>>
>>> rule
>>> (n):
>> Oh, section 6 contradicts section 4 in a number of places, I take 
>> section 4 as
>> definitive since it specifies the intent of the spec whereas section 6 
>> only
>> contains an attempt at implementing that intent.
>>
>> (Another proposed improvement for bride-of-3280, indicate which of 
>> section 4
>> or 6 is definitive in the case of conflict).
>>
>>> I can't see anything that says that absence of Key Usage should 
>>> trigger chain
>>> validation failure.
>>
>>
>> The exact text I quoted earlier, i.e:
>>
>> Conforming CAs MUST include this extension in certificates that contain
>> public keys that are used to validate digital signatures on other 
>> public key
>> certificates or CRLs.
>>
>>> Its a long RFC, an you point to the text you are "squinting sideways" 
>>> at?
>>
>>
>> The keyUsage text, which covers the use of keyUsage in a very obtuse way.
>> What the above is trying to say in a very roundabout way is:
>>
>> CA certificates must include a keyUsage extension with keyCertSign or
>> crlSign bits set as appropriate.
>>
>>> Why MUST an end-entity cert include a Key Usage, not including it is 
>>> a good
>>> way of specifying allow-all. You want to forbid allow-all?
>>
>>
>> No, I want to make it explicit. As your message shows, at least one PKIX
>> member (not to mention an unknown but significant number of non-PKIX 
>> people)
>> find the current text/usage quite confusing :-). Since virtually all CAs
>> already include keyUsage, explicitly requiring it would fix the 
>> problem at
>> virtually zero cost to implementors.
>>
>> Peter.

Date: Tue, 31 May 2005 09:48:15 -0400
From: "David A. Cooper" <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Absent keyUsage in certificates
Sender: [email-masked]

Peter,

This seems to be an issue that has caused confusion for several people, 
as Sam Roberts pointed out to me in another forum 
(http://cio.nist.gov/esd/emaildir/lists/pkits/msg00108.html).

When the keyUsage extension is absent, then the key can be used for any 
purpose (except as restricted by the basicConstraints, extendedKeyUsage, 
certificatePolicies, etc. extensions as Stefan mentioned).

The text that you quoted was intentionally written as "Conforming CAs 
MUST ..." because it is a requirement that ONLY applies to CAs.  So, 
section 4 and 6 are not contradictory.  The text from section 4 that you 
quoted imposes a requirement on CAs, but does not apply to relying 
parties.  The text that Sam quoted from section 6 is part of the path 
validation algorithm, which is used by relying parties but not CAs.

The basic idea is that while the PKIX Certificate and CRL profile (RFC 
3280, 3280bis) imposes stricter certificate and CRL generation 
requirements than X.509 does, there is no requirement to reject a 
certification path that is valid under X.509 simply because it was not 
issued in conformance with the PKIX profile.  While it would be nice if 
every CA followed the PKIX profile of X.509, I don't think PKIX should 
mandate that certificates be rejected simply because they were issued in 
accordance with a profile of X.509 that does not conform to the PKIX 
profile.  This is the reason that the path validation algorithm in RFC 
3280 and 3280bis was designed to accept any certification path that is 
valid under X.509 and it does not include checks to verify that 
certificates were issued in conformance to the PKIX profile.  So, even 
if PKIX required all certificates to include a keyUsage extension, this 
could only be a requirement for conforming CAs, not relying parties.

Sam suggested that I add text to section 6 of 3280bis clearly stating 
that the PKIX path validation algorithm is designed to accept any 
certification path that is valid under X.509, not just those that were 
issued in conformance with the PKIX profile.  He made the suggestion a 
few days after the -00 draft was originally submitted, but I intend to 
include this text in the -01 draft.

As to your question about whether section 4 takes precedence over 
section 6 or vice versa, I don't think there is a real answer.  In 
general, section 6 provides the definitive explanation of how to perform 
certification path validation.  However, section 6 does not repeat all 
of the details from section 4.  For example, section 6.1.3 steps (b) and 
(c) and section 6.1.4 step (g) discuss the processing of name 
constraints, but one must read section 4.2.1.10 to understand the rules 
for applying name constraints to each name form.  On the other hand, 
while section 4.2.1.11 provides a good textual description of the 
policyConstraints extension, this section does not provide enough detail 
to implement the path validation algorithm.  So, if you want a general 
understanding of the extension, read section 4.  If you want to 
implement the code to process the extension, read section 6.

BTW, if there are places where section 6 contradicts section 4, please 
point them out so that they can be fixed.  But remember that the 
algorithm in section 6 was not intended to verify that CAs issued 
certificates and CRLs in conformance with section 4.  So, if there is a 
requirement in section 4 of the form "conforming CAs MUST ...", there 
may not be a corresponding requirement imposed in relying parties.

Dave

Peter Gutmann wrote:

> Sam Roberts <[email-masked]> writes:
>
>> agree that allow-all or deny-all is sensible, and special-casing two 
>> of the
>> bits would be weird, but isn't allow-all what is specified now?
>
> Nope. See below.
>
>> This interpretation is based on the validation rules, section 6.1.4, rule
>> (n):
>>
> Oh, section 6 contradicts section 4 in a number of places, I take 
> section 4 as
> definitive since it specifies the intent of the spec whereas section 6 
> only
> contains an attempt at implementing that intent.
>
> (Another proposed improvement for bride-of-3280, indicate which of 
> section 4
> or 6 is definitive in the case of conflict).
>
>> I can't see anything that says that absence of Key Usage should 
>> trigger chain
>> validation failure.
>
> The exact text I quoted earlier, i.e:
>
> Conforming CAs MUST include this extension in certificates that contain
> public keys that are used to validate digital signatures on other 
> public key
> certificates or CRLs.
>
>> Its a long RFC, an you point to the text you are "squinting sideways" at?
>
> The keyUsage text, which covers the use of keyUsage in a very obtuse way.
> What the above is trying to say in a very roundabout way is:
>
> CA certificates must include a keyUsage extension with keyCertSign or
> crlSign bits set as appropriate.
>
>> Why MUST an end-entity cert include a Key Usage, not including it is 
>> a good
>> way of specifying allow-all. You want to forbid allow-all?
>
> No, I want to make it explicit. As your message shows, at least one PKIX
> member (not to mention an unknown but significant number of non-PKIX 
> people)
> find the current text/usage quite confusing :-). Since virtually all CAs
> already include keyUsage, explicitly requiring it would fix the problem at
> virtually zero cost to implementors.
>
> Peter.

Date: Tue, 31 May 2005 09:44:33 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: Absent keyUsage in certificates
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Cheers,
Sam

-- 
http://www.certicom.com

Content-class: urn:content-classes:message
Subject: CRL sequence issues
Date: Tue, 31 May 2005 15:35:24 +0200
From: "Vittek Robert" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Dear gentlemen,

I am involved in development of a system that is supposed to process electronically signed documents (possibly ten thousands per hour) while the response time (on the question if the signature is valid or not) should be "as low as possible". At the same time, it is crucial that the response is correct because a mistake can have serious legal consequences.

I have questions concerning certificate status validation when CRLs are the revocation mechanism. All of the references are made to RFC 3280.

CRL Validation algorithm described in 6.3 assumes usage of a local cache and somehow alibistically "assumes that all of the needed CRLs are available in a local cache". In 6.3.3, there are some rules to be followed on fetching all needed CRLs, one of them being very interesting.

         (2)  If the current time is before the value of the next update
         field and use-deltas is set, then obtain the current delta CRL
         that can be used to update the locally cached complete CRL as
         specified in section 5.2.4.

There is no rule specified if use-deltas is not set. At the same time description of Next Update field (5.1.2.5) says:

   This field indicates the date by which the next CRL will be issued.
   The next CRL could be issued before the indicated date, but it will
   not be issued any later than the indicated date.

So, there is a possibility that a complete CRL has been issued invalidating the one in local cache for the time in question (e.g. from Time Stamp Token) and this CRL should be downloaded. I think that the above mentioned paragraph in 6.3.3 should be modified to obtain a complete CRL in any case or at least make a check.

Anyway, it's been kind of a theoretical problem so far. In real world it is not feasible to make HTTP or FTP call to CA for every validated signature at the rate "ten thousands per hour". Even if it was, how can I be sure (using untrusted HTTP or FTP communication with most of CAs) that some traitor did not fetch my request and did not provided me with older CRL which still has next update field greater than time from TST. I can not. My uncertainty will disappear only after a CRL with ThisUpdate greater than TST is issued and I have downloaded all CRLs issued so far. Btw, CRL with ThisUpdate greater than TST is sometimes the first CRL that can invalidate a revoked certificate which makes the rules for fetching CRLs in algorithm for CRL Validation all erroneous.

So, this leads me to a question what mechanism can be exploited to ensure that I have downloaded a complete set of CRLs issued so far. First, I thought that crlNumber is sufficient. But crlNumbers must convey only monotonically increasing sequence - NOT LINEAR sequence. That means, some of the numbers can be omitted and I have no means to determine it. Do you have any suggestions?

Moreover, it may be critical to be sure to download the next CRL issued right after TST, because RFC 3280 states that:

   A complete CRL lists all unexpired certificates, within its scope,
   that have been revoked for one of the revocation reasons covered by
   the CRL scope.

               An entry is added to the CRL as part of the next update
   following notification of revocation.  An entry MUST NOT be removed
   from the CRL until it appears on one regularly scheduled CRL issued
   beyond the revoked certificate's validity period.

If TST < Cert.validTo < CRL(n).thisUpdate then CRL(n) is crucial for certificate status validation with respect to Time Stamp Token. Another reason to have a mechanism for a check if I am missing some CRL from sequence or not. Otherwise, there are cases when one is not able to say if a certificate was valid at TST time or not, hence if the signature is valid wrt. TST.

Maybe, I am just missing something in RFC 3280 (or any other) that will suddenly make everything clear to me.
In that case I apologize to the readers of this forum.

Sincerely,

Mgr. Robert Vittek
 
DITEC, a.s.
Bratislava Business Center V
Plyn�rensk� 7/C
821 09 Bratislava
 
voice: +421 2 58 222 487
fax: +421 2 58 222 777
cell: +421 908 797 827
e-mail: [email-masked]

Content-class: urn:content-classes:message
Subject: RE: Absent keyUsage in certificates
Date: Tue, 31 May 2005 14:05:01 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, "David Cross" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Peter,

> >and usage by applications EE certs with this extension absent to
indicate
> all

All purposes that is consistent with the rest of the certificate. Since
Basic Constraints MUST be present in CA certificates, this automatically
excludes CRL/Cert signing for EE certs.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of Peter Gutmann
> Sent: den 31 maj 2005 10:57
> To: David Cross; [email-masked]; [email-masked]
> Subject: RE: Absent keyUsage in certificates
> 
> 
> consumption
> In what way?  Why can't you just set all the flags that make sense
(e.g.
> all
> I've seen with keyUsage absent seem to be more an indication of CA
error
> than
> >and usage by applications EE certs with this extension absent to
indicate
> all

Content-class: urn:content-classes:message
Subject: RE: Absent keyUsage in certificates
Date: Tue, 31 May 2005 09:58:07 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I'm not sure I get the problem or what has to be fixed.

This extension defines the use of the public key in the certificate. So
obviously, in absence of this extension the usage is simply undefined in
the context of this extension.

The use of the public key may however still be constrained by other
means, such as certificate policy, EKU, Basic Constraints etc. So it is
not correct to define that absent key usage extension = all usages. 

The key usage extension is already required for CA certs.

/Stefan

> On Behalf Of Peter Gutmann
> Sent: den 30 maj 2005 18:31
> To: [email-masked]; [email-masked]
> Sam Roberts <[email-masked]> writes:
> 
> >I agree that allow-all or deny-all is sensible, and special-casing
two of
> the
> >bits would be weird, but isn't allow-all what is specified now?
> 
> Nope.  See below.
> 
rule
> >(n):
> Oh, section 6 contradicts section 4 in a number of places, I take
section
> 4 as
> definitive since it specifies the intent of the spec whereas section 6
> only
> contains an attempt at implementing that intent.
> 
> (Another proposed improvement for bride-of-3280, indicate which of
section
> 4
>  or 6 is definitive in the case of conflict).
> 
> chain
> >validation failure.
> The exact text I quoted earlier, i.e:
> 
>   Conforming CAs MUST include this extension in certificates that
contain
>   public keys that are used to validate digital signatures on other
public
> key
>   certificates or CRLs.
> 
> >Its a long RFC, an you point to the text you are "squinting sideways"
at?
> 
> The keyUsage text, which covers the use of keyUsage in a very obtuse
way.
> What the above is trying to say in a very roundabout way is:
> 
>   CA certificates must include a keyUsage extension with keyCertSign
or
>   crlSign bits set as appropriate.
> 
> good
> >way of specifying allow-all. You want to forbid allow-all?
> 
> No, I want to make it explicit.  As your message shows, at least one
PKIX
> member (not to mention an unknown but significant number of non-PKIX
> people)
> find the current text/usage quite confusing :-).  Since virtually all
CAs
> already include keyUsage, explicitly requiring it would fix the
problem at
> virtually zero cost to implementors.
> 
> Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Absent keyUsage in certificates
Date: Tue, 31 May 2005 20:56:51 +1200
Sender: [email-masked]

Peter.

Content-class: urn:content-classes:message
Subject: RE: Absent keyUsage in certificates
Date: Mon, 30 May 2005 22:57:58 -0700
From: "David Cross" <[email-masked]>
To: "Sam Roberts" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

David B. Cross 

-----Original Message-----

out of date).

Cheers,
Sam

--
http://www.certicom.com

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Absent keyUsage in certificates
Date: Tue, 31 May 2005 04:30:35 +1200
Sender: [email-masked]

Sam Roberts <[email-masked]> writes:

>I agree that allow-all or deny-all is sensible, and special-casing two of the
>bits would be weird, but isn't allow-all what is specified now?

Nope.  See below.

>This interpretation is based on the validation rules, section 6.1.4, rule
>(n):
>

Oh, section 6 contradicts section 4 in a number of places, I take section 4 as
definitive since it specifies the intent of the spec whereas section 6 only
contains an attempt at implementing that intent.

(Another proposed improvement for bride-of-3280, indicate which of section 4
 or 6 is definitive in the case of conflict).

>I can't see anything that says that absence of Key Usage should trigger chain
>validation failure.

The exact text I quoted earlier, i.e:

  Conforming CAs MUST include this extension in certificates that contain
  public keys that are used to validate digital signatures on other public key
  certificates or CRLs.

>Its a long RFC, an you point to the text you are "squinting sideways" at?

The keyUsage text, which covers the use of keyUsage in a very obtuse way.
What the above is trying to say in a very roundabout way is:

  CA certificates must include a keyUsage extension with keyCertSign or
  crlSign bits set as appropriate.

>Why MUST an end-entity cert include a Key Usage, not including it is a good
>way of specifying allow-all. You want to forbid allow-all?

No, I want to make it explicit.  As your message shows, at least one PKIX
member (not to mention an unknown but significant number of non-PKIX people)
find the current text/usage quite confusing :-).  Since virtually all CAs
already include keyUsage, explicitly requiring it would fix the problem at
virtually zero cost to implementors.

Peter.

Date: Mon, 30 May 2005 10:24:42 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: Absent keyUsage in certificates
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Wrote Peter Gutmann <[email-masked]>, on Mon, May 30, 2005 at 09:04:15PM +1200:
> If anyone from Verisign-called-Thawte is reading this, could you please fix
> your certs to include the keyUsage extension?  They're currently being issued
> without any keyUsage indication (or at least some of them are), which is
> causing some debate about how to apply them (the contact details I have for
> someone at Verisign seem to be out of date).
> 
> Also, could the current wording around keyUsage in bride-of-3280 be improved
> to indicate what the correct usage is if the extension is absent?  Squinting
> at the text sideways, it currently says that the key can be used for anything
> *except* cert and CRL verification, a rather strange allow-some/deny-some
> interpretation when it's more normal to have a default of either allow-all or
> deny-all (fail-open/fail-closed) in the absence of any further instructions,

> but this is quite hard to see for anyone who doesn't already know in advance
> how keyUsage works.  The sentence "Conforming CAs MUST include this extension
> in certificates that contain public keys that are used to validate digital
> signatures on other public key certificates or CRLs" is particularly obtuse. 
> 

Cheers,
Sam

-- 
http://www.certicom.com

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: 3280bis: key usage (13)
Date: Mon, 30 May 2005 21:19:48 +1200
Sender: [email-masked]

"David P. Kemp" <[email-masked]> writes:

>The suggestion at the time was to consider ephemeral signatures (entity
>authentication w/ liveness) to be purpose A, and persistent signatures (data
>origin authentication / integrity with no implication of presence/liveness)
>to be purpose B. That view was roundly rejected by all present, who
>subscribed to Stefan's theory of contagious fuzziness.

Uhh, just for the record, I've always supported this interpretation, it's
simple, straightforward, and easy to understand.  From private discussions in
the past that there are others here who support this as well, but they tend to
fall into the class of PKI app developers/implementors, who have mostly
abandoned this list or use it purely in read-only mode.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Absent keyUsage in certificates
Date: Mon, 30 May 2005 21:04:15 +1200
Sender: [email-masked]

If anyone from Verisign-called-Thawte is reading this, could you please fix
your certs to include the keyUsage extension?  They're currently being issued
without any keyUsage indication (or at least some of them are), which is
causing some debate about how to apply them (the contact details I have for
someone at Verisign seem to be out of date).

Also, could the current wording around keyUsage in bride-of-3280 be improved
to indicate what the correct usage is if the extension is absent?  Squinting
at the text sideways, it currently says that the key can be used for anything
*except* cert and CRL verification, a rather strange allow-some/deny-some
interpretation when it's more normal to have a default of either allow-all or
deny-all (fail-open/fail-closed) in the absence of any further instructions,
but this is quite hard to see for anyone who doesn't already know in advance
how keyUsage works.  The sentence "Conforming CAs MUST include this extension
in certificates that contain public keys that are used to validate digital
signatures on other public key certificates or CRLs" is particularly obtuse. 

(by far the simplest solution, there's no reason not to include this in a
cert, it's at the same level as basicConstraints, and virtually every CA in
existence does it anyway), or at least:

  Where this extension is absent, the certificate may be used for all purposes
  that the public-key algorithm is capable of except certificate and CRL
  signing and validation.
  
Peter.

To: Russ Housley <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: AD Review for draft-ietf-pkix-rfc3770bis
From: Sam Hartman <[email-masked]>
Date: Sat, 28 May 2005 16:38:13 -0400
Sender: [email-masked]

Hi, Russ.  These changes look good to me and I agree they address my
comments.

There doesn't seem to be any disagreement from the WG, so let's send
in a new draft unless we get an objection from the chairs.  I believe
I'm still waiting for a proto writeup from Tim.

Date: Fri, 27 May 2005 14:36:53 -0400
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: 3280bis: key usage (13)
Sender: [email-masked]

David Chadwick and I argued within X.509 that if there are going to be 
two (or four) bits,
then those bits should specify non-overlapping purposes (i.e.  DS for 
purpose A,
NR/CC/?? for purpose B, Cert-S for purpose C and CRL-S for purpose D, where
A, B, C and D are mutually exclusive and collectively exhaustive).  The 
suggestion
at the time was to consider ephemeral signatures (entity authentication 
w/ liveness)
to be purpose A, and persistent signatures (data origin authentication / 
integrity with no
implication of presence/liveness) to be purpose B.

That view was roundly rejected by all present, who subscribed to 
Stefan's theory of
contagious fuzziness.  So given that the decision has been made to 
create a fuzzy
non-implementable definition for NR/CC, I believe PKIX should adopt 
Stephen's
suggestion that CA's MUST set this bit to a random value.

Dave

Peter Gutmann wrote:

>Stephen Farrell <[email-masked]> writes:
>
>  
>
>>There's a bit (NR/CC) whose meaning has been the subject of loads and loads
>>of rambling discussion for ages and ages, and you want to define DS=
>>NOT(NR/CC)? Sounds like a great way to spread the NR fuzziness around, i.e. a
>>bad idea.
>>    
>>
>
>Oh was that what all that was about?  I'd gone off to reorganise my sock
>drawer and sort my packets of alphabet soup after the first 800 or so messages
>went by, so I probably missed some bits.
>
>The motivation for the comment was that we've just gone through the
>keyEncipherment vs. dataEncipherment debate where no-one's quite sure which
>bits to set for what occasion, and now in an attempt to fix the equally-
>problematic DS vs. NR we're creating a similar problem: what do you do in
>situations where neither the DS nor CC/NR bits fit?  I don't really care how
>the bits are defined, as long as it doesn't end up creating un-uses that can't
>be clearly signified with either DS or CC/NR.  Without this, we'll get another
>situation like the dataEncipherment one where something doesn't fall easily
>into either choice, so users and CAs claim that their choice of DS or CC
>applies, whatever happens to coincide with what their software does.
>
>  
>
>>    The digitalSignature bit is asserted when the subject public key
>>    is used for verifying digital signatures that are used
>>    with an entity authentication service, a data origin authentication
>>    service or/and an integrity service. Note that a certificate
>>    with only the digitalSignature bit set MUST NOT be used for
>>    verifying certificate or CRL signatures.
>>    
>>
>
>Sounds good to me.
>
>Peter.
>
>
>  
>

Date: Fri, 27 May 2005 12:51:54 -0400
From: "David A. Cooper" <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: 3280bis:  CRL validation
Sender: [email-masked]

Denis,

You have been saying for some time that "CRL validation is NOT specified 
in RFC 3280".  But, the more you post about CRL validation, the more 
clear it becomes that the problem is that you do not understand how CRL 
validation works in X.509.  Further, it is not clear that the problem is 
with the text of X.509 or RFC 3280 or if it is just that X.509 does not 
work the way you believe (or want) it to work.

X.509 was designed based on a model in which names are globally unique.  
In November on the X.500 mail list, you tried to argue otherwise, but it 
was demonstrated quite convincingly that this is what X.509 says:

    X.509, clause 8.3.2.1 (subject alternative name extension):

        The values in the alternatives of the GeneralName type are names 
of various forms as follows:

               directoryName is a directory name defined in accordance 
with ITU-T Rec. X.501 | ISO/IEC 9594-2;

(NOTE that directoryName is of type Name, which is the also the type 
used to define the issuer and subject fields)

    X.501, clause 9.1 (Definitions):

      9.1.4 (directory) name: A construct that singles out a particular 
object from all other objects.
      A name shall be unambiguous (that is, denote just one object), 
however it need not be unique
      (that is, be the only name which unambiguously denotes the object).

    X.501, clause 9.2 (Names in General):

      A (directory) name is a construct that identifies a particular 
object from among the set of all objects.
      A name shall be unambiguous, that is, denotes just one object. 
However, a name need not be unique,
      that is, be the only name that unambiguously denotes the object. A 
(directory) name also identifies
      an entry. This entry is either an object entry that represents the 
object or an alias entry which
      contains information that helps the Directory to locate the entry 
that represents the object.

      An object can be assigned a distinguished name without being 
represented by an entry in the
      Directory, but this name is then the name its object entry would 
have had were it represented
      in the Directory.

      Syntactically, each name for an object or entry is an ordered 
sequence of relative distinguished
      names (see 9.3).

      Name ::= CHOICE { -- only one possibility for now -- rdnSequence 
RDNSequence }

      RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

      DistinguishedName ::= RDNSequence

Note that I am not try to argue that it is impossible for two entities 
within a PKI to be assigned the same name, just that this would be 
inconsistent with the model upon which X.509 was developed.

In a message to the PKIX list on April 11 about the CRL AIA draft, you 
wrote:

> In order to build a path, a relying party needs to make sure of the 
> name of the CRL Issuer, which means not simply knowing the DN of the 
> CRL issuer but also all the other DNs from the upper CAs up to a root 
> key.

As noted above, in X.509 an object is uniquely identified by its DN.  
There is no notion of forming that "name" of an object by creating a 
sequence of DNs.  In the context of your comment above, you seem to be 
suggesting that the "name" of the CRL Issuer consists of the sequence of 
names from the certificates forming a certification path that starts at 
a "root" and ends with the CRL Issuer.  But, this does not make sense 
for two reasons.  First, in the X.500 series, naming is defined in 
X.501.  That is, the concept of PKI is not used in defining naming.  
Second, a naming scheme like this could only work if PKIs were limited 
to being hierarchies, which they are not.

In the same message on April 11, you wrote:

> Let us consider two different scenarios where this new extension [AIA 
> extension in a CRL] would be considered.
>
> Scenario A: The relying party does not trust any CRL issuer in 
> particular and will simply use the CRL Issuer designated by the 
> Certificate Issuer by means of the CRL DP extension.
>
> Scenario B: The relying party trusts at least a specific CRL issuer 
> and will get the CRLs from that CRL Issuer and then will make sure 
> that the information contained in them matches with the designation of 
> the Certificate Issuer.

X.509/RFC 3280 does not allow for scenario B.  With OCSP a relying party 
may choose to accept status information from a locally trusted OCSP 
server.  With CRLs, a CRL may only be used to verify the status of a 
certificate if the certificate explicitly indicates that CRLs from that 
issuer may be used.  This can be done in two ways.  Either (1) the 
certificate issuer and CRL issuer are the same entity (i.e., the issuer 
fields in the certificate and CRL contain the same name) or (2) the 
certificate includes a cRLDistributionPoints extension in which the 
cRLIssuer field is present and contains the name of the CRL issuer.  
This is covered in RFC 3280 in section 6.3.3, step (b)(1):

    6.3.3  CRL Processing

       (b)  Verify the issuer and scope of the complete CRL as follows:

             (1)  If the DP includes cRLIssuer, then verify that the issuer
             field in the complete CRL matches cRLIssuer in the DP and that
             the complete CRL contains an issuing distribution point
             extension with the indrectCRL boolean asserted.  Otherwise,
             verify that the CRL issuer matches the certificate issuer.

As to your specific comments below:

For issue 33, you are misinterpreting the certificateIssuer extension.  
The certificateIssuer extension is defined as GeneralNames so that one 
can include more than one name for the certificate issuer (e.g., the 
name from the issuer field of the certificate and one or more names from 
the issuerAltName extension of the certificate).  That is it is a 
sequence (or logically a set) of names for a single entity.  It is not 
intended to specify a certification path.

As for issue 43, as I argued above, whether you like it or not, X.509 
was designed based on the assumption that name collisions will not 
occur.  (Of course a "rogue" CA could issue such certificates, but X.509 
assumes that rogue CAs are untrusted (either they are never issued a 
certificate or certificates issued to them are revoked) so that any name 
collisions they create will not affect the security of the PKI).  Again, 
you may believe that it was a bad idea to make such an assumption, but 
this doesn't change the fact that this assumption was used in the design 
of X.509.

Recently, a number of people on the PKIX list, including you, have 
argued that it is unsafe to assume that no two authorities (e.g., CA 
and/or CRL issuer) will issue certificates and/or CRLs under the same 
name.  In particular, they are concerned that at some point there will 
be two trusted authorities that belong to the same PKI that are issuing 
certificates and CRLs under the same name, that no one will detect this, 
and that this may result in a relying party using a CRL issued by one of 
the authorities to validate a certificate issued by the other 
authority.  Since the CRL does not actually cover the certificate, it 
will not provide accurate information about the status of the certificate.

At the IETF meeting in November, Santosh presented a proposal for a 
restricted version of the certification path validation algorithm that 
would prevent a relying party from using a CRL issued by the wrong 
authority to validate the status of a certificate, even if name 
collisions occurred, so long as no trusted CA issued two certificates to 
different entities with the same subject DN.

At the meeting, the concern was expressed that incorporating this new 
algorithm into 3280bis would be too big of a change from RFC 3280 and so 
trying to incorporate it into 3280bis would unacceptably delay the 
completion of 3280bis.  So, it was suggested that Santosh's proposal 
should be advanced in a separate document.  At the same time, several 
people felt that if name collisions between authorities were ever going 
to be seen, it would be as a result of two authorities in two different 
PKIs using the same name, but with both authorities being trusted by a 
relying party as a result of the relying party using multiple trust 
anchors.  Indicating that the certification path for a certificate and 
the corresponding CRL should start at the same trust anchor would 
prevent the use of the wrong CRL in this case.  So, the initial 
agreement that came out of the November IETF meeting was to include a 
note in the security requirements section of 3280bis about the use of a 
common trust anchor in order to mitigate the risk that might result if a 
name collision ever did occur and to leave any further work on this 
issue to another document.

Note that I am personally in favor of Santosh's proposal, mainly because 
I believe that imposing such restrictions on the certification path for 
the CRL will limit the search space for the certification path and will 
thus lead to more efficient implementations.  While I am not 
particularly concerned about the name collision risk, I do not think 
that the restrictions that Santosh's algorithm imposes pose any problems 
either.  However, PKIX standards, including 3280bis, are developed by 
consensus; I cannot simply write my own personal views into the standard.

Dave

Denis Pinkas wrote:

> To the list,
>
> I changed the name of the thread which is now under 3280bis.
>
> As Tim mentioned: "it is clear that the current content of 3280bis 
> with respect to CRL validation does not enjoy consensus within the 
> working group".
>
> Issues 33 and 43 are directly related to this topic. They are both 
> copied below:
>
> 33) The certificateIssuer CRL entry extension contains a GeneralNames. 
> While RFC 3280 does not state this, there seems to be general 
> agreement that the certificateIssuer extension should only contain the 
> DN from the issuer field of the certificate being revoked.
>
>   3280bis states: "Conforming CRL issuers MUST include in [the
>   certificateIssuer] extension the distinguished name (DN) from the
>   issuer field of the certificate that corresponds to this CRL entry.
>   The encoding of the DN MUST be identical to the encoding used in the
>   certificate."
>
>
>  43) It should be noted in 3280bis that there is a risk that two 
> different
>      CAs (or a CA and a CRL issuer) may issue certificates and CRLs under
>      the same name and that if this happens there is a risk that a 
> relying
>      party will validate a certificate issued by one of these entities
>      using a CRL issued by the other.
>
>   The security considerations section of 3280bis states that CAs and CRL
>   issuers should be formed in a way that reduces the likelihood of name
>   collisions.  It also states that implementations validating CRLs MUST
>   ensure that the certification path of the target certificate and the
>   CRL issuer certification path used to validate the target certificate
>   terminate at the same trust anchor.
>
> Both statements are incorrect.
>
> For issue 43: name collisions are possible and a design cannot be 
> based on the assumption that name collisions, whether accidental or 
> intentional, will never happen. This means that chosing names to 
> "reduce the likehood of name collisions" is not a way to solve the 
> issue. Termination at the same trust anchor without additional details 
> does not solve the issue either.
>
> For issue 33: the certificateIssuer extension is defined as :
>
>      certificateIssuer ::= GeneralNames
>
> with
>
>      GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
>
> It is not defined as:
>
>      certificateIssuer ::= GeneralName
>
> ... and this is NOT an error.
>
> To go directly to the point, certificateIssuer may contain in practice 
> either:
>
>  - one name, or
>  - a sequence of names.
>
> If it contains one name, this means that this name MUST be certified 
> by the CA that has issued the certificate where the extension appears.
>
> If it contains a sequence of names, this means that the certification 
> path of the CRL issuer certificate formed using that sequence of names 
> MUST also terminate at the trust anchor of the target certificate.
>
> This is secure and avoids any name collision, either deliberate or 
> intentional.
>
> Denis

Content-class: urn:content-classes:message
Subject: RE: 3280bis: key usage (13)
Date: Fri, 27 May 2005 17:48:28 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

The problem is partly to understand what NR/CC is but the real issue why
they can be mutually exclusive is that they define properties of
different abstraction layers.

Applications on the message layer only understand signing within the
concept of data origin authentication and content integrity, they have
no clue whether the signature they process is going to be used for CC/NR
or not.

Example: e-mail client with S/MIME signing will never know the purpose
of signing.

Application on the higher application layers may however know exactly
why you are signing. E.g. web service enabling you to pay an invoice.
This application will know whether the purpose is CC/NR and can pick the
appropriate cert.

So in summary, if you define DS = all signing except CC/NR, they you
confuse all lower layer applications operating on the message layer who
don't have a clue whether their signatures are being used for CC/NR in
any higher layer context.

To the text proposed by Stephen:

It is not quite correct. That text forbids cert and CRL validation when
only DS is set, which is close bon not exactly right. E.g. it does not
prevent Cert and CRL validation when DS+NR/CC are set. I think you need
to move closer to the original RFC 3280 def.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of Stephen Farrell
> Sent: den 27 maj 2005 17:26
> To: Peter Gutmann
> Cc: [email-masked]; [email-masked]
> Subject: Re: 3280bis: key usage (13)
> 
> 
> 
> Peter,
> 
> > The motivation for the comment was that we've just gone through the
> > keyEncipherment vs. dataEncipherment debate where no-one's quite
sure
> which
> > bits to set for what occasion, and now in an attempt to fix the
equally-
> > problematic DS vs. NR we're creating a similar problem: [...]
> 
> Fair enough. Problem is we'll apparently never get agreement
> on what NR/CC means:-(
> 
> >>    The digitalSignature bit is asserted when the subject public key
> >>    is used for verifying digital signatures that are used
> >>    with an entity authentication service, a data origin
authentication
> >>    service or/and an integrity service. Note that a certificate
> >>    with only the digitalSignature bit set MUST NOT be used for
> >>    verifying certificate or CRL signatures.
> >
> > Sounds good to me.
> 
> Cool. Let's see what happens when Denis get back so,
> Stephen.
> 

Date: Fri, 27 May 2005 16:25:37 +0100
From: Stephen Farrell <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: 3280bis: key usage (13)
Sender: [email-masked]

Peter,

> The motivation for the comment was that we've just gone through the
> keyEncipherment vs. dataEncipherment debate where no-one's quite sure which
> bits to set for what occasion, and now in an attempt to fix the equally-
> problematic DS vs. NR we're creating a similar problem: [...]

Fair enough. Problem is we'll apparently never get agreement
on what NR/CC means:-(

>>    The digitalSignature bit is asserted when the subject public key
>>    is used for verifying digital signatures that are used
>>    with an entity authentication service, a data origin authentication
>>    service or/and an integrity service. Note that a certificate
>>    with only the digitalSignature bit set MUST NOT be used for
>>    verifying certificate or CRL signatures.
> 
> Sounds good to me.

Cool. Let's see what happens when Denis get back so,
Stephen.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: 3280bis: key usage (13)
Cc: [email-masked], [email-masked]
Date: Sat, 28 May 2005 03:16:03 +1200
Sender: [email-masked]

Stephen Farrell <[email-masked]> writes:

>There's a bit (NR/CC) whose meaning has been the subject of loads and loads
>of rambling discussion for ages and ages, and you want to define DS=
>NOT(NR/CC)? Sounds like a great way to spread the NR fuzziness around, i.e. a
>bad idea.

Oh was that what all that was about?  I'd gone off to reorganise my sock
drawer and sort my packets of alphabet soup after the first 800 or so messages
went by, so I probably missed some bits.

The motivation for the comment was that we've just gone through the
keyEncipherment vs. dataEncipherment debate where no-one's quite sure which
bits to set for what occasion, and now in an attempt to fix the equally-
problematic DS vs. NR we're creating a similar problem: what do you do in
situations where neither the DS nor CC/NR bits fit?  I don't really care how
the bits are defined, as long as it doesn't end up creating un-uses that can't
be clearly signified with either DS or CC/NR.  Without this, we'll get another
situation like the dataEncipherment one where something doesn't fall easily
into either choice, so users and CAs claim that their choice of DS or CC
applies, whatever happens to coincide with what their software does.

>     The digitalSignature bit is asserted when the subject public key
>     is used for verifying digital signatures that are used
>     with an entity authentication service, a data origin authentication
>     service or/and an integrity service. Note that a certificate
>     with only the digitalSignature bit set MUST NOT be used for
>     verifying certificate or CRL signatures.

Sounds good to me.

Peter.

Content-class: urn:content-classes:message
Subject: RE: 3280bis: key usage (13)
Date: Fri, 27 May 2005 16:13:33 +0100
From: "Stefan Santesson" <[email-masked]>
To: "David A. Cooper" <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

Agree with David.

We need to preserve the old logic in this regard.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of David A. Cooper
> Sent: den 27 maj 2005 15:51
> To: Denis Pinkas
> Cc: pkix
> Subject: Re: 3280bis: key usage (13)
> 
> 
> Denis,
> 
> I do not agree with your proposal for the digitalSignature bit.  Here
is
> the current text:
> 
>       The digitalSignature bit is asserted when the subject public key
>       is used with a digital signature mechanism to support security
>       services other than certificate signing (bit 5), or CRL signing
>       (bit 6).  Digital signature mechanisms are often used for entity
>       authentication and data origin authentication with integrity.
> 
> This text merely states that setting the digitalSignature bit, by
> itself, does not authorize relying parties to use the subject public
key
> to verify signatures on certificates or CRLs.  It does not prevent a
CA
> from setting digitalSignature, keyCertSign, and cRLSign in the same
> certificate.
> 
> Imposing this restriction would, for example, prevent a CA from using
> its certificate signing key to also sign OCSP responses.
> 
> Denis Pinkas wrote:
> 
> > Stephen,
> >
> > Just before leaving my office in a few minutes for a few days,
> > here is a new text proposal for the DS bit:
> >
> > New proposal for 3280bis:
> >
> >     The digitalSignature bit is asserted when the subject public key
> >     is used for verifying digital signatures that are used
> >     with an entity authentication service, a data origin
authentication
> >     service or/and an integrity service. However, it SHALL not be
set
> >     when certificate signing (bit 5) or CRL signing (bit 6) is set.
> >
> > Denis

From: "Santosh Chokhani" <[email-masked]>
To: "'pkix'" <[email-masked]>
Subject: RE: 3280bis: key usage (13)
Date: Fri, 27 May 2005 10:58:32 -0400
Importance: Normal
Sender: [email-masked]

I agree with David Cooper.  In addition to David's argument, Dennis's
proposal will also break many known PKI implementation for no security or
interoperability reasons.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Friday, May 27, 2005 9:51 AM
To: Denis Pinkas
Cc: pkix
Subject: Re: 3280bis: key usage (13)

Denis,

I do not agree with your proposal for the digitalSignature bit.  Here is 
the current text:

      The digitalSignature bit is asserted when the subject public key
      is used with a digital signature mechanism to support security
      services other than certificate signing (bit 5), or CRL signing
      (bit 6).  Digital signature mechanisms are often used for entity
      authentication and data origin authentication with integrity.

This text merely states that setting the digitalSignature bit, by 
itself, does not authorize relying parties to use the subject public key 
to verify signatures on certificates or CRLs.  It does not prevent a CA 
from setting digitalSignature, keyCertSign, and cRLSign in the same 
certificate.

Imposing this restriction would, for example, prevent a CA from using 
its certificate signing key to also sign OCSP responses.

Denis Pinkas wrote:

> Stephen,
>
> Just before leaving my office in a few minutes for a few days, here is 
> a new text proposal for the DS bit:
>
> New proposal for 3280bis:
>
>     The digitalSignature bit is asserted when the subject public key
>     is used for verifying digital signatures that are used
>     with an entity authentication service, a data origin authentication
>     service or/and an integrity service. However, it SHALL not be set
>     when certificate signing (bit 5) or CRL signing (bit 6) is set.
>
> Denis

Date: Fri, 27 May 2005 15:59:39 +0100
From: Stephen Farrell <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: 3280bis: key usage (13)
Sender: [email-masked]

Peter,

Peter Gutmann wrote:

> Wouldn't it be better to say that it's used for purposes other than CC?  By
> saying that DS can only be used for purposes A, B, and C, and CC for purpose
> D, what happens if someone wants to mark a key for purpose E?  Since CC seems
> to be the more restrictive, it would be better to say that DS is to be used
> for everything else.  If not, we'd need a third signature bit to cover the
> 'other' category that's explicitly excluded from DS and CC.

You're kidding, right?

There's a bit (NR/CC) whose meaning has been the subject of
loads and loads of rambling discussion for ages and ages,
and you want to define DS=NOT(NR/CC)? Sounds like a great
way to spread the NR fuzziness around, i.e. a bad idea.

 >>However, it SHALL not be set when certificate signing (bit 5) or CRL 
signing
 >>(bit 6) is set.
 >
 > Why not?  The intent of the original text was to say that
 > digitalSignature doesn't mean you can use the cert for cert/CRL
 > signing, now it says something completely different, that a
 > cert-signing cert can never be used for any other purpose.  This
 > wording change would make a number of CAs non-compliant, since
 > they do use their CA certs for other purposes (don't ask me why,
 > I just see the things turn up from time to time).  The wording
 > should be something like "Setting this bit doesn't mean the
 > cert can be used for cert or CRL signing; for that, you need
 > to set the cert/CRL signing bits".

You're right there (as is David C.) So we should replace Denis'
last sentence with something like yours, giving maybe:

     The digitalSignature bit is asserted when the subject public key
     is used for verifying digital signatures that are used
     with an entity authentication service, a data origin authentication
     service or/and an integrity service. Note that a certificate
     with only the digitalSignature bit set MUST NOT be used for
     verifying certificate or CRL signatures.

And the certificate and CRL signing bits are described elsewhere.

Stephen.

From: "Santosh Chokhani" <[email-masked]>
To: "'pkix'" <[email-masked]>
Subject: RE: 3280bis: key usage (13)
Date: Fri, 27 May 2005 10:43:47 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01C562A8.F9290510
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X.509 V1 or V2 did not have any extensions.  Thus, neither key usage nor
certificate policies were part of v1 or v2.  These extensions came about =
in
v3.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Kazin, Joel
Sent: Friday, May 27, 2005 9:20 AM
To: Stefan Santesson; Denis Pinkas; Stephen Farrell
Cc: Hoyt L Kesterson II; pkix
Subject: RE: 3280bis: key usage (13)

The core problem is labeling the bit non-repudiation.  It goes against =
the
legal idea that you can attempt to repudiate your alleged actions even =
when
your defense is weaker than "the cat ate my homework".  To me,
non-repudiation is more of a marketing description than a technical,
contractual, or legal description of what the signer intended to do. =20

A secondary problem is that the non-repudiation bit doesn't tell a =
relying
party or third party enough.  The logical place to look for such =
information
is in the id-ce-certificatePolicies extension.  Was the
id-ce-certificatePolicies extension part of the original x.509 v1
specification?  If that is true, then perhaps the non-repudiation bit is
just a holdover from the original x.509 v1 certificate definition?  If =
my
arguments are true then we can: 1) keep calling it non-repudiation and
strongly deprecate its use, 2) change the name and deprecate its use, 3)
change the name and allow its use. I favor 1 over 2 over 3. =20

At 07:06 AM 5/27/2005 -0500, Stefan Santesson wrote:

Speaking as implementer and not design team member, I can live with both =

texts since they allow me to do the same thing.=20

It allows my low level application to add a digital signature supported=20
by the digital signature bit, where the intention of that application is =

to add integrity and origin authentication, while the use of the=20
signature in practice (higher layers) ends up being used as evidence of=20
some kind of commitment.=20

Example. An e-mail application adds an arbitrary signature supported by=20
the DS bit, while the body of the text reads "Through the digital=20
signature on this e-mail I commit to....). This is now a perfectly valid =

scenario according to both texts.=20

The real defect that was fixed was that the digital signature bit said=20
that it was for purposes "other" than NR. That is now gone in both=20
standards.=20

I agree to Stephen's rationale to keep the name nonRepudiation. It is=20
not worth the cost to change the name. Stephen's point here was missing=20
in the X.509 discussions of a name change.=20

Stefan Santesson=20
Program Manager, Standards Liaison=20
Windows Security=20
 =20

> -----Original Message-----=20
> From: [email-masked]=20
[mailto:[email-masked]]=20
> On Behalf Of Denis Pinkas=20
> Sent: den 27 maj 2005 12:29=20
> To: Stephen Farrell=20
> Cc: Hoyt L Kesterson II; pkix=20
> Subject: Re: 3280bis: key usage (13)=20
>=20
>=20
> Stephen,=20
>=20
> I agree with everything Hoyt said on bit 1.=20
>=20
> However, there are two sides for this coin : bit 0 and bit 1.=20
>=20
> Both are again copied below:=20
>=20
> ISO Corrigendum:=20
>=20
>      a) digitalSignature: for verifying digital signatures that are=20
used=20
>         with an entity authentication service, a data origin=20
> authentication=20
>         service or/and an integrity service;=20
>=20
> 3280bis:=20
>=20
>      The digitalSignature bit is asserted when the subject public key=20
>      is used with a digital signature mechanism to support security=20
>      services other than certificate signing (bit 5), or CRL signing=20
>      (bit 6).  Digital signature mechanisms are often used for entity=20
>      authentication and data origin authentication with integrity.=20
>=20
> The current text of 3280bis for bit 0 (ds) is incompatible with the=20
ISO=20
> Corrigendum.=20
>=20
> As Hoyt already said, any new text should align with the definition in =

the=20
> approved technical corrigenda against the 4th edition and in the=20
upcoming=20
> 5th edition.=20
>=20
> Denis=20
>=20
> > Hi Hoyt,=20
> >=20
> > Hoyt L Kesterson II wrote:=20
> >=20
> >> Stephen=20
> >>=20
> >> I am somewhat dismayed at your reaction to the new text in X.509.=20
> >=20
> >=20
> > I'm sorry about that, but I guess I'm just fed up with the=20
> > NR bit, though I can understand how people who've worked=20
> > hard to try fix it might be dismayed.=20
> >=20
> > (BTW: I once suggested that CAs MUST set this bit randomly=20
> > since that was the only way I could see to kill it off=20
> > properly. If you can get that into X.509 then I'd be happy=20
> > for 3280bis to align:-)=20
> >=20
> >  > I am not going to argue with you here (maybe in a bar the next=20
time=20
> >  > we run into each other).=20
> >=20
> > Good idea!=20
> >=20
> >> However, I do want to mention several points.=20
> >>=20
> >> 1) I initiated the change in text because of the various=20
> interpretations=20
> >=20
> >  > by implementors that were resulting in non-interoperable=20
> >  > implementations. It was a conversation with a PKIXer at a RSA=20
> >  > conference a few years ago that caused me to articulate a private =

> >  > concern.=20
> >=20
> > I agree that everything connected with this bit has been=20
> > confused and remains so.=20
> >=20
> >> 2) The legal community was very confused. There was even a=20
> >=20
> >  > paper castigating the standard developers for mandating that=20
> >  > one could not repudiate an action.=20
> >=20
> > Maybe the mistake was defining a bit that laywers care about?=20
> >=20
> >> 3) There were several meetings held where there was significant=20
> >=20
> >  > participation by people in the IETF PKIX group (as well as=20
> >  > lawyers). All agreed there was a problem with the published text. =

> >  > Denis and I argued long and hard over wording but we didn't=20
> >  > disagree on the need for new text and its general intent.=20
> >=20
> > Fair enough.=20
> >=20
> >> 4) Russ was concerned that change would cause a problem=20
> >=20
> >  > with existing IETF standards and was not too happy with a=20
> >  > change to the name of the bit. That's why I put the line=20
> >  > in that you referenced. However, that was to grandfather=20
> >  > existing text, not to allow new text to continue using=20
> >  > the old term and definitions.=20
> >=20
> > Ok. Here's the real reason not to change: Many people use=20
> > ASN.1 compilers which means that names from the ASN.1=20
> > module end up being directly used in higher layer code.=20
> > Changing the name causes that code not to compile. I'd=20
> > say that there's quite a lot of 3280 code in the world=20
> > at this stage. So, if the semantics isn't supposed to=20
> > have changed (and I assume that is meant to be the=20
> > case) then this cost just doesn't seem worthwhile.=20
> >=20
> >> 5) It is the definition that is important. I recommend=20
> >=20
> >  > that any new text align with the definition in the approved=20
> >  > technical corrigenda against the 4th edition and in=20
> >  > the upcoming 5th edition.=20
> >=20
> > While I'd rather not see any more text added on this,=20
> > (there's been way too much already) I wouldn't have a big=20
> > issue with trying to help a reader make sense of the=20
> > fact that 3280bis and x.509 name this bit differently.=20
> >=20
> > However text like the sentence below is IMO almost=20
> > certain to cause even more confusion:=20
> >=20
> >   The precise type of commitment of the signer e.g. "reviewed=20
> >   and approved" or "with the intent to be bound", may be=20
> >   signalled by the content being signed, e.g. the signed=20
> >   document itself or some additional signed information.=20
> >=20
> > That sounds like the sole purpose of the CC-bit is as=20
> > a flag to indicate when some other bits somewhere else=20
> > tell you what the CC-bit means.=20
> >=20
> > So in the absence of some better text I think that 3280bis=20
> > is better off just saying "NR a.k.a. CC" as it currently=20
> > does.=20
> >=20
> > Regards,=20
> > Stephen.=20
> >=20
> >>=20
> >> At 14:49 +0100 5/26/05, Stephen Farrell wrote:=20
> >>=20
> >>> Denis,=20
> >>>=20
> >>>=20
> >>>> Please align with the the ISO-ITU text.=20
> >>>=20
> >>>=20
> >>> Do you mean we should rename the bits and include the=20
> >>> other new x.509 text? The design team were against=20
> >>> doing that.=20
> >>>=20
> >>> Is there any (good) reason other than alignment to=20
> >>> make such a change?=20
> >>>=20
> >>> Personally, I find the new x.509 text worse, although=20
> >>> it does say: "Note that it is not incorrect to refer to=20
> >>> this keyUsage bit using the identifier nonRepudiation."=20
> >>> So I can argue that we are aligned, just not identical.=20
> >>>=20
> >>> But of course, I'm from the non-repudiation is non-sense=20
> >>> camp so I may not be the best judge.=20
> >>>=20
> >>> Stephen.=20
> >>>=20
> >>> PS: A quibble:=20
> >>>=20
> >>>=20
> >>>>  The new text in X.509 aligns with the text in RFC 3280.  No=20
changes=20
> >>>>  are required to 3280bis.  A comment has been added to the ASN.1=20
for=20
> >>>>  KeyUsage stating that "recent editions of X.509 have renamed=20
> >>>>  [the nonRepudiation] bit to contentCommitment"=20
> >>>>=20
> >>>> This statement is untrue.=20
> >>>=20
> >>>=20
> >>> The paragraph to which I assume you refer contains 3=20
> >>> statements - it'd be easier to close these threads if=20
> >>> you were more precise. (I think I got what you want=20
> >>> by the end of the mail though...)=20
> >>>=20
> >>> PPS: "This statement is untrue."=20
> >>>    Are you from Crete after all? :-)=20
> >>>=20
> >>>=20
> >>>=20
> >>>=20
> >>> Denis Pinkas wrote:=20
> >>>=20
> >>>=20
> >>>> To the list,=20
> >>>>=20
> >>>> The disposition of comments states:=20
> >>>>=20
> >>>> 13) The descriptions of the meanings of the digitalSignature and=20
> >>>>    nonRepudiation bits of keyUsage may need to be adjusted based=20
> >>>>    on the work in X.509=20
> >>>>=20
> >>>> The new text in X.509 aligns with the text in RFC 3280.  No=20
changes=20
> >>>> are required to 3280bis.  A comment has been added to the ASN.1=20
for=20
> >>>> KeyUsage stating that "recent editions of X.509 have renamed=20
> >>>> [the nonRepudiation] bit to contentCommitment"=20
> >>>>=20
> >>>> This statement is untrue.=20
> >>>>=20
> >>>> The text from X.509 has been published in Corrigendum 3 (04/2004) =

> >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called=20
> >>>>=20
> >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).=20
> >>>>=20
> >>>> An extract from this text is copied below:=20
> >>>>=20
> >>>> a) digitalSignature: for verifying digital signatures that are=20
used=20
> >>>>  with an entity authentication service, a data origin=20
authentication=20
> >>>>  service or/and an integrity service;=20
> >>>>=20
> >>>> b) contentCommitment: for verifying digital signatures which are=20
> >>>> intended=20
> >>>>  to signal that the signer is committing to the content being=20
signed.=20
> >>>>  The type of commitment the certificate can be used to support=20
may be=20
> >>>>  further constrained by the CA, e.g. through a certificate=20
policy.=20
> >>>>  The precise type of commitment of the signer e.g. "reviewed and=20
> >>>>  approved" or "with the intent to be bound", may be signalled by=20
the=20
> >>>>  content being signed, e.g. the signed document itself or some=20
> >>>> additional=20
> >>>>  signed information.=20
> >>>>=20
> >>>>  Since a content commitment signing is considered to be a=20
digitally=20
> >>>> signed=20
> >>>>  transaction, the digitalSignature bit need not be set in the=20
> >>>> certificate.=20
> >>>>  If it is set, it does not affect the level of commitment the=20
signer=20
> >>>> has=20
> >>>>  endowed in the signed content.=20
> >>>>=20
> >>>>  Note that it is not incorrect to refer to this keyUsage bit=20
using=20
> the=20
> >>>>  identifier nonRepudiation. However, the use of this identifier=20
has=20
> >>>> been=20
> >>>>  deprecated. Regardless of the identifier used, the semantics of=20
> >>>> this bit=20
> >>>>  are as specified in this Directory Specification.=20
> >>>>=20
> >>>> The text from 3280 is copied below:=20
> >>>>=20
> >>>>     The digitalSignature bit is asserted when the subject public=20
key=20
> >>>>     is used with a digital signature mechanism to support=20
security=20
> >>>>     services other than certificate signing (bit 5), or CRL=20
signing=20
> >>>>     (bit 6).  Digital signature mechanisms are often used for=20
entity=20
> >>>>     authentication and data origin authentication with integrity. =

> >>>>=20
> >>>>     The nonRepudiation bit is asserted when the subject public=20
key is=20
> >>>>     used to verify digital signatures used to provide a non-=20
> >>>>     repudiation service which protects against the signing entity =

> >>>>     falsely denying some action, excluding certificate or CRL=20
> signing.=20
> >>>>     In the case of later conflict, a reliable third party may=20
> >>>>     determine the authenticity of the signed data.=20
> >>>>=20
> >>>>     Further distinctions between the digitalSignature and=20
> >>>>     nonRepudiation bits may be provided in specific certificate=20
> >>>>     policies.=20
> >>>>=20
> >>>> The text from 3280bis does not align with the ISO-ITU text.=20
> >>>> Please align with the the ISO-ITU text.=20
> >>>>=20
> >>>> Denis=20
> >>>=20
> >>=20
> >>=20
> >>=20
> >=20
> >=20
>=20

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com <http://www.atosorigin.com/>=20

------=_NextPart_000_0031_01C562A8.F9290510
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2627" name=3DGENERATOR></HEAD>
<BODY>
<DIV><STRONG><FONT face=3DArial color=3D#008000 size=3D2><SPAN=20
class=3D302464114-27052005>X.509 V1 or V2 did not have any =
extensions.&nbsp; Thus,=20
neither key usage nor certificate policies were part of v1 or v2.&nbsp; =
These=20
extensions came about in v3.</SPAN></FONT></STRONG></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Kazin, Joel<BR><B>Sent:</B> Friday, May 27, 2005 9:20=20
  AM<BR><B>To:</B> Stefan Santesson; Denis Pinkas; Stephen =
Farrell<BR><B>Cc:</B>=20
  Hoyt L Kesterson II; pkix<BR><B>Subject:</B> RE: 3280bis: key usage=20
  (13)<BR><BR></FONT></DIV>The core problem is labeling the bit=20
  non-repudiation.&nbsp; It goes against the legal idea that you can =
attempt to=20
  repudiate your alleged actions even when your defense is weaker than =
"the cat=20
  ate my homework".&nbsp; To me, non-repudiation is more of a marketing=20
  description than a technical, contractual, or legal description of =
what the=20
  signer intended to do.&nbsp; <BR><BR>A secondary problem is that the=20
  non-repudiation bit doesn't tell a relying party or third party =
enough.&nbsp;=20
  The logical place to look for such information is in the=20
  id-ce-certificatePolicies extension.&nbsp; Was the =
id-ce-certificatePolicies=20
  extension part of the original x.509 v1 specification?&nbsp; If that =
is true,=20
  then perhaps the non-repudiation bit is just a holdover from the =
original=20
  x.509 v1 certificate definition?&nbsp; If my arguments are true then =
we can:=20
  1) keep calling it non-repudiation and strongly deprecate its use, 2) =
change=20
  the name and deprecate its use, 3) change the name and allow its use. =
I favor=20
  1 over 2 over 3.&nbsp; <BR><BR><BR>At 07:06 AM 5/27/2005 -0500, Stefan =

  Santesson wrote:<BR><BR>
  <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite"><FONT =
size=3D2>Speaking as=20
    implementer and not design team member, I can live with both</FONT>=20
    <BR><FONT size=3D2>texts since they allow me to do the same =
thing.</FONT>=20
    <BR><BR><FONT size=3D2>It allows my low level application to add a =
digital=20
    signature supported</FONT> <BR><FONT size=3D2>by the digital =
signature bit,=20
    where the intention of that application is</FONT> <BR><FONT =
size=3D2>to add=20
    integrity and origin authentication, while the use of the</FONT> =
<BR><FONT=20
    size=3D2>signature in practice (higher layers) ends up being used as =
evidence=20
    of</FONT> <BR><FONT size=3D2>some kind of commitment.</FONT> =
<BR><BR><FONT=20
    size=3D2>Example. An e-mail application adds an arbitrary signature =
supported=20
    by</FONT> <BR><FONT size=3D2>the DS bit, while the body of the text =
reads=20
    "Through the digital</FONT> <BR><FONT size=3D2>signature on this =
e-mail I=20
    commit to....). This is now a perfectly valid</FONT> <BR><FONT=20
    size=3D2>scenario according to both texts.</FONT> <BR><BR><FONT =
size=3D2>The=20
    real defect that was fixed was that the digital signature bit =
said</FONT>=20
    <BR><FONT size=3D2>that it was for purposes "other" than NR. That is =
now gone=20
    in both</FONT> <BR><FONT size=3D2>standards.</FONT> <BR><BR><FONT =
size=3D2>I=20
    agree to Stephen's rationale to keep the name nonRepudiation. It =
is</FONT>=20
    <BR><FONT size=3D2>not worth the cost to change the name. Stephen's =
point here=20
    was missing</FONT> <BR><FONT size=3D2>in the X.509 discussions of a =
name=20
    change.</FONT> <BR><BR><FONT size=3D2>Stefan Santesson</FONT> =
<BR><FONT=20
    size=3D2>Program Manager, Standards Liaison</FONT> <BR><FONT =
size=3D2>Windows=20
    Security</FONT> <BR><FONT size=3D2>&nbsp;</FONT> <BR><BR><FONT =
size=3D2>&gt;=20
    -----Original Message-----</FONT> <BR><FONT size=3D2>&gt; From:=20
    [email-masked]</FONT> <BR><FONT size=3D2>[<A=20
    =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]</FONT>=20
    <BR><FONT size=3D2>&gt; On Behalf Of Denis Pinkas</FONT> <BR><FONT =
size=3D2>&gt;=20
    Sent: den 27 maj 2005 12:29</FONT> <BR><FONT size=3D2>&gt; To: =
Stephen=20
    Farrell</FONT> <BR><FONT size=3D2>&gt; Cc: Hoyt L Kesterson II; =
pkix</FONT>=20
    <BR><FONT size=3D2>&gt; Subject: Re: 3280bis: key usage (13)</FONT> =
<BR><FONT=20
    size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
    Stephen,</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; I agree=20
    with everything Hoyt said on bit 1.</FONT> <BR><FONT size=3D2>&gt;=20
    </FONT><BR><FONT size=3D2>&gt; However, there are two sides for this =
coin :=20
    bit 0 and bit 1.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
    Both are again copied below:</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; ISO Corrigendum:</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) digitalSignature: for =
verifying=20
    digital signatures that are</FONT> <BR><FONT size=3D2>used</FONT> =
<BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with =
an entity=20
    authentication service, a data origin</FONT> <BR><FONT size=3D2>&gt; =

    authentication</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
service or/and=20
    an integrity service;</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; 3280bis:</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The digitalSignature bit =
is=20
    asserted when the subject public key</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is used with a digital =
signature=20
    mechanism to support security</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; services other than =
certificate=20
    signing (bit 5), or CRL signing</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (bit 6).&nbsp; Digital =
signature=20
    mechanisms are often used for entity</FONT> <BR><FONT=20
    size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authentication and data =
origin=20
    authentication with integrity.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; The current text of 3280bis for bit 0 (ds) is =
incompatible with=20
    the</FONT> <BR><FONT size=3D2>ISO</FONT> <BR><FONT size=3D2>&gt;=20
    Corrigendum.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; As=20
    Hoyt already said, any new text should align with the definition =
in</FONT>=20
    <BR><FONT size=3D2>the</FONT> <BR><FONT size=3D2>&gt; approved =
technical=20
    corrigenda against the 4th edition and in the</FONT> <BR><FONT=20
    size=3D2>upcoming</FONT> <BR><FONT size=3D2>&gt; 5th edition.</FONT> =
<BR><FONT=20
    size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Denis</FONT> <BR><FONT =
size=3D2>&gt;=20
    </FONT><BR><FONT size=3D2>&gt; &gt; Hi Hoyt,</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Hoyt L Kesterson II =
wrote:</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt; =

    Stephen</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt; I am somewhat dismayed at your reaction to the new text in=20
    X.509.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; I'm sorry about that, but I =
guess I'm=20
    just fed up with the</FONT> <BR><FONT size=3D2>&gt; &gt; NR bit, =
though I can=20
    understand how people who've worked</FONT> <BR><FONT size=3D2>&gt; =
&gt; hard=20
    to try fix it might be dismayed.</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; (BTW: I once suggested that CAs MUST =
set this bit=20
    randomly</FONT> <BR><FONT size=3D2>&gt; &gt; since that was the only =
way I=20
    could see to kill it off</FONT> <BR><FONT size=3D2>&gt; &gt; =
properly. If you=20
    can get that into X.509 then I'd be happy</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
    for 3280bis to align:-)</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&nbsp; &gt; I am not going to argue with you here =
(maybe in=20
    a bar the next</FONT> <BR><FONT size=3D2>time</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&nbsp; &gt; we run into each other).</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Good idea!</FONT> <BR><FONT =

    size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt; However, =
I do want to=20
    mention several points.</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt; 1) I initiated the change in text =
because of=20
    the various</FONT> <BR><FONT size=3D2>&gt; interpretations</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; by =

    implementors that were resulting in non-interoperable</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&nbsp; &gt; implementations. It was a conversation =
with a=20
    PKIXer at a RSA</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; =
conference a=20
    few years ago that caused me to articulate a private</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&nbsp; &gt; concern.</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; I agree that everything =
connected=20
    with this bit has been</FONT> <BR><FONT size=3D2>&gt; &gt; confused =
and=20
    remains so.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt; 2) The legal community was very confused. There was even =
a</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp; &gt;=20
    paper castigating the standard developers for mandating that</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; one could not repudiate an=20
    action.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
    Maybe the mistake was defining a bit that laywers care about?</FONT> =

    <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt; =
3) There=20
    were several meetings held where there was significant</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; =
participation=20
    by people in the IETF PKIX group (as well as</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&nbsp; &gt; lawyers). All agreed there was a problem with the =
published=20
    text.</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; Denis and I =
argued long=20
    and hard over wording but we didn't</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp;=20
    &gt; disagree on the need for new text and its general =
intent.</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
Fair=20
    enough.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt; 4) Russ was concerned that change would cause a =
problem</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp; &gt; with=20
    existing IETF standards and was not too happy with a</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&nbsp; &gt; change to the name of the bit. That's =
why I put=20
    the line</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; in that you=20
    referenced. However, that was to grandfather</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&nbsp; &gt; existing text, not to allow new text to continue=20
    using</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; the old term =
and=20
    definitions.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; Ok. Here's the real reason not to change: Many people =
use</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; ASN.1 compilers which means that names =
from the=20
    ASN.1</FONT> <BR><FONT size=3D2>&gt; &gt; module end up being =
directly used in=20
    higher layer code.</FONT> <BR><FONT size=3D2>&gt; &gt; Changing the =
name=20
    causes that code not to compile. I'd</FONT> <BR><FONT size=3D2>&gt; =
&gt; say=20
    that there's quite a lot of 3280 code in the world</FONT> <BR><FONT=20
    size=3D2>&gt; &gt; at this stage. So, if the semantics isn't =
supposed=20
    to</FONT> <BR><FONT size=3D2>&gt; &gt; have changed (and I assume =
that is=20
    meant to be the</FONT> <BR><FONT size=3D2>&gt; &gt; case) then this =
cost just=20
    doesn't seem worthwhile.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt; 5) It is the definition that is important. I=20
    recommend</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&nbsp; &gt; that any new text align with the definition in the=20
    approved</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp; &gt; technical =
corrigenda=20
    against the 4th edition and in</FONT> <BR><FONT size=3D2>&gt; =
&gt;&nbsp; &gt;=20
    the upcoming 5th edition.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; While I'd rather not see any more text added on=20
    this,</FONT> <BR><FONT size=3D2>&gt; &gt; (there's been way too much =
already)=20
    I wouldn't have a big</FONT> <BR><FONT size=3D2>&gt; &gt; issue with =
trying to=20
    help a reader make sense of the</FONT> <BR><FONT size=3D2>&gt; &gt; =
fact that=20
    3280bis and x.509 name this bit differently.</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; However text like the =
sentence below=20
    is IMO almost</FONT> <BR><FONT size=3D2>&gt; &gt; certain to cause =
even more=20
    confusion:</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&nbsp;&nbsp; The precise type of commitment of the signer e.g.=20
    "reviewed</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp; and =
approved" or=20
    "with the intent to be bound", may be</FONT> <BR><FONT size=3D2>&gt; =

    &gt;&nbsp;&nbsp; signalled by the content being signed, e.g. the=20
    signed</FONT> <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp; document =
itself or some=20
    additional signed information.</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; That sounds like the sole purpose of =
the CC-bit=20
    is as</FONT> <BR><FONT size=3D2>&gt; &gt; a flag to indicate when =
some other=20
    bits somewhere else</FONT> <BR><FONT size=3D2>&gt; &gt; tell you =
what the=20
    CC-bit means.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; So in the absence of some better text I think that =
3280bis</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; is better off just saying "NR a.k.a. =
CC" as it=20
    currently</FONT> <BR><FONT size=3D2>&gt; &gt; does.</FONT> <BR><FONT =

    size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
Regards,</FONT> <BR><FONT=20
    size=3D2>&gt; &gt; Stephen.</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT> <BR><FONT=20
    size=3D2>&gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt; At =
14:49 +0100=20
    5/26/05, Stephen Farrell wrote:</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt; Denis,</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt;&gt; Please align with the the ISO-ITU =
text.</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt; Do you mean =
we should=20
    rename the bits and include the</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;=20
    other new x.509 text? The design team were against</FONT> <BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt; doing that.</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt; Is there =
any (good)=20
    reason other than alignment to</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;=20
    make such a change?</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt; Personally, I find the new =
x.509 text=20
    worse, although</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt; it does =
say: "Note=20
    that it is not incorrect to refer to</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt; this keyUsage bit using the identifier =
nonRepudiation."</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt; So I can argue that we are =
aligned, just=20
    not identical.</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt; But of course, I'm from the =
non-repudiation is=20
    non-sense</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt; camp so I may =
not be the=20
    best judge.</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt; Stephen.</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt; PS: A =
quibble:</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp; =
The new=20
    text in X.509 aligns with the text in RFC 3280.&nbsp; No</FONT> =
<BR><FONT=20
    size=3D2>changes</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt;&nbsp; are=20
    required to 3280bis.&nbsp; A comment has been added to the =
ASN.1</FONT>=20
    <BR><FONT size=3D2>for</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt;&nbsp;=20
    KeyUsage stating that "recent editions of X.509 have renamed</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp; [the nonRepudiation] =
bit to=20
    contentCommitment"</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt;</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt; This statement is =
untrue.</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt; The =
paragraph to=20
    which I assume you refer contains 3</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt; statements - it'd be easier to close these threads =
if</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt; you were more precise. (I think =
I got=20
    what you want</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt; by the end =
of the=20
    mail though...)</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt; PPS: "This statement is untrue."</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Are you from Crete =
after all?=20
    :-)</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt; Denis=20
    Pinkas wrote:</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt; To=20
    the list,</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt;&gt; The disposition of comments =
states:</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt; 13) The descriptions of the meanings of the=20
    digitalSignature and</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; nonRepudiation bits of keyUsage =
may need=20
    to be adjusted based</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; on the work in X.509</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt;=20
    The new text in X.509 aligns with the text in RFC 3280.&nbsp; =
No</FONT>=20
    <BR><FONT size=3D2>changes</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt; are=20
    required to 3280bis.&nbsp; A comment has been added to the =
ASN.1</FONT>=20
    <BR><FONT size=3D2>for</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt; KeyUsage=20
    stating that "recent editions of X.509 have renamed</FONT> <BR><FONT =

    size=3D2>&gt; &gt;&gt;&gt;&gt; [the nonRepudiation] bit to=20
    contentCommitment"</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt;</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt; This statement is =
untrue.</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt; The text from X.509 has been published in =
Corrigendum 3=20
    (04/2004)</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt; on pages 4 =
and 5=20
    (see ISO/IEC 9594-8:2000/Cor.3:2004 also called</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt; =
ITU-T Rec.=20
    X.509 (2000)/Cor.3 (04/2004)).</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt; An =
extract=20
    from this text is copied below:</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt; a)=20
    digitalSignature: for verifying digital signatures that are</FONT> =
<BR><FONT=20
    size=3D2>used</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp; =
with an=20
    entity authentication service, a data origin</FONT> <BR><FONT=20
    size=3D2>authentication</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt;&nbsp;=20
    service or/and an integrity service;</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt; b)=20
    contentCommitment: for verifying digital signatures which are</FONT> =

    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt; intended</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp; to signal that the signer is committing to =
the=20
    content being</FONT> <BR><FONT size=3D2>signed.</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp; The type of commitment the certificate can be =
used to=20
    support</FONT> <BR><FONT size=3D2>may be</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp; further constrained by the CA, e.g. through a =

    certificate</FONT> <BR><FONT size=3D2>policy.</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp; The precise type of commitment of the signer =
e.g.=20
    "reviewed and</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp; =
approved"=20
    or "with the intent to be bound", may be signalled by</FONT> =
<BR><FONT=20
    size=3D2>the</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp; =
content being=20
    signed, e.g. the signed document itself or some</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt; additional</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp; signed information.</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt;&nbsp; Since a=20
    content commitment signing is considered to be a</FONT> <BR><FONT=20
    size=3D2>digitally</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt; =
signed</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp; transaction, the=20
    digitalSignature bit need not be set in the</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt; certificate.</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp; If it is set, it does not affect the level of =

    commitment the</FONT> <BR><FONT size=3D2>signer</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt; has</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt;&nbsp;=20
    endowed in the signed content.</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt;&nbsp; Note=20
    that it is not incorrect to refer to this keyUsage bit</FONT> =
<BR><FONT=20
    size=3D2>using</FONT> <BR><FONT size=3D2>&gt; the</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp; identifier nonRepudiation. However, the use =
of this=20
    identifier</FONT> <BR><FONT size=3D2>has</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt; been</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt;&nbsp;=20
    deprecated. Regardless of the identifier used, the semantics =
of</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt; this bit</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp; are as specified in this Directory=20
    Specification.</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt;</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt; The text from 3280 is =
copied=20
    below:</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; The =
digitalSignature=20
    bit is asserted when the subject public</FONT> <BR><FONT =
size=3D2>key</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; is =
used with=20
    a digital signature mechanism to support</FONT> <BR><FONT=20
    size=3D2>security</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; services other than =
certificate=20
    signing (bit 5), or CRL</FONT> <BR><FONT size=3D2>signing</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; (bit =
6).&nbsp; Digital=20
    signature mechanisms are often used for</FONT> <BR><FONT=20
    size=3D2>entity</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; authentication and data =
origin=20
    authentication with integrity.</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; The nonRepudiation bit is =
asserted=20
    when the subject public</FONT> <BR><FONT size=3D2>key is</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; used to =
verify digital=20
    signatures used to provide a non-</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; repudiation service which =
protects=20
    against the signing entity</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; falsely denying some =
action,=20
    excluding certificate or CRL</FONT> <BR><FONT size=3D2>&gt; =
signing.</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; In =
the case=20
    of later conflict, a reliable third party may</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; determine the authenticity =
of the=20
    signed data.</FONT> <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Further =
distinctions=20
    between the digitalSignature and</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; nonRepudiation bits may be =
provided=20
    in specific certificate</FONT> <BR><FONT size=3D2>&gt;=20
    &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; policies.</FONT> <BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;&gt;=20
    The text from 3280bis does not align with the ISO-ITU text.</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt;&gt;&gt;&gt; Please align with the the ISO-ITU =
text.</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;&gt;&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&gt;&gt;&gt; Denis</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;&gt;</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;&gt;</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt;</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt;=20
</BLOCKQUOTE><X-SIGSEP>
  <P></X-SIGSEP><BR>Joel S. Kazin CPA, CISA, CISSP, CISM<BR>Senior=20
  Consultant<BR>Atos Origin<BR>40 Old Sleepy Hollow =
Road<BR>Pleasantville, New=20
  York 10570-3802<BR>USA<BR>Phone&nbsp; +1 914-769-8780<BR>Mobile&nbsp; =
+1=20
  914-564-1484<BR>email<X-TAB>&nbsp;&nbsp;&nbsp;</X-TAB>=20
  [email-masked]<BR><A href=3D"http://www.atosorigin.com/"=20
  =
eudora=3D"autourl">www.atosorigin.com<BR></A></FONT></P></BLOCKQUOTE></BO=
DY></HTML>

------=_NextPart_000_0031_01C562A8.F9290510--

Date: Fri, 27 May 2005 09:50:51 -0400
From: "David A. Cooper" <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: 3280bis: key usage (13)
Sender: [email-masked]

Denis,

I do not agree with your proposal for the digitalSignature bit.  Here is 
the current text:

      The digitalSignature bit is asserted when the subject public key
      is used with a digital signature mechanism to support security
      services other than certificate signing (bit 5), or CRL signing
      (bit 6).  Digital signature mechanisms are often used for entity
      authentication and data origin authentication with integrity.

This text merely states that setting the digitalSignature bit, by 
itself, does not authorize relying parties to use the subject public key 
to verify signatures on certificates or CRLs.  It does not prevent a CA 
from setting digitalSignature, keyCertSign, and cRLSign in the same 
certificate.

Imposing this restriction would, for example, prevent a CA from using 
its certificate signing key to also sign OCSP responses.

Denis Pinkas wrote:

> Stephen,
>
> Just before leaving my office in a few minutes for a few days,
> here is a new text proposal for the DS bit:
>
> New proposal for 3280bis:
>
>     The digitalSignature bit is asserted when the subject public key
>     is used for verifying digital signatures that are used
>     with an entity authentication service, a data origin authentication
>     service or/and an integrity service. However, it SHALL not be set
>     when certificate signing (bit 5) or CRL signing (bit 6) is set.
>
> Denis

From: "Kazin, Joel" <[email-masked]>
To: Stefan Santesson <[email-masked]>, Denis Pinkas <[email-masked]>, Stephen Farrell <[email-masked]>
Cc: Hoyt L Kesterson II <[email-masked]>, pkix <[email-masked]>
Subject: RE: 3280bis: key usage (13)
Date: Fri, 27 May 2005 08:19:49 -0500
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.

------_=_NextPart_001_01C562BE.91D1CCE2
Content-Type: text/plain;
	charset="iso-8859-1"

The core problem is labeling the bit non-repudiation.  It goes against the
legal idea that you can attempt to repudiate your alleged actions even when
your defense is weaker than "the cat ate my homework".  To me,
non-repudiation is more of a marketing description than a technical,
contractual, or legal description of what the signer intended to do.  

A secondary problem is that the non-repudiation bit doesn't tell a relying
party or third party enough.  The logical place to look for such information
is in the id-ce-certificatePolicies extension.  Was the
id-ce-certificatePolicies extension part of the original x.509 v1
specification?  If that is true, then perhaps the non-repudiation bit is
just a holdover from the original x.509 v1 certificate definition?  If my
arguments are true then we can: 1) keep calling it non-repudiation and
strongly deprecate its use, 2) change the name and deprecate its use, 3)
change the name and allow its use. I favor 1 over 2 over 3.  

At 07:06 AM 5/27/2005 -0500, Stefan Santesson wrote:

Speaking as implementer and not design team member, I can live with both 
texts since they allow me to do the same thing. 

It allows my low level application to add a digital signature supported 
by the digital signature bit, where the intention of that application is 
to add integrity and origin authentication, while the use of the 
signature in practice (higher layers) ends up being used as evidence of 
some kind of commitment. 

Example. An e-mail application adds an arbitrary signature supported by 
the DS bit, while the body of the text reads "Through the digital 
signature on this e-mail I commit to....). This is now a perfectly valid 
scenario according to both texts. 

The real defect that was fixed was that the digital signature bit said 
that it was for purposes "other" than NR. That is now gone in both 
standards. 

I agree to Stephen's rationale to keep the name nonRepudiation. It is 
not worth the cost to change the name. Stephen's point here was missing 
in the X.509 discussions of a name change. 

Stefan Santesson 
Program Manager, Standards Liaison 
Windows Security 

> From: [email-masked] 
[mailto:[email-masked] <mailto:[email-masked]> ]

> On Behalf Of Denis Pinkas 
> Sent: den 27 maj 2005 12:29 
> To: Stephen Farrell 
> Cc: Hoyt L Kesterson II; pkix 
> Subject: Re: 3280bis: key usage (13) 
> 
> 
> Stephen, 
> 
> I agree with everything Hoyt said on bit 1. 
> 
> However, there are two sides for this coin : bit 0 and bit 1. 
> 
> Both are again copied below: 
> 
> ISO Corrigendum: 
> 
>      a) digitalSignature: for verifying digital signatures that are 
used 
>         with an entity authentication service, a data origin 
> authentication 
>         service or/and an integrity service; 
> 
> 3280bis: 
> 
>      The digitalSignature bit is asserted when the subject public key 
>      is used with a digital signature mechanism to support security 
>      services other than certificate signing (bit 5), or CRL signing 
>      (bit 6).  Digital signature mechanisms are often used for entity 
>      authentication and data origin authentication with integrity. 
> 
> The current text of 3280bis for bit 0 (ds) is incompatible with the 
ISO 
> Corrigendum. 
> 
> As Hoyt already said, any new text should align with the definition in 
the 
> approved technical corrigenda against the 4th edition and in the 
upcoming 
> 5th edition. 
> 
> Denis 
> 
> > Hi Hoyt, 
> > 
> > Hoyt L Kesterson II wrote: 
> > 
> >> Stephen 
> >> 
> >> I am somewhat dismayed at your reaction to the new text in X.509. 
> > 
> > 
> > I'm sorry about that, but I guess I'm just fed up with the 
> > NR bit, though I can understand how people who've worked 
> > hard to try fix it might be dismayed. 
> > 
> > (BTW: I once suggested that CAs MUST set this bit randomly 
> > since that was the only way I could see to kill it off 
> > properly. If you can get that into X.509 then I'd be happy 
> > for 3280bis to align:-) 
> > 
> >  > I am not going to argue with you here (maybe in a bar the next 
time 
> >  > we run into each other). 
> > 
> > Good idea! 
> > 
> >> However, I do want to mention several points. 
> >> 
> >> 1) I initiated the change in text because of the various 
> interpretations 
> > 
> >  > by implementors that were resulting in non-interoperable 
> >  > implementations. It was a conversation with a PKIXer at a RSA 
> >  > conference a few years ago that caused me to articulate a private 
> >  > concern. 
> > 
> > I agree that everything connected with this bit has been 
> > confused and remains so. 
> > 
> >> 2) The legal community was very confused. There was even a 
> > 
> >  > paper castigating the standard developers for mandating that 
> >  > one could not repudiate an action. 
> > 
> > Maybe the mistake was defining a bit that laywers care about? 
> > 
> >> 3) There were several meetings held where there was significant 
> > 
> >  > participation by people in the IETF PKIX group (as well as 
> >  > lawyers). All agreed there was a problem with the published text. 
> >  > Denis and I argued long and hard over wording but we didn't 
> >  > disagree on the need for new text and its general intent. 
> > 
> > Fair enough. 
> > 
> >> 4) Russ was concerned that change would cause a problem 
> > 
> >  > with existing IETF standards and was not too happy with a 
> >  > change to the name of the bit. That's why I put the line 
> >  > in that you referenced. However, that was to grandfather 
> >  > existing text, not to allow new text to continue using 
> >  > the old term and definitions. 
> > 
> > Ok. Here's the real reason not to change: Many people use 
> > ASN.1 compilers which means that names from the ASN.1 
> > module end up being directly used in higher layer code. 
> > Changing the name causes that code not to compile. I'd 
> > say that there's quite a lot of 3280 code in the world 
> > at this stage. So, if the semantics isn't supposed to 
> > have changed (and I assume that is meant to be the 
> > case) then this cost just doesn't seem worthwhile. 
> > 
> >> 5) It is the definition that is important. I recommend 
> > 
> >  > that any new text align with the definition in the approved 
> >  > technical corrigenda against the 4th edition and in 
> >  > the upcoming 5th edition. 
> > 
> > While I'd rather not see any more text added on this, 
> > (there's been way too much already) I wouldn't have a big 
> > issue with trying to help a reader make sense of the 
> > fact that 3280bis and x.509 name this bit differently. 
> > 
> > However text like the sentence below is IMO almost 
> > certain to cause even more confusion: 
> > 
> >   The precise type of commitment of the signer e.g. "reviewed 
> >   and approved" or "with the intent to be bound", may be 
> >   signalled by the content being signed, e.g. the signed 
> >   document itself or some additional signed information. 
> > 
> > That sounds like the sole purpose of the CC-bit is as 
> > a flag to indicate when some other bits somewhere else 
> > tell you what the CC-bit means. 
> > 
> > So in the absence of some better text I think that 3280bis 
> > is better off just saying "NR a.k.a. CC" as it currently 
> > does. 
> > 
> > Regards, 
> > Stephen. 
> > 
> >> 
> >> At 14:49 +0100 5/26/05, Stephen Farrell wrote: 
> >> 
> >>> Denis, 
> >>> 
> >>> 
> >>>> Please align with the the ISO-ITU text. 
> >>> 
> >>> 
> >>> Do you mean we should rename the bits and include the 
> >>> other new x.509 text? The design team were against 
> >>> doing that. 
> >>> 
> >>> Is there any (good) reason other than alignment to 
> >>> make such a change? 
> >>> 
> >>> Personally, I find the new x.509 text worse, although 
> >>> it does say: "Note that it is not incorrect to refer to 
> >>> this keyUsage bit using the identifier nonRepudiation." 
> >>> So I can argue that we are aligned, just not identical. 
> >>> 
> >>> But of course, I'm from the non-repudiation is non-sense 
> >>> camp so I may not be the best judge. 
> >>> 
> >>> Stephen. 
> >>> 
> >>> PS: A quibble: 
> >>> 
> >>> 
> >>>>  The new text in X.509 aligns with the text in RFC 3280.  No 
changes 
> >>>>  are required to 3280bis.  A comment has been added to the ASN.1 
for 
> >>>>  KeyUsage stating that "recent editions of X.509 have renamed 
> >>>>  [the nonRepudiation] bit to contentCommitment" 
> >>>> 
> >>>> This statement is untrue. 
> >>> 
> >>> 
> >>> The paragraph to which I assume you refer contains 3 
> >>> statements - it'd be easier to close these threads if 
> >>> you were more precise. (I think I got what you want 
> >>> by the end of the mail though...) 
> >>> 
> >>> PPS: "This statement is untrue." 
> >>>    Are you from Crete after all? :-) 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> Denis Pinkas wrote: 
> >>> 
> >>> 
> >>>> To the list, 
> >>>> 
> >>>> The disposition of comments states: 
> >>>> 
> >>>> 13) The descriptions of the meanings of the digitalSignature and 
> >>>>    nonRepudiation bits of keyUsage may need to be adjusted based 
> >>>>    on the work in X.509 
> >>>> 
> >>>> The new text in X.509 aligns with the text in RFC 3280.  No 
changes 
> >>>> are required to 3280bis.  A comment has been added to the ASN.1 
for 
> >>>> KeyUsage stating that "recent editions of X.509 have renamed 
> >>>> [the nonRepudiation] bit to contentCommitment" 
> >>>> 
> >>>> This statement is untrue. 
> >>>> 
> >>>> The text from X.509 has been published in Corrigendum 3 (04/2004) 
> >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called 
> >>>> 
> >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). 
> >>>> 
> >>>> An extract from this text is copied below: 
> >>>> 
> >>>> a) digitalSignature: for verifying digital signatures that are 
used 
> >>>>  with an entity authentication service, a data origin 
authentication 
> >>>>  service or/and an integrity service; 
> >>>> 
> >>>> b) contentCommitment: for verifying digital signatures which are 
> >>>> intended 
> >>>>  to signal that the signer is committing to the content being 
signed. 
> >>>>  The type of commitment the certificate can be used to support 
may be 
> >>>>  further constrained by the CA, e.g. through a certificate 
policy. 
> >>>>  The precise type of commitment of the signer e.g. "reviewed and 
> >>>>  approved" or "with the intent to be bound", may be signalled by 
the 
> >>>>  content being signed, e.g. the signed document itself or some 
> >>>> additional 
> >>>>  signed information. 
> >>>> 
> >>>>  Since a content commitment signing is considered to be a 
digitally 
> >>>> signed 
> >>>>  transaction, the digitalSignature bit need not be set in the 
> >>>> certificate. 
> >>>>  If it is set, it does not affect the level of commitment the 
signer 
> >>>> has 
> >>>>  endowed in the signed content. 
> >>>> 
> >>>>  Note that it is not incorrect to refer to this keyUsage bit 
using 
> the 
> >>>>  identifier nonRepudiation. However, the use of this identifier 
has 
> >>>> been 
> >>>>  deprecated. Regardless of the identifier used, the semantics of 
> >>>> this bit 
> >>>>  are as specified in this Directory Specification. 
> >>>> 
> >>>> The text from 3280 is copied below: 
> >>>> 
> >>>>     The digitalSignature bit is asserted when the subject public 
key 
> >>>>     is used with a digital signature mechanism to support 
security 
> >>>>     services other than certificate signing (bit 5), or CRL 
signing 
> >>>>     (bit 6).  Digital signature mechanisms are often used for 
entity 
> >>>>     authentication and data origin authentication with integrity. 
> >>>> 
> >>>>     The nonRepudiation bit is asserted when the subject public 
key is 
> >>>>     used to verify digital signatures used to provide a non- 
> >>>>     repudiation service which protects against the signing entity 
> >>>>     falsely denying some action, excluding certificate or CRL 
> signing. 
> >>>>     In the case of later conflict, a reliable third party may 
> >>>>     determine the authenticity of the signed data. 
> >>>> 
> >>>>     Further distinctions between the digitalSignature and 
> >>>>     nonRepudiation bits may be provided in specific certificate 
> >>>>     policies. 
> >>>> 
> >>>> The text from 3280bis does not align with the ISO-ITU text. 
> >>>> Please align with the the ISO-ITU text. 
> >>>> 
> >>>> Denis 
> >>> 
> >> 
> >> 
> >> 
> > 
> > 
> 

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com <http://www.atosorigin.com/> 

------_=_NextPart_001_01C562BE.91D1CCE2
Content-Type: text/html;
	charset="iso-8859-1"

<html>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
The core problem is labeling the bit non-repudiation.&nbsp; It goes
against the legal idea that you can attempt to repudiate your alleged
actions even when your defense is weaker than &quot;the cat ate my
homework&quot;.&nbsp; To me, non-repudiation is more of a marketing
description than a technical, contractual, or legal description of what
the signer intended to do.&nbsp; <br><br>
A secondary problem is that the non-repudiation bit doesn't tell a
relying party or third party enough.&nbsp; The logical place to look for
such information is in the id-ce-certificatePolicies extension.&nbsp; Was
the id-ce-certificatePolicies extension part of the original x.509 v1
specification?&nbsp; If that is true, then perhaps the non-repudiation
bit is just a holdover from the original x.509 v1 certificate
definition?&nbsp; If my arguments are true then we can: 1) keep calling
it non-repudiation and strongly deprecate its use, 2) change the name and
deprecate its use, 3) change the name and allow its use.  I favor 1 over
2 over 3.&nbsp; <br><br>
<br>
At 07:06 AM 5/27/2005 -0500, Stefan Santesson wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>Speaking as
implementer and not design team member, I can live with both</font> 
<br>
<font size=2>texts since they allow me to do the same thing.</font>
<br><br>
<font size=2>It allows my low level application to add a digital signature supported</font> <br>
<font size=2>by the digital signature bit, where the intention of that application is</font> <br>
<font size=2>to add integrity and origin authentication, while the use of the</font> <br>
<font size=2>signature in practice (higher layers) ends up being used as evidence of</font> <br>
<font size=2>some kind of commitment.</font> <br><br>
<font size=2>Example. An e-mail application adds an arbitrary signature supported by</font> <br>
<font size=2>the DS bit, while the body of the text reads &quot;Through the digital</font> <br>
<font size=2>signature on this e-mail I commit to....). This is now a perfectly valid</font> <br>
<font size=2>scenario according to both texts.</font> <br><br>
<font size=2>The real defect that was fixed was that the digital signature bit said</font> <br>
<font size=2>that it was for purposes &quot;other&quot; than NR. That is now gone in both</font> <br>
<font size=2>standards.</font> <br><br>
<font size=2>I agree to Stephen's rationale to keep the name nonRepudiation. It is</font> <br>
<font size=2>not worth the cost to change the name. Stephen's point here was missing</font> <br>
<font size=2>in the X.509 discussions of a name change.</font> <br><br>
<font size=2>Stefan Santesson</font> <br>
<font size=2>Program Manager, Standards Liaison</font> <br>
<font size=2>Windows Security</font> <br>
<font size=2>&nbsp;</font> <br><br>
<font size=2>&gt; -----Original Message-----</font> <br>
<font size=2>&gt; From: [email-masked]</font> <br>
<font size=2>[<a href="mailto:[email-masked]">mailto:[email-masked]</a>]</font> <br>
<font size=2>&gt; On Behalf Of Denis Pinkas</font> <br>
<font size=2>&gt; Sent: den 27 maj 2005 12:29</font> <br>
<font size=2>&gt; To: Stephen Farrell</font> <br>
<font size=2>&gt; Cc: Hoyt L Kesterson II; pkix</font> <br>
<font size=2>&gt; Subject: Re: 3280bis: key usage (13)</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; </font><br>
<font size=2>&gt; Stephen,</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; I agree with everything Hoyt said on bit 1.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; However, there are two sides for this coin : bit 0 and bit 1.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; Both are again copied below:</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; ISO Corrigendum:</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) digitalSignature: for verifying digital signatures that are</font> <br>
<font size=2>used</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with an entity authentication service, a data origin</font> <br>
<font size=2>&gt; authentication</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; service or/and an integrity service;</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; 3280bis:</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The digitalSignature bit is asserted when the subject public key</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is used with a digital signature mechanism to support security</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; services other than certificate signing (bit 5), or CRL signing</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (bit 6).&nbsp; Digital signature mechanisms are often used for entity</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authentication and data origin authentication with integrity.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; The current text of 3280bis for bit 0 (ds) is incompatible with the</font> <br>
<font size=2>ISO</font> <br>
<font size=2>&gt; Corrigendum.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; As Hoyt already said, any new text should align with the definition in</font> <br>
<font size=2>the</font> <br>
<font size=2>&gt; approved technical corrigenda against the 4th edition and in the</font> <br>
<font size=2>upcoming</font> <br>
<font size=2>&gt; 5th edition.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; Denis</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt; &gt; Hi Hoyt,</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; Hoyt L Kesterson II wrote:</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&gt; Stephen</font> <br>
<font size=2>&gt; &gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt; I am somewhat dismayed at your reaction to the new text in X.509.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; I'm sorry about that, but I guess I'm just fed up with the</font> <br>
<font size=2>&gt; &gt; NR bit, though I can understand how people who've worked</font> <br>
<font size=2>&gt; &gt; hard to try fix it might be dismayed.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; (BTW: I once suggested that CAs MUST set this bit randomly</font> <br>
<font size=2>&gt; &gt; since that was the only way I could see to kill it off</font> <br>
<font size=2>&gt; &gt; properly. If you can get that into X.509 then I'd be happy</font> <br>
<font size=2>&gt; &gt; for 3280bis to align:-)</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; I am not going to argue with you here (maybe in a bar the next</font> <br>
<font size=2>time</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; we run into each other).</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; Good idea!</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&gt; However, I do want to mention several points.</font> <br>
<font size=2>&gt; &gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt; 1) I initiated the change in text because of the various</font> <br>
<font size=2>&gt; interpretations</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; by implementors that were resulting in non-interoperable</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; implementations. It was a conversation with a PKIXer at a RSA</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; conference a few years ago that caused me to articulate a private</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; concern.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; I agree that everything connected with this bit has been</font> <br>
<font size=2>&gt; &gt; confused and remains so.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&gt; 2) The legal community was very confused. There was even a</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; paper castigating the standard developers for mandating that</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; one could not repudiate an action.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; Maybe the mistake was defining a bit that laywers care about?</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&gt; 3) There were several meetings held where there was significant</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; participation by people in the IETF PKIX group (as well as</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; lawyers). All agreed there was a problem with the published text.</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; Denis and I argued long and hard over wording but we didn't</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; disagree on the need for new text and its general intent.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; Fair enough.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&gt; 4) Russ was concerned that change would cause a problem</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; with existing IETF standards and was not too happy with a</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; change to the name of the bit. That's why I put the line</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; in that you referenced. However, that was to grandfather</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; existing text, not to allow new text to continue using</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; the old term and definitions.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; Ok. Here's the real reason not to change: Many people use</font> <br>
<font size=2>&gt; &gt; ASN.1 compilers which means that names from the ASN.1</font> <br>
<font size=2>&gt; &gt; module end up being directly used in higher layer code.</font> <br>
<font size=2>&gt; &gt; Changing the name causes that code not to compile. I'd</font> <br>
<font size=2>&gt; &gt; say that there's quite a lot of 3280 code in the world</font> <br>
<font size=2>&gt; &gt; at this stage. So, if the semantics isn't supposed to</font> <br>
<font size=2>&gt; &gt; have changed (and I assume that is meant to be the</font> <br>
<font size=2>&gt; &gt; case) then this cost just doesn't seem worthwhile.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&gt; 5) It is the definition that is important. I recommend</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; that any new text align with the definition in the approved</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; technical corrigenda against the 4th edition and in</font> <br>
<font size=2>&gt; &gt;&nbsp; &gt; the upcoming 5th edition.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; While I'd rather not see any more text added on this,</font> <br>
<font size=2>&gt; &gt; (there's been way too much already) I wouldn't have a big</font> <br>
<font size=2>&gt; &gt; issue with trying to help a reader make sense of the</font> <br>
<font size=2>&gt; &gt; fact that 3280bis and x.509 name this bit differently.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; However text like the sentence below is IMO almost</font> <br>
<font size=2>&gt; &gt; certain to cause even more confusion:</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&nbsp;&nbsp; The precise type of commitment of the signer e.g. &quot;reviewed</font> <br>
<font size=2>&gt; &gt;&nbsp;&nbsp; and approved&quot; or &quot;with the intent to be bound&quot;, may be</font> <br>
<font size=2>&gt; &gt;&nbsp;&nbsp; signalled by the content being signed, e.g. the signed</font> <br>
<font size=2>&gt; &gt;&nbsp;&nbsp; document itself or some additional signed information.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; That sounds like the sole purpose of the CC-bit is as</font> <br>
<font size=2>&gt; &gt; a flag to indicate when some other bits somewhere else</font> <br>
<font size=2>&gt; &gt; tell you what the CC-bit means.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; So in the absence of some better text I think that 3280bis</font> <br>
<font size=2>&gt; &gt; is better off just saying &quot;NR a.k.a. CC&quot; as it currently</font> <br>
<font size=2>&gt; &gt; does.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt; Regards,</font> <br>
<font size=2>&gt; &gt; Stephen.</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt; At 14:49 +0100 5/26/05, Stephen Farrell wrote:</font> <br>
<font size=2>&gt; &gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt; Denis,</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; Please align with the the ISO-ITU text.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt; Do you mean we should rename the bits and include the</font> <br>
<font size=2>&gt; &gt;&gt;&gt; other new x.509 text? The design team were against</font> <br>
<font size=2>&gt; &gt;&gt;&gt; doing that.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt; Is there any (good) reason other than alignment to</font> <br>
<font size=2>&gt; &gt;&gt;&gt; make such a change?</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt; Personally, I find the new x.509 text worse, although</font> <br>
<font size=2>&gt; &gt;&gt;&gt; it does say: &quot;Note that it is not incorrect to refer to</font> <br>
<font size=2>&gt; &gt;&gt;&gt; this keyUsage bit using the identifier nonRepudiation.&quot;</font> <br>
<font size=2>&gt; &gt;&gt;&gt; So I can argue that we are aligned, just not identical.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt; But of course, I'm from the non-repudiation is non-sense</font> <br>
<font size=2>&gt; &gt;&gt;&gt; camp so I may not be the best judge.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt; Stephen.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt; PS: A quibble:</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; The new text in X.509 aligns with the text in RFC 3280.&nbsp; No</font> <br>
<font size=2>changes</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; are required to 3280bis.&nbsp; A comment has been added to the ASN.1</font> <br>
<font size=2>for</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; KeyUsage stating that &quot;recent editions of X.509 have renamed</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; [the nonRepudiation] bit to contentCommitment&quot;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; This statement is untrue.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt; The paragraph to which I assume you refer contains 3</font> <br>
<font size=2>&gt; &gt;&gt;&gt; statements - it'd be easier to close these threads if</font> <br>
<font size=2>&gt; &gt;&gt;&gt; you were more precise. (I think I got what you want</font> <br>
<font size=2>&gt; &gt;&gt;&gt; by the end of the mail though...)</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt; PPS: &quot;This statement is untrue.&quot;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp; Are you from Crete after all? :-)</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt; Denis Pinkas wrote:</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; To the list,</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; The disposition of comments states:</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; 13) The descriptions of the meanings of the digitalSignature and</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; nonRepudiation bits of keyUsage may need to be adjusted based</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp; on the work in X.509</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; The new text in X.509 aligns with the text in RFC 3280.&nbsp; No</font> <br>
<font size=2>changes</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; are required to 3280bis.&nbsp; A comment has been added to the ASN.1</font> <br>
<font size=2>for</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; KeyUsage stating that &quot;recent editions of X.509 have renamed</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; [the nonRepudiation] bit to contentCommitment&quot;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; This statement is untrue.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; The text from X.509 has been published in Corrigendum 3 (04/2004)</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; An extract from this text is copied below:</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; a) digitalSignature: for verifying digital signatures that are</font> <br>
<font size=2>used</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; with an entity authentication service, a data origin</font> <br>
<font size=2>authentication</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; service or/and an integrity service;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; b) contentCommitment: for verifying digital signatures which are</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; intended</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; to signal that the signer is committing to the content being</font> <br>
<font size=2>signed.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; The type of commitment the certificate can be used to support</font> <br>
<font size=2>may be</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; further constrained by the CA, e.g. through a certificate</font> <br>
<font size=2>policy.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; The precise type of commitment of the signer e.g. &quot;reviewed and</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; approved&quot; or &quot;with the intent to be bound&quot;, may be signalled by</font> <br>
<font size=2>the</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; content being signed, e.g. the signed document itself or some</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; additional</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; signed information.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; Since a content commitment signing is considered to be a</font> <br>
<font size=2>digitally</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; signed</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; transaction, the digitalSignature bit need not be set in the</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; certificate.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; If it is set, it does not affect the level of commitment the</font> <br>
<font size=2>signer</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; has</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; endowed in the signed content.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; Note that it is not incorrect to refer to this keyUsage bit</font> <br>
<font size=2>using</font> <br>
<font size=2>&gt; the</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; identifier nonRepudiation. However, the use of this identifier</font> <br>
<font size=2>has</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; been</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; deprecated. Regardless of the identifier used, the semantics of</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; this bit</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp; are as specified in this Directory Specification.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; The text from 3280 is copied below:</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; The digitalSignature bit is asserted when the subject public</font> <br>
<font size=2>key</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; is used with a digital signature mechanism to support</font> <br>
<font size=2>security</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; services other than certificate signing (bit 5), or CRL</font> <br>
<font size=2>signing</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; (bit 6).&nbsp; Digital signature mechanisms are often used for</font> <br>
<font size=2>entity</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; authentication and data origin authentication with integrity.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; The nonRepudiation bit is asserted when the subject public</font> <br>
<font size=2>key is</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; used to verify digital signatures used to provide a non-</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; repudiation service which protects against the signing entity</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; falsely denying some action, excluding certificate or CRL</font> <br>
<font size=2>&gt; signing.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; In the case of later conflict, a reliable third party may</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; determine the authenticity of the signed data.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Further distinctions between the digitalSignature and</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; nonRepudiation bits may be provided in specific certificate</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; policies.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; The text from 3280bis does not align with the ISO-ITU text.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; Please align with the the ISO-ITU text.</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;&gt;&gt; Denis</font> <br>
<font size=2>&gt; &gt;&gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;</font> <br>
<font size=2>&gt; &gt;&gt;</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; &gt;</font> <br>
<font size=2>&gt; </blockquote>
<x-sigsep><p></x-sigsep>
<br>
Joel S. Kazin CPA, CISA, CISSP, CISM<br>
Senior Consultant<br>
Atos Origin<br>
40 Old Sleepy Hollow Road<br>
Pleasantville, New York 10570-3802<br>
USA<br>
Phone&nbsp; +1 914-769-8780<br>
Mobile&nbsp; +1 914-564-1484<br>
email<x-tab>&nbsp;&nbsp;&nbsp;</x-tab> [email-masked]<br>
<a href="http://www.atosorigin.com/" eudora="autourl">www.atosorigin.com<br>
</a></font></html>

------_=_NextPart_001_01C562BE.91D1CCE2--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: 3280bis: key usage (13)
Cc: [email-masked]
Date: Sat, 28 May 2005 01:16:43 +1200
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>The digitalSignature bit is asserted when the subject public key is used for
>verifying digital signatures that are used with an entity authentication
>service, a data origin authentication service or/and an integrity service.

Wouldn't it be better to say that it's used for purposes other than CC?  By
saying that DS can only be used for purposes A, B, and C, and CC for purpose
D, what happens if someone wants to mark a key for purpose E?  Since CC seems
to be the more restrictive, it would be better to say that DS is to be used
for everything else.  If not, we'd need a third signature bit to cover the
'other' category that's explicitly excluded from DS and CC.

>However, it SHALL not be set when certificate signing (bit 5) or CRL signing
>(bit 6) is set.

Why not?  The intent of the original text was to say that digitalSignature
doesn't mean you can use the cert for cert/CRL signing, now it says something
completely different, that a cert-signing cert can never be used for any other
purpose.  This wording change would make a number of CAs non-compliant, since
they do use their CA certs for other purposes (don't ask me why, I just see
the things turn up from time to time).  The wording should be something like
"Setting this bit doesn't mean the cert can be used for cert or CRL signing;
for that, you need to set the cert/CRL signing bits".

(I realise this stuff should be obvious to anyone, but there are going to be
 CAs and vendors out there who defend their buggy software by interpreting the
 text as literally as possible, so it had better not contain any loopholes).

Peter.

Date: Fri, 27 May 2005 13:39:51 +0100
From: Stephen Farrell <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: 3280bis: key usage (13)
Sender: [email-masked]

Denis,

Fine by me.

Have a nice trip,
Stephen.

Denis Pinkas wrote:

> Stephen,
> 
> Just before leaving my office in a few minutes for a few days,
> here is a new text proposal for the DS bit:
> 
> New proposal for 3280bis:
> 
>     The digitalSignature bit is asserted when the subject public key
>     is used for verifying digital signatures that are used
>     with an entity authentication service, a data origin authentication
>     service or/and an integrity service. However, it SHALL not be set
>     when certificate signing (bit 5) or CRL signing (bit 6) is set.
> 
> Denis
> 
>> Hi Denis,
>>
>> I've no problem with aligning the DS bit text although I
>> wouldn't say that they're incompatible actually. I like
>> the way 3280 says the DS isn't for certs or CRLs which
>> ISO doesn't seem to include. Would you like to propose
>> an aligned paragraph?
>>
>> I oppose inclusion of new NR/CC text and the name change.
>>
>> Stephen.
>>
>> Denis Pinkas wrote:
>>
>>> Stephen,
>>>
>>> I agree with everything Hoyt said on bit 1.
>>>
>>> However, there are two sides for this coin : bit 0 and bit 1.
>>>
>>> Both are again copied below:
>>>
>>> ISO Corrigendum:
>>>
>>>     a) digitalSignature: for verifying digital signatures that are used
>>>        with an entity authentication service, a data origin 
>>> authentication
>>>        service or/and an integrity service;
>>>
>>> 3280bis:
>>>
>>>     The digitalSignature bit is asserted when the subject public key
>>>     is used with a digital signature mechanism to support security
>>>     services other than certificate signing (bit 5), or CRL signing
>>>     (bit 6).  Digital signature mechanisms are often used for entity
>>>     authentication and data origin authentication with integrity.
>>>
>>> The current text of 3280bis for bit 0 (ds) is incompatible with the ISO
>>> Corrigendum.
>>>
>>> As Hoyt already said, any new text should align with the definition 
>>> in the approved technical corrigenda against the 4th edition and in 
>>> the upcoming 5th edition.
>>>
>>> Denis
>>>
>>>> Hi Hoyt,
>>>>
>>>> Hoyt L Kesterson II wrote:
>>>>
>>>>> Stephen
>>>>>
>>>>> I am somewhat dismayed at your reaction to the new text in X.509. 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I'm sorry about that, but I guess I'm just fed up with the
>>>> NR bit, though I can understand how people who've worked
>>>> hard to try fix it might be dismayed.
>>>>
>>>> (BTW: I once suggested that CAs MUST set this bit randomly
>>>> since that was the only way I could see to kill it off
>>>> properly. If you can get that into X.509 then I'd be happy
>>>> for 3280bis to align:-)
>>>>
>>>>  > I am not going to argue with you here (maybe in a bar the next time
>>>>  > we run into each other).
>>>>
>>>> Good idea!
>>>>
>>>>> However, I do want to mention several points.
>>>>>
>>>>> 1) I initiated the change in text because of the various 
>>>>> interpretations 
>>>>
>>>>
>>>>
>>>>
>>>>  > by implementors that were resulting in non-interoperable
>>>>  > implementations. It was a conversation with a PKIXer at a RSA
>>>>  > conference a few years ago that caused me to articulate a private
>>>>  > concern.
>>>>
>>>> I agree that everything connected with this bit has been
>>>> confused and remains so.
>>>>
>>>>> 2) The legal community was very confused. There was even a 
>>>>
>>>>
>>>>
>>>>
>>>>  > paper castigating the standard developers for mandating that
>>>>  > one could not repudiate an action.
>>>>
>>>> Maybe the mistake was defining a bit that laywers care about?
>>>>
>>>>> 3) There were several meetings held where there was significant 
>>>>
>>>>
>>>>
>>>>
>>>>  > participation by people in the IETF PKIX group (as well as
>>>>  > lawyers). All agreed there was a problem with the published text.
>>>>  > Denis and I argued long and hard over wording but we didn't
>>>>  > disagree on the need for new text and its general intent.
>>>>
>>>> Fair enough.
>>>>
>>>>> 4) Russ was concerned that change would cause a problem 
>>>>
>>>>
>>>>
>>>>
>>>>  > with existing IETF standards and was not too happy with a
>>>>  > change to the name of the bit. That's why I put the line
>>>>  > in that you referenced. However, that was to grandfather
>>>>  > existing text, not to allow new text to continue using
>>>>  > the old term and definitions.
>>>>
>>>> Ok. Here's the real reason not to change: Many people use
>>>> ASN.1 compilers which means that names from the ASN.1
>>>> module end up being directly used in higher layer code.
>>>> Changing the name causes that code not to compile. I'd
>>>> say that there's quite a lot of 3280 code in the world
>>>> at this stage. So, if the semantics isn't supposed to
>>>> have changed (and I assume that is meant to be the
>>>> case) then this cost just doesn't seem worthwhile.
>>>>
>>>>> 5) It is the definition that is important. I recommend 
>>>>
>>>>
>>>>
>>>>
>>>>  > that any new text align with the definition in the approved
>>>>  > technical corrigenda against the 4th edition and in
>>>>  > the upcoming 5th edition.
>>>>
>>>> While I'd rather not see any more text added on this,
>>>> (there's been way too much already) I wouldn't have a big
>>>> issue with trying to help a reader make sense of the
>>>> fact that 3280bis and x.509 name this bit differently.
>>>>
>>>> However text like the sentence below is IMO almost
>>>> certain to cause even more confusion:
>>>>
>>>>   The precise type of commitment of the signer e.g. "reviewed
>>>>   and approved" or "with the intent to be bound", may be
>>>>   signalled by the content being signed, e.g. the signed
>>>>   document itself or some additional signed information.
>>>>
>>>> That sounds like the sole purpose of the CC-bit is as
>>>> a flag to indicate when some other bits somewhere else
>>>> tell you what the CC-bit means.
>>>>
>>>> So in the absence of some better text I think that 3280bis
>>>> is better off just saying "NR a.k.a. CC" as it currently
>>>> does.
>>>>
>>>> Regards,
>>>> Stephen.
>>>>
>>>>>
>>>>> At 14:49 +0100 5/26/05, Stephen Farrell wrote:
>>>>>
>>>>>> Denis,
>>>>>>
>>>>>>
>>>>>>> Please align with the the ISO-ITU text.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Do you mean we should rename the bits and include the
>>>>>> other new x.509 text? The design team were against
>>>>>> doing that.
>>>>>>
>>>>>> Is there any (good) reason other than alignment to
>>>>>> make such a change?
>>>>>>
>>>>>> Personally, I find the new x.509 text worse, although
>>>>>> it does say: "Note that it is not incorrect to refer to
>>>>>> this keyUsage bit using the identifier nonRepudiation."
>>>>>> So I can argue that we are aligned, just not identical.
>>>>>>
>>>>>> But of course, I'm from the non-repudiation is non-sense
>>>>>> camp so I may not be the best judge.
>>>>>>
>>>>>> Stephen.
>>>>>>
>>>>>> PS: A quibble:
>>>>>>
>>>>>>
>>>>>>>  The new text in X.509 aligns with the text in RFC 3280.  No changes
>>>>>>>  are required to 3280bis.  A comment has been added to the ASN.1 for
>>>>>>>  KeyUsage stating that "recent editions of X.509 have renamed
>>>>>>>  [the nonRepudiation] bit to contentCommitment"
>>>>>>>
>>>>>>> This statement is untrue.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The paragraph to which I assume you refer contains 3
>>>>>> statements - it'd be easier to close these threads if
>>>>>> you were more precise. (I think I got what you want
>>>>>> by the end of the mail though...)
>>>>>>
>>>>>> PPS: "This statement is untrue."
>>>>>>    Are you from Crete after all? :-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Denis Pinkas wrote:
>>>>>>
>>>>>>
>>>>>>> To the list,
>>>>>>>
>>>>>>> The disposition of comments states:
>>>>>>>
>>>>>>> 13) The descriptions of the meanings of the digitalSignature and
>>>>>>>    nonRepudiation bits of keyUsage may need to be adjusted based
>>>>>>>    on the work in X.509
>>>>>>>
>>>>>>> The new text in X.509 aligns with the text in RFC 3280.  No changes
>>>>>>> are required to 3280bis.  A comment has been added to the ASN.1 for
>>>>>>> KeyUsage stating that "recent editions of X.509 have renamed
>>>>>>> [the nonRepudiation] bit to contentCommitment"
>>>>>>>
>>>>>>> This statement is untrue.
>>>>>>>
>>>>>>> The text from X.509 has been published in Corrigendum 3 (04/2004)
>>>>>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
>>>>>>>
>>>>>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).
>>>>>>>
>>>>>>> An extract from this text is copied below:
>>>>>>>
>>>>>>> a) digitalSignature: for verifying digital signatures that are used
>>>>>>>  with an entity authentication service, a data origin authentication
>>>>>>>  service or/and an integrity service;
>>>>>>>
>>>>>>> b) contentCommitment: for verifying digital signatures which are 
>>>>>>> intended
>>>>>>>  to signal that the signer is committing to the content being 
>>>>>>> signed.
>>>>>>>  The type of commitment the certificate can be used to support 
>>>>>>> may be
>>>>>>>  further constrained by the CA, e.g. through a certificate policy.
>>>>>>>  The precise type of commitment of the signer e.g. "reviewed and
>>>>>>>  approved" or "with the intent to be bound", may be signalled by the
>>>>>>>  content being signed, e.g. the signed document itself or some 
>>>>>>> additional
>>>>>>>  signed information.
>>>>>>>
>>>>>>>  Since a content commitment signing is considered to be a 
>>>>>>> digitally signed
>>>>>>>  transaction, the digitalSignature bit need not be set in the 
>>>>>>> certificate.
>>>>>>>  If it is set, it does not affect the level of commitment the 
>>>>>>> signer has
>>>>>>>  endowed in the signed content.
>>>>>>>
>>>>>>>  Note that it is not incorrect to refer to this keyUsage bit 
>>>>>>> using the
>>>>>>>  identifier nonRepudiation. However, the use of this identifier 
>>>>>>> has been
>>>>>>>  deprecated. Regardless of the identifier used, the semantics of 
>>>>>>> this bit
>>>>>>>  are as specified in this Directory Specification.
>>>>>>>
>>>>>>> The text from 3280 is copied below:
>>>>>>>
>>>>>>>     The digitalSignature bit is asserted when the subject public key
>>>>>>>     is used with a digital signature mechanism to support security
>>>>>>>     services other than certificate signing (bit 5), or CRL signing
>>>>>>>     (bit 6).  Digital signature mechanisms are often used for entity
>>>>>>>     authentication and data origin authentication with integrity.
>>>>>>>
>>>>>>>     The nonRepudiation bit is asserted when the subject public 
>>>>>>> key is
>>>>>>>     used to verify digital signatures used to provide a non-
>>>>>>>     repudiation service which protects against the signing entity
>>>>>>>     falsely denying some action, excluding certificate or CRL 
>>>>>>> signing.
>>>>>>>     In the case of later conflict, a reliable third party may
>>>>>>>     determine the authenticity of the signed data.
>>>>>>>
>>>>>>>     Further distinctions between the digitalSignature and
>>>>>>>     nonRepudiation bits may be provided in specific certificate
>>>>>>>     policies.
>>>>>>>
>>>>>>> The text from 3280bis does not align with the ISO-ITU text.
>>>>>>> Please align with the the ISO-ITU text.
>>>>>>>
>>>>>>> Denis
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
> 
> 
> 

Date: Fri, 27 May 2005 14:30:32 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stephen Farrell <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: 3280bis: key usage (13)
Sender: [email-masked]

Stephen,

Just before leaving my office in a few minutes for a few days,
here is a new text proposal for the DS bit:

New proposal for 3280bis:

     The digitalSignature bit is asserted when the subject public key
     is used for verifying digital signatures that are used
     with an entity authentication service, a data origin authentication
     service or/and an integrity service. However, it SHALL not be set
     when certificate signing (bit 5) or CRL signing (bit 6) is set.

Denis

> Hi Denis,
> 
> I've no problem with aligning the DS bit text although I
> wouldn't say that they're incompatible actually. I like
> the way 3280 says the DS isn't for certs or CRLs which
> ISO doesn't seem to include. Would you like to propose
> an aligned paragraph?
> 
> I oppose inclusion of new NR/CC text and the name change.
> 
> Stephen.
> 
> Denis Pinkas wrote:
> 
>> Stephen,
>>
>> I agree with everything Hoyt said on bit 1.
>>
>> However, there are two sides for this coin : bit 0 and bit 1.
>>
>> Both are again copied below:
>>
>> ISO Corrigendum:
>>
>>     a) digitalSignature: for verifying digital signatures that are used
>>        with an entity authentication service, a data origin 
>> authentication
>>        service or/and an integrity service;
>>
>> 3280bis:
>>
>>     The digitalSignature bit is asserted when the subject public key
>>     is used with a digital signature mechanism to support security
>>     services other than certificate signing (bit 5), or CRL signing
>>     (bit 6).  Digital signature mechanisms are often used for entity
>>     authentication and data origin authentication with integrity.
>>
>> The current text of 3280bis for bit 0 (ds) is incompatible with the ISO
>> Corrigendum.
>>
>> As Hoyt already said, any new text should align with the definition in 
>> the approved technical corrigenda against the 4th edition and in the 
>> upcoming 5th edition.
>>
>> Denis
>>
>>> Hi Hoyt,
>>>
>>> Hoyt L Kesterson II wrote:
>>>
>>>> Stephen
>>>>
>>>> I am somewhat dismayed at your reaction to the new text in X.509. 
>>>
>>>
>>>
>>>
>>> I'm sorry about that, but I guess I'm just fed up with the
>>> NR bit, though I can understand how people who've worked
>>> hard to try fix it might be dismayed.
>>>
>>> (BTW: I once suggested that CAs MUST set this bit randomly
>>> since that was the only way I could see to kill it off
>>> properly. If you can get that into X.509 then I'd be happy
>>> for 3280bis to align:-)
>>>
>>>  > I am not going to argue with you here (maybe in a bar the next time
>>>  > we run into each other).
>>>
>>> Good idea!
>>>
>>>> However, I do want to mention several points.
>>>>
>>>> 1) I initiated the change in text because of the various 
>>>> interpretations 
>>>
>>>
>>>
>>>  > by implementors that were resulting in non-interoperable
>>>  > implementations. It was a conversation with a PKIXer at a RSA
>>>  > conference a few years ago that caused me to articulate a private
>>>  > concern.
>>>
>>> I agree that everything connected with this bit has been
>>> confused and remains so.
>>>
>>>> 2) The legal community was very confused. There was even a 
>>>
>>>
>>>
>>>  > paper castigating the standard developers for mandating that
>>>  > one could not repudiate an action.
>>>
>>> Maybe the mistake was defining a bit that laywers care about?
>>>
>>>> 3) There were several meetings held where there was significant 
>>>
>>>
>>>
>>>  > participation by people in the IETF PKIX group (as well as
>>>  > lawyers). All agreed there was a problem with the published text.
>>>  > Denis and I argued long and hard over wording but we didn't
>>>  > disagree on the need for new text and its general intent.
>>>
>>> Fair enough.
>>>
>>>> 4) Russ was concerned that change would cause a problem 
>>>
>>>
>>>
>>>  > with existing IETF standards and was not too happy with a
>>>  > change to the name of the bit. That's why I put the line
>>>  > in that you referenced. However, that was to grandfather
>>>  > existing text, not to allow new text to continue using
>>>  > the old term and definitions.
>>>
>>> Ok. Here's the real reason not to change: Many people use
>>> ASN.1 compilers which means that names from the ASN.1
>>> module end up being directly used in higher layer code.
>>> Changing the name causes that code not to compile. I'd
>>> say that there's quite a lot of 3280 code in the world
>>> at this stage. So, if the semantics isn't supposed to
>>> have changed (and I assume that is meant to be the
>>> case) then this cost just doesn't seem worthwhile.
>>>
>>>> 5) It is the definition that is important. I recommend 
>>>
>>>
>>>
>>>  > that any new text align with the definition in the approved
>>>  > technical corrigenda against the 4th edition and in
>>>  > the upcoming 5th edition.
>>>
>>> While I'd rather not see any more text added on this,
>>> (there's been way too much already) I wouldn't have a big
>>> issue with trying to help a reader make sense of the
>>> fact that 3280bis and x.509 name this bit differently.
>>>
>>> However text like the sentence below is IMO almost
>>> certain to cause even more confusion:
>>>
>>>   The precise type of commitment of the signer e.g. "reviewed
>>>   and approved" or "with the intent to be bound", may be
>>>   signalled by the content being signed, e.g. the signed
>>>   document itself or some additional signed information.
>>>
>>> That sounds like the sole purpose of the CC-bit is as
>>> a flag to indicate when some other bits somewhere else
>>> tell you what the CC-bit means.
>>>
>>> So in the absence of some better text I think that 3280bis
>>> is better off just saying "NR a.k.a. CC" as it currently
>>> does.
>>>
>>> Regards,
>>> Stephen.
>>>
>>>>
>>>> At 14:49 +0100 5/26/05, Stephen Farrell wrote:
>>>>
>>>>> Denis,
>>>>>
>>>>>
>>>>>> Please align with the the ISO-ITU text.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Do you mean we should rename the bits and include the
>>>>> other new x.509 text? The design team were against
>>>>> doing that.
>>>>>
>>>>> Is there any (good) reason other than alignment to
>>>>> make such a change?
>>>>>
>>>>> Personally, I find the new x.509 text worse, although
>>>>> it does say: "Note that it is not incorrect to refer to
>>>>> this keyUsage bit using the identifier nonRepudiation."
>>>>> So I can argue that we are aligned, just not identical.
>>>>>
>>>>> But of course, I'm from the non-repudiation is non-sense
>>>>> camp so I may not be the best judge.
>>>>>
>>>>> Stephen.
>>>>>
>>>>> PS: A quibble:
>>>>>
>>>>>
>>>>>>  The new text in X.509 aligns with the text in RFC 3280.  No changes
>>>>>>  are required to 3280bis.  A comment has been added to the ASN.1 for
>>>>>>  KeyUsage stating that "recent editions of X.509 have renamed
>>>>>>  [the nonRepudiation] bit to contentCommitment"
>>>>>>
>>>>>> This statement is untrue.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The paragraph to which I assume you refer contains 3
>>>>> statements - it'd be easier to close these threads if
>>>>> you were more precise. (I think I got what you want
>>>>> by the end of the mail though...)
>>>>>
>>>>> PPS: "This statement is untrue."
>>>>>    Are you from Crete after all? :-)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Denis Pinkas wrote:
>>>>>
>>>>>
>>>>>> To the list,
>>>>>>
>>>>>> The disposition of comments states:
>>>>>>
>>>>>> 13) The descriptions of the meanings of the digitalSignature and
>>>>>>    nonRepudiation bits of keyUsage may need to be adjusted based
>>>>>>    on the work in X.509
>>>>>>
>>>>>> The new text in X.509 aligns with the text in RFC 3280.  No changes
>>>>>> are required to 3280bis.  A comment has been added to the ASN.1 for
>>>>>> KeyUsage stating that "recent editions of X.509 have renamed
>>>>>> [the nonRepudiation] bit to contentCommitment"
>>>>>>
>>>>>> This statement is untrue.
>>>>>>
>>>>>> The text from X.509 has been published in Corrigendum 3 (04/2004)
>>>>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
>>>>>>
>>>>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).
>>>>>>
>>>>>> An extract from this text is copied below:
>>>>>>
>>>>>> a) digitalSignature: for verifying digital signatures that are used
>>>>>>  with an entity authentication service, a data origin authentication
>>>>>>  service or/and an integrity service;
>>>>>>
>>>>>> b) contentCommitment: for verifying digital signatures which are 
>>>>>> intended
>>>>>>  to signal that the signer is committing to the content being signed.
>>>>>>  The type of commitment the certificate can be used to support may be
>>>>>>  further constrained by the CA, e.g. through a certificate policy.
>>>>>>  The precise type of commitment of the signer e.g. "reviewed and
>>>>>>  approved" or "with the intent to be bound", may be signalled by the
>>>>>>  content being signed, e.g. the signed document itself or some 
>>>>>> additional
>>>>>>  signed information.
>>>>>>
>>>>>>  Since a content commitment signing is considered to be a 
>>>>>> digitally signed
>>>>>>  transaction, the digitalSignature bit need not be set in the 
>>>>>> certificate.
>>>>>>  If it is set, it does not affect the level of commitment the 
>>>>>> signer has
>>>>>>  endowed in the signed content.
>>>>>>
>>>>>>  Note that it is not incorrect to refer to this keyUsage bit using 
>>>>>> the
>>>>>>  identifier nonRepudiation. However, the use of this identifier 
>>>>>> has been
>>>>>>  deprecated. Regardless of the identifier used, the semantics of 
>>>>>> this bit
>>>>>>  are as specified in this Directory Specification.
>>>>>>
>>>>>> The text from 3280 is copied below:
>>>>>>
>>>>>>     The digitalSignature bit is asserted when the subject public key
>>>>>>     is used with a digital signature mechanism to support security
>>>>>>     services other than certificate signing (bit 5), or CRL signing
>>>>>>     (bit 6).  Digital signature mechanisms are often used for entity
>>>>>>     authentication and data origin authentication with integrity.
>>>>>>
>>>>>>     The nonRepudiation bit is asserted when the subject public key is
>>>>>>     used to verify digital signatures used to provide a non-
>>>>>>     repudiation service which protects against the signing entity
>>>>>>     falsely denying some action, excluding certificate or CRL 
>>>>>> signing.
>>>>>>     In the case of later conflict, a reliable third party may
>>>>>>     determine the authenticity of the signed data.
>>>>>>
>>>>>>     Further distinctions between the digitalSignature and
>>>>>>     nonRepudiation bits may be provided in specific certificate
>>>>>>     policies.
>>>>>>
>>>>>> The text from 3280bis does not align with the ISO-ITU text.
>>>>>> Please align with the the ISO-ITU text.
>>>>>>
>>>>>> Denis
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
> 

Date: Fri, 27 May 2005 13:22:40 +0100
From: Stephen Farrell <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: 3280bis: key usage (13)
Sender: [email-masked]

Hi Denis,

I've no problem with aligning the DS bit text although I
wouldn't say that they're incompatible actually. I like
the way 3280 says the DS isn't for certs or CRLs which
ISO doesn't seem to include. Would you like to propose
an aligned paragraph?

I oppose inclusion of new NR/CC text and the name change.

Stephen.

Denis Pinkas wrote:

> Stephen,
> 
> I agree with everything Hoyt said on bit 1.
> 
> However, there are two sides for this coin : bit 0 and bit 1.
> 
> Both are again copied below:
> 
> ISO Corrigendum:
> 
>     a) digitalSignature: for verifying digital signatures that are used
>        with an entity authentication service, a data origin authentication
>        service or/and an integrity service;
> 
> 3280bis:
> 
>     The digitalSignature bit is asserted when the subject public key
>     is used with a digital signature mechanism to support security
>     services other than certificate signing (bit 5), or CRL signing
>     (bit 6).  Digital signature mechanisms are often used for entity
>     authentication and data origin authentication with integrity.
> 
> The current text of 3280bis for bit 0 (ds) is incompatible with the ISO
> Corrigendum.
> 
> As Hoyt already said, any new text should align with the definition in 
> the approved technical corrigenda against the 4th edition and in the 
> upcoming 5th edition.
> 
> Denis
> 
>> Hi Hoyt,
>>
>> Hoyt L Kesterson II wrote:
>>
>>> Stephen
>>>
>>> I am somewhat dismayed at your reaction to the new text in X.509. 
>>
>>
>>
>> I'm sorry about that, but I guess I'm just fed up with the
>> NR bit, though I can understand how people who've worked
>> hard to try fix it might be dismayed.
>>
>> (BTW: I once suggested that CAs MUST set this bit randomly
>> since that was the only way I could see to kill it off
>> properly. If you can get that into X.509 then I'd be happy
>> for 3280bis to align:-)
>>
>>  > I am not going to argue with you here (maybe in a bar the next time
>>  > we run into each other).
>>
>> Good idea!
>>
>>> However, I do want to mention several points.
>>>
>>> 1) I initiated the change in text because of the various interpretations 
>>
>>
>>  > by implementors that were resulting in non-interoperable
>>  > implementations. It was a conversation with a PKIXer at a RSA
>>  > conference a few years ago that caused me to articulate a private
>>  > concern.
>>
>> I agree that everything connected with this bit has been
>> confused and remains so.
>>
>>> 2) The legal community was very confused. There was even a 
>>
>>
>>  > paper castigating the standard developers for mandating that
>>  > one could not repudiate an action.
>>
>> Maybe the mistake was defining a bit that laywers care about?
>>
>>> 3) There were several meetings held where there was significant 
>>
>>
>>  > participation by people in the IETF PKIX group (as well as
>>  > lawyers). All agreed there was a problem with the published text.
>>  > Denis and I argued long and hard over wording but we didn't
>>  > disagree on the need for new text and its general intent.
>>
>> Fair enough.
>>
>>> 4) Russ was concerned that change would cause a problem 
>>
>>
>>  > with existing IETF standards and was not too happy with a
>>  > change to the name of the bit. That's why I put the line
>>  > in that you referenced. However, that was to grandfather
>>  > existing text, not to allow new text to continue using
>>  > the old term and definitions.
>>
>> Ok. Here's the real reason not to change: Many people use
>> ASN.1 compilers which means that names from the ASN.1
>> module end up being directly used in higher layer code.
>> Changing the name causes that code not to compile. I'd
>> say that there's quite a lot of 3280 code in the world
>> at this stage. So, if the semantics isn't supposed to
>> have changed (and I assume that is meant to be the
>> case) then this cost just doesn't seem worthwhile.
>>
>>> 5) It is the definition that is important. I recommend 
>>
>>
>>  > that any new text align with the definition in the approved
>>  > technical corrigenda against the 4th edition and in
>>  > the upcoming 5th edition.
>>
>> While I'd rather not see any more text added on this,
>> (there's been way too much already) I wouldn't have a big
>> issue with trying to help a reader make sense of the
>> fact that 3280bis and x.509 name this bit differently.
>>
>> However text like the sentence below is IMO almost
>> certain to cause even more confusion:
>>
>>   The precise type of commitment of the signer e.g. "reviewed
>>   and approved" or "with the intent to be bound", may be
>>   signalled by the content being signed, e.g. the signed
>>   document itself or some additional signed information.
>>
>> That sounds like the sole purpose of the CC-bit is as
>> a flag to indicate when some other bits somewhere else
>> tell you what the CC-bit means.
>>
>> So in the absence of some better text I think that 3280bis
>> is better off just saying "NR a.k.a. CC" as it currently
>> does.
>>
>> Regards,
>> Stephen.
>>
>>>
>>> At 14:49 +0100 5/26/05, Stephen Farrell wrote:
>>>
>>>> Denis,
>>>>
>>>>
>>>>> Please align with the the ISO-ITU text.
>>>>
>>>>
>>>>
>>>> Do you mean we should rename the bits and include the
>>>> other new x.509 text? The design team were against
>>>> doing that.
>>>>
>>>> Is there any (good) reason other than alignment to
>>>> make such a change?
>>>>
>>>> Personally, I find the new x.509 text worse, although
>>>> it does say: "Note that it is not incorrect to refer to
>>>> this keyUsage bit using the identifier nonRepudiation."
>>>> So I can argue that we are aligned, just not identical.
>>>>
>>>> But of course, I'm from the non-repudiation is non-sense
>>>> camp so I may not be the best judge.
>>>>
>>>> Stephen.
>>>>
>>>> PS: A quibble:
>>>>
>>>>
>>>>>  The new text in X.509 aligns with the text in RFC 3280.  No changes
>>>>>  are required to 3280bis.  A comment has been added to the ASN.1 for
>>>>>  KeyUsage stating that "recent editions of X.509 have renamed
>>>>>  [the nonRepudiation] bit to contentCommitment"
>>>>>
>>>>> This statement is untrue.
>>>>
>>>>
>>>>
>>>> The paragraph to which I assume you refer contains 3
>>>> statements - it'd be easier to close these threads if
>>>> you were more precise. (I think I got what you want
>>>> by the end of the mail though...)
>>>>
>>>> PPS: "This statement is untrue."
>>>>    Are you from Crete after all? :-)
>>>>
>>>>
>>>>
>>>>
>>>> Denis Pinkas wrote:
>>>>
>>>>
>>>>> To the list,
>>>>>
>>>>> The disposition of comments states:
>>>>>
>>>>> 13) The descriptions of the meanings of the digitalSignature and
>>>>>    nonRepudiation bits of keyUsage may need to be adjusted based
>>>>>    on the work in X.509
>>>>>
>>>>> The new text in X.509 aligns with the text in RFC 3280.  No changes
>>>>> are required to 3280bis.  A comment has been added to the ASN.1 for
>>>>> KeyUsage stating that "recent editions of X.509 have renamed
>>>>> [the nonRepudiation] bit to contentCommitment"
>>>>>
>>>>> This statement is untrue.
>>>>>
>>>>> The text from X.509 has been published in Corrigendum 3 (04/2004)
>>>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
>>>>>
>>>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).
>>>>>
>>>>> An extract from this text is copied below:
>>>>>
>>>>> a) digitalSignature: for verifying digital signatures that are used
>>>>>  with an entity authentication service, a data origin authentication
>>>>>  service or/and an integrity service;
>>>>>
>>>>> b) contentCommitment: for verifying digital signatures which are 
>>>>> intended
>>>>>  to signal that the signer is committing to the content being signed.
>>>>>  The type of commitment the certificate can be used to support may be
>>>>>  further constrained by the CA, e.g. through a certificate policy.
>>>>>  The precise type of commitment of the signer e.g. "reviewed and
>>>>>  approved" or "with the intent to be bound", may be signalled by the
>>>>>  content being signed, e.g. the signed document itself or some 
>>>>> additional
>>>>>  signed information.
>>>>>
>>>>>  Since a content commitment signing is considered to be a digitally 
>>>>> signed
>>>>>  transaction, the digitalSignature bit need not be set in the 
>>>>> certificate.
>>>>>  If it is set, it does not affect the level of commitment the 
>>>>> signer has
>>>>>  endowed in the signed content.
>>>>>
>>>>>  Note that it is not incorrect to refer to this keyUsage bit using the
>>>>>  identifier nonRepudiation. However, the use of this identifier has 
>>>>> been
>>>>>  deprecated. Regardless of the identifier used, the semantics of 
>>>>> this bit
>>>>>  are as specified in this Directory Specification.
>>>>>
>>>>> The text from 3280 is copied below:
>>>>>
>>>>>     The digitalSignature bit is asserted when the subject public key
>>>>>     is used with a digital signature mechanism to support security
>>>>>     services other than certificate signing (bit 5), or CRL signing
>>>>>     (bit 6).  Digital signature mechanisms are often used for entity
>>>>>     authentication and data origin authentication with integrity.
>>>>>
>>>>>     The nonRepudiation bit is asserted when the subject public key is
>>>>>     used to verify digital signatures used to provide a non-
>>>>>     repudiation service which protects against the signing entity
>>>>>     falsely denying some action, excluding certificate or CRL signing.
>>>>>     In the case of later conflict, a reliable third party may
>>>>>     determine the authenticity of the signed data.
>>>>>
>>>>>     Further distinctions between the digitalSignature and
>>>>>     nonRepudiation bits may be provided in specific certificate
>>>>>     policies.
>>>>>
>>>>> The text from 3280bis does not align with the ISO-ITU text.
>>>>> Please align with the the ISO-ITU text.
>>>>>
>>>>> Denis
>>>>
>>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: 3280bis: key usage (13)
Date: Fri, 27 May 2005 13:06:07 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "Hoyt L Kesterson II" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

Speaking as implementer and not design team member, I can live with both
texts since they allow me to do the same thing.

It allows my low level application to add a digital signature supported
by the digital signature bit, where the intention of that application is
to add integrity and origin authentication, while the use of the
signature in practice (higher layers) ends up being used as evidence of
some kind of commitment.

Example. An e-mail application adds an arbitrary signature supported by
the DS bit, while the body of the text reads "Through the digital
signature on this e-mail I commit to....). This is now a perfectly valid
scenario according to both texts.

The real defect that was fixed was that the digital signature bit said
that it was for purposes "other" than NR. That is now gone in both
standards.

I agree to Stephen's rationale to keep the name nonRepudiation. It is
not worth the cost to change the name. Stephen's point here was missing
in the X.509 discussions of a name change.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of Denis Pinkas
> Sent: den 27 maj 2005 12:29
> To: Stephen Farrell
> Cc: Hoyt L Kesterson II; pkix
> Subject: Re: 3280bis: key usage (13)
> 
> 
> Stephen,
> 
> I agree with everything Hoyt said on bit 1.
> 
> However, there are two sides for this coin : bit 0 and bit 1.
> 
> Both are again copied below:
> 
> ISO Corrigendum:
> 
>      a) digitalSignature: for verifying digital signatures that are
used
>         with an entity authentication service, a data origin
> authentication
>         service or/and an integrity service;
> 
> 3280bis:
> 
>      The digitalSignature bit is asserted when the subject public key
>      is used with a digital signature mechanism to support security
>      services other than certificate signing (bit 5), or CRL signing
>      (bit 6).  Digital signature mechanisms are often used for entity
>      authentication and data origin authentication with integrity.
> 
> The current text of 3280bis for bit 0 (ds) is incompatible with the
ISO
> Corrigendum.
> 
> As Hoyt already said, any new text should align with the definition in
the
> approved technical corrigenda against the 4th edition and in the
upcoming
> 5th edition.
> 
> Denis
> 
> > Hi Hoyt,
> >
> > Hoyt L Kesterson II wrote:
> >
> >> Stephen
> >>
> >> I am somewhat dismayed at your reaction to the new text in X.509.
> >
> >
> > I'm sorry about that, but I guess I'm just fed up with the
> > NR bit, though I can understand how people who've worked
> > hard to try fix it might be dismayed.
> >
> > (BTW: I once suggested that CAs MUST set this bit randomly
> > since that was the only way I could see to kill it off
> > properly. If you can get that into X.509 then I'd be happy
> > for 3280bis to align:-)
> >
> >  > I am not going to argue with you here (maybe in a bar the next
time
> >  > we run into each other).
> >
> > Good idea!
> >
> >> However, I do want to mention several points.
> >>
> >> 1) I initiated the change in text because of the various
> interpretations
> >
> >  > by implementors that were resulting in non-interoperable
> >  > implementations. It was a conversation with a PKIXer at a RSA
> >  > conference a few years ago that caused me to articulate a private
> >  > concern.
> >
> > I agree that everything connected with this bit has been
> > confused and remains so.
> >
> >> 2) The legal community was very confused. There was even a
> >
> >  > paper castigating the standard developers for mandating that
> >  > one could not repudiate an action.
> >
> > Maybe the mistake was defining a bit that laywers care about?
> >
> >> 3) There were several meetings held where there was significant
> >
> >  > participation by people in the IETF PKIX group (as well as
> >  > lawyers). All agreed there was a problem with the published text.
> >  > Denis and I argued long and hard over wording but we didn't
> >  > disagree on the need for new text and its general intent.
> >
> > Fair enough.
> >
> >> 4) Russ was concerned that change would cause a problem
> >
> >  > with existing IETF standards and was not too happy with a
> >  > change to the name of the bit. That's why I put the line
> >  > in that you referenced. However, that was to grandfather
> >  > existing text, not to allow new text to continue using
> >  > the old term and definitions.
> >
> > Ok. Here's the real reason not to change: Many people use
> > ASN.1 compilers which means that names from the ASN.1
> > module end up being directly used in higher layer code.
> > Changing the name causes that code not to compile. I'd
> > say that there's quite a lot of 3280 code in the world
> > at this stage. So, if the semantics isn't supposed to
> > have changed (and I assume that is meant to be the
> > case) then this cost just doesn't seem worthwhile.
> >
> >> 5) It is the definition that is important. I recommend
> >
> >  > that any new text align with the definition in the approved
> >  > technical corrigenda against the 4th edition and in
> >  > the upcoming 5th edition.
> >
> > While I'd rather not see any more text added on this,
> > (there's been way too much already) I wouldn't have a big
> > issue with trying to help a reader make sense of the
> > fact that 3280bis and x.509 name this bit differently.
> >
> > However text like the sentence below is IMO almost
> > certain to cause even more confusion:
> >
> >   The precise type of commitment of the signer e.g. "reviewed
> >   and approved" or "with the intent to be bound", may be
> >   signalled by the content being signed, e.g. the signed
> >   document itself or some additional signed information.
> >
> > That sounds like the sole purpose of the CC-bit is as
> > a flag to indicate when some other bits somewhere else
> > tell you what the CC-bit means.
> >
> > So in the absence of some better text I think that 3280bis
> > is better off just saying "NR a.k.a. CC" as it currently
> > does.
> >
> > Regards,
> > Stephen.
> >
> >>
> >> At 14:49 +0100 5/26/05, Stephen Farrell wrote:
> >>
> >>> Denis,
> >>>
> >>>
> >>>> Please align with the the ISO-ITU text.
> >>>
> >>>
> >>> Do you mean we should rename the bits and include the
> >>> other new x.509 text? The design team were against
> >>> doing that.
> >>>
> >>> Is there any (good) reason other than alignment to
> >>> make such a change?
> >>>
> >>> Personally, I find the new x.509 text worse, although
> >>> it does say: "Note that it is not incorrect to refer to
> >>> this keyUsage bit using the identifier nonRepudiation."
> >>> So I can argue that we are aligned, just not identical.
> >>>
> >>> But of course, I'm from the non-repudiation is non-sense
> >>> camp so I may not be the best judge.
> >>>
> >>> Stephen.
> >>>
> >>> PS: A quibble:
> >>>
> >>>
> >>>>  The new text in X.509 aligns with the text in RFC 3280.  No
changes
> >>>>  are required to 3280bis.  A comment has been added to the ASN.1
for
> >>>>  KeyUsage stating that "recent editions of X.509 have renamed
> >>>>  [the nonRepudiation] bit to contentCommitment"
> >>>>
> >>>> This statement is untrue.
> >>>
> >>>
> >>> The paragraph to which I assume you refer contains 3
> >>> statements - it'd be easier to close these threads if
> >>> you were more precise. (I think I got what you want
> >>> by the end of the mail though...)
> >>>
> >>> PPS: "This statement is untrue."
> >>>    Are you from Crete after all? :-)
> >>>
> >>>
> >>>
> >>>
> >>> Denis Pinkas wrote:
> >>>
> >>>
> >>>> To the list,
> >>>>
> >>>> The disposition of comments states:
> >>>>
> >>>> 13) The descriptions of the meanings of the digitalSignature and
> >>>>    nonRepudiation bits of keyUsage may need to be adjusted based
> >>>>    on the work in X.509
> >>>>
> >>>> The new text in X.509 aligns with the text in RFC 3280.  No
changes
> >>>> are required to 3280bis.  A comment has been added to the ASN.1
for
> >>>> KeyUsage stating that "recent editions of X.509 have renamed
> >>>> [the nonRepudiation] bit to contentCommitment"
> >>>>
> >>>> This statement is untrue.
> >>>>
> >>>> The text from X.509 has been published in Corrigendum 3 (04/2004)
> >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
> >>>>
> >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).
> >>>>
> >>>> An extract from this text is copied below:
> >>>>
> >>>> a) digitalSignature: for verifying digital signatures that are
used
> >>>>  with an entity authentication service, a data origin
authentication
> >>>>  service or/and an integrity service;
> >>>>
> >>>> b) contentCommitment: for verifying digital signatures which are
> >>>> intended
> >>>>  to signal that the signer is committing to the content being
signed.
> >>>>  The type of commitment the certificate can be used to support
may be
> >>>>  further constrained by the CA, e.g. through a certificate
policy.
> >>>>  The precise type of commitment of the signer e.g. "reviewed and
> >>>>  approved" or "with the intent to be bound", may be signalled by
the
> >>>>  content being signed, e.g. the signed document itself or some
> >>>> additional
> >>>>  signed information.
> >>>>
> >>>>  Since a content commitment signing is considered to be a
digitally
> >>>> signed
> >>>>  transaction, the digitalSignature bit need not be set in the
> >>>> certificate.
> >>>>  If it is set, it does not affect the level of commitment the
signer
> >>>> has
> >>>>  endowed in the signed content.
> >>>>
> >>>>  Note that it is not incorrect to refer to this keyUsage bit
using
> the
> >>>>  identifier nonRepudiation. However, the use of this identifier
has
> >>>> been
> >>>>  deprecated. Regardless of the identifier used, the semantics of
> >>>> this bit
> >>>>  are as specified in this Directory Specification.
> >>>>
> >>>> The text from 3280 is copied below:
> >>>>
> >>>>     The digitalSignature bit is asserted when the subject public
key
> >>>>     is used with a digital signature mechanism to support
security
> >>>>     services other than certificate signing (bit 5), or CRL
signing
> >>>>     (bit 6).  Digital signature mechanisms are often used for
entity
> >>>>     authentication and data origin authentication with integrity.
> >>>>
> >>>>     The nonRepudiation bit is asserted when the subject public
key is
> >>>>     used to verify digital signatures used to provide a non-
> >>>>     repudiation service which protects against the signing entity
> >>>>     falsely denying some action, excluding certificate or CRL
> signing.
> >>>>     In the case of later conflict, a reliable third party may
> >>>>     determine the authenticity of the signed data.
> >>>>
> >>>>     Further distinctions between the digitalSignature and
> >>>>     nonRepudiation bits may be provided in specific certificate
> >>>>     policies.
> >>>>
> >>>> The text from 3280bis does not align with the ISO-ITU text.
> >>>> Please align with the the ISO-ITU text.
> >>>>
> >>>> Denis
> >>>
> >>
> >>
> >>
> >
> >
> 

Date: Fri, 27 May 2005 12:29:02 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stephen Farrell <[email-masked]>
CC: Hoyt L Kesterson II <[email-masked]>, pkix <[email-masked]>
Subject: Re: 3280bis: key usage (13)
Sender: [email-masked]

Stephen,

I agree with everything Hoyt said on bit 1.

However, there are two sides for this coin : bit 0 and bit 1.

Both are again copied below:

ISO Corrigendum:

     a) digitalSignature: for verifying digital signatures that are used
        with an entity authentication service, a data origin authentication
        service or/and an integrity service;

3280bis:

     The digitalSignature bit is asserted when the subject public key
     is used with a digital signature mechanism to support security
     services other than certificate signing (bit 5), or CRL signing
     (bit 6).  Digital signature mechanisms are often used for entity
     authentication and data origin authentication with integrity.

The current text of 3280bis for bit 0 (ds) is incompatible with the ISO
Corrigendum.

As Hoyt already said, any new text should align with the definition in the 
approved technical corrigenda against the 4th edition and in the upcoming 
5th edition.

Denis

> Hi Hoyt,
> 
> Hoyt L Kesterson II wrote:
> 
>> Stephen
>>
>> I am somewhat dismayed at your reaction to the new text in X.509. 
> 
> 
> I'm sorry about that, but I guess I'm just fed up with the
> NR bit, though I can understand how people who've worked
> hard to try fix it might be dismayed.
> 
> (BTW: I once suggested that CAs MUST set this bit randomly
> since that was the only way I could see to kill it off
> properly. If you can get that into X.509 then I'd be happy
> for 3280bis to align:-)
> 
>  > I am not going to argue with you here (maybe in a bar the next time
>  > we run into each other).
> 
> Good idea!
> 
>> However, I do want to mention several points.
>>
>> 1) I initiated the change in text because of the various interpretations 
> 
>  > by implementors that were resulting in non-interoperable
>  > implementations. It was a conversation with a PKIXer at a RSA
>  > conference a few years ago that caused me to articulate a private
>  > concern.
> 
> I agree that everything connected with this bit has been
> confused and remains so.
> 
>> 2) The legal community was very confused. There was even a 
> 
>  > paper castigating the standard developers for mandating that
>  > one could not repudiate an action.
> 
> Maybe the mistake was defining a bit that laywers care about?
> 
>> 3) There were several meetings held where there was significant 
> 
>  > participation by people in the IETF PKIX group (as well as
>  > lawyers). All agreed there was a problem with the published text.
>  > Denis and I argued long and hard over wording but we didn't
>  > disagree on the need for new text and its general intent.
> 
> Fair enough.
> 
>> 4) Russ was concerned that change would cause a problem 
> 
>  > with existing IETF standards and was not too happy with a
>  > change to the name of the bit. That's why I put the line
>  > in that you referenced. However, that was to grandfather
>  > existing text, not to allow new text to continue using
>  > the old term and definitions.
> 
> Ok. Here's the real reason not to change: Many people use
> ASN.1 compilers which means that names from the ASN.1
> module end up being directly used in higher layer code.
> Changing the name causes that code not to compile. I'd
> say that there's quite a lot of 3280 code in the world
> at this stage. So, if the semantics isn't supposed to
> have changed (and I assume that is meant to be the
> case) then this cost just doesn't seem worthwhile.
> 
>> 5) It is the definition that is important. I recommend 
> 
>  > that any new text align with the definition in the approved
>  > technical corrigenda against the 4th edition and in
>  > the upcoming 5th edition.
> 
> While I'd rather not see any more text added on this,
> (there's been way too much already) I wouldn't have a big
> issue with trying to help a reader make sense of the
> fact that 3280bis and x.509 name this bit differently.
> 
> However text like the sentence below is IMO almost
> certain to cause even more confusion:
> 
>   The precise type of commitment of the signer e.g. "reviewed
>   and approved" or "with the intent to be bound", may be
>   signalled by the content being signed, e.g. the signed
>   document itself or some additional signed information.
> 
> That sounds like the sole purpose of the CC-bit is as
> a flag to indicate when some other bits somewhere else
> tell you what the CC-bit means.
> 
> So in the absence of some better text I think that 3280bis
> is better off just saying "NR a.k.a. CC" as it currently
> does.
> 
> Regards,
> Stephen.
> 
>>
>> At 14:49 +0100 5/26/05, Stephen Farrell wrote:
>>
>>> Denis,
>>>
>>>
>>>> Please align with the the ISO-ITU text.
>>>
>>>
>>> Do you mean we should rename the bits and include the
>>> other new x.509 text? The design team were against
>>> doing that.
>>>
>>> Is there any (good) reason other than alignment to
>>> make such a change?
>>>
>>> Personally, I find the new x.509 text worse, although
>>> it does say: "Note that it is not incorrect to refer to
>>> this keyUsage bit using the identifier nonRepudiation."
>>> So I can argue that we are aligned, just not identical.
>>>
>>> But of course, I'm from the non-repudiation is non-sense
>>> camp so I may not be the best judge.
>>>
>>> Stephen.
>>>
>>> PS: A quibble:
>>>
>>>
>>>>  The new text in X.509 aligns with the text in RFC 3280.  No changes
>>>>  are required to 3280bis.  A comment has been added to the ASN.1 for
>>>>  KeyUsage stating that "recent editions of X.509 have renamed
>>>>  [the nonRepudiation] bit to contentCommitment"
>>>>
>>>> This statement is untrue.
>>>
>>>
>>> The paragraph to which I assume you refer contains 3
>>> statements - it'd be easier to close these threads if
>>> you were more precise. (I think I got what you want
>>> by the end of the mail though...)
>>>
>>> PPS: "This statement is untrue."
>>>    Are you from Crete after all? :-)
>>>
>>>
>>>
>>>
>>> Denis Pinkas wrote:
>>>
>>>
>>>> To the list,
>>>>
>>>> The disposition of comments states:
>>>>
>>>> 13) The descriptions of the meanings of the digitalSignature and
>>>>    nonRepudiation bits of keyUsage may need to be adjusted based
>>>>    on the work in X.509
>>>>
>>>> The new text in X.509 aligns with the text in RFC 3280.  No changes
>>>> are required to 3280bis.  A comment has been added to the ASN.1 for
>>>> KeyUsage stating that "recent editions of X.509 have renamed
>>>> [the nonRepudiation] bit to contentCommitment"
>>>>
>>>> This statement is untrue.
>>>>
>>>> The text from X.509 has been published in Corrigendum 3 (04/2004)
>>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
>>>>
>>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).
>>>>
>>>> An extract from this text is copied below:
>>>>
>>>> a) digitalSignature: for verifying digital signatures that are used
>>>>  with an entity authentication service, a data origin authentication
>>>>  service or/and an integrity service;
>>>>
>>>> b) contentCommitment: for verifying digital signatures which are 
>>>> intended
>>>>  to signal that the signer is committing to the content being signed.
>>>>  The type of commitment the certificate can be used to support may be
>>>>  further constrained by the CA, e.g. through a certificate policy.
>>>>  The precise type of commitment of the signer e.g. "reviewed and
>>>>  approved" or "with the intent to be bound", may be signalled by the
>>>>  content being signed, e.g. the signed document itself or some 
>>>> additional
>>>>  signed information.
>>>>
>>>>  Since a content commitment signing is considered to be a digitally 
>>>> signed
>>>>  transaction, the digitalSignature bit need not be set in the 
>>>> certificate.
>>>>  If it is set, it does not affect the level of commitment the signer 
>>>> has
>>>>  endowed in the signed content.
>>>>
>>>>  Note that it is not incorrect to refer to this keyUsage bit using the
>>>>  identifier nonRepudiation. However, the use of this identifier has 
>>>> been
>>>>  deprecated. Regardless of the identifier used, the semantics of 
>>>> this bit
>>>>  are as specified in this Directory Specification.
>>>>
>>>> The text from 3280 is copied below:
>>>>
>>>>     The digitalSignature bit is asserted when the subject public key
>>>>     is used with a digital signature mechanism to support security
>>>>     services other than certificate signing (bit 5), or CRL signing
>>>>     (bit 6).  Digital signature mechanisms are often used for entity
>>>>     authentication and data origin authentication with integrity.
>>>>
>>>>     The nonRepudiation bit is asserted when the subject public key is
>>>>     used to verify digital signatures used to provide a non-
>>>>     repudiation service which protects against the signing entity
>>>>     falsely denying some action, excluding certificate or CRL signing.
>>>>     In the case of later conflict, a reliable third party may
>>>>     determine the authenticity of the signed data.
>>>>
>>>>     Further distinctions between the digitalSignature and
>>>>     nonRepudiation bits may be provided in specific certificate
>>>>     policies.
>>>>
>>>> The text from 3280bis does not align with the ISO-ITU text.
>>>> Please align with the the ISO-ITU text.
>>>>
>>>> Denis
>>>
>>
>>
>>
> 
> 

Date: Fri, 27 May 2005 10:58:17 +0100
From: Stephen Farrell <[email-masked]>
To: Hoyt L Kesterson II <[email-masked]>
Cc: Denis Pinkas <[email-masked]>, pkix <[email-masked]>
Subject: Re: 3280bis: key usage (13)
Sender: [email-masked]

Hi Hoyt,

Hoyt L Kesterson II wrote:

> Stephen
> 
> I am somewhat dismayed at your reaction to the new text in X.509. 

I'm sorry about that, but I guess I'm just fed up with the
NR bit, though I can understand how people who've worked
hard to try fix it might be dismayed.

(BTW: I once suggested that CAs MUST set this bit randomly
since that was the only way I could see to kill it off
properly. If you can get that into X.509 then I'd be happy
for 3280bis to align:-)

 > I am not going to argue with you here (maybe in a bar the next time
 > we run into each other).

Good idea!

> However, I do want to mention several points.
> 
> 1) I initiated the change in text because of the various interpretations 
 > by implementors that were resulting in non-interoperable
 > implementations. It was a conversation with a PKIXer at a RSA
 > conference a few years ago that caused me to articulate a private
 > concern.

I agree that everything connected with this bit has been
confused and remains so.

> 2) The legal community was very confused. There was even a 
 > paper castigating the standard developers for mandating that
 > one could not repudiate an action.

Maybe the mistake was defining a bit that laywers care about?

> 3) There were several meetings held where there was significant 
 > participation by people in the IETF PKIX group (as well as
 > lawyers). All agreed there was a problem with the published text.
 > Denis and I argued long and hard over wording but we didn't
 > disagree on the need for new text and its general intent.

Fair enough.

> 4) Russ was concerned that change would cause a problem 
 > with existing IETF standards and was not too happy with a
 > change to the name of the bit. That's why I put the line
 > in that you referenced. However, that was to grandfather
 > existing text, not to allow new text to continue using
 > the old term and definitions.

Ok. Here's the real reason not to change: Many people use
ASN.1 compilers which means that names from the ASN.1
module end up being directly used in higher layer code.
Changing the name causes that code not to compile. I'd
say that there's quite a lot of 3280 code in the world
at this stage. So, if the semantics isn't supposed to
have changed (and I assume that is meant to be the
case) then this cost just doesn't seem worthwhile.

> 5) It is the definition that is important. I recommend 
 > that any new text align with the definition in the approved
 > technical corrigenda against the 4th edition and in
 > the upcoming 5th edition.

While I'd rather not see any more text added on this,
(there's been way too much already) I wouldn't have a big
issue with trying to help a reader make sense of the
fact that 3280bis and x.509 name this bit differently.

However text like the sentence below is IMO almost
certain to cause even more confusion:

   The precise type of commitment of the signer e.g. "reviewed
   and approved" or "with the intent to be bound", may be
   signalled by the content being signed, e.g. the signed
   document itself or some additional signed information.

That sounds like the sole purpose of the CC-bit is as
a flag to indicate when some other bits somewhere else
tell you what the CC-bit means.

So in the absence of some better text I think that 3280bis
is better off just saying "NR a.k.a. CC" as it currently
does.

Regards,
Stephen.

> 
> At 14:49 +0100 5/26/05, Stephen Farrell wrote:
> 
>>Denis,
>>
>>
>>>Please align with the the ISO-ITU text.
>>
>>Do you mean we should rename the bits and include the
>>other new x.509 text? The design team were against
>>doing that.
>>
>>Is there any (good) reason other than alignment to
>>make such a change?
>>
>>Personally, I find the new x.509 text worse, although
>>it does say: "Note that it is not incorrect to refer to
>>this keyUsage bit using the identifier nonRepudiation."
>>So I can argue that we are aligned, just not identical.
>>
>>But of course, I'm from the non-repudiation is non-sense
>>camp so I may not be the best judge.
>>
>>Stephen.
>>
>>PS: A quibble:
>>
>>
>>>  The new text in X.509 aligns with the text in RFC 3280.  No changes
>>>  are required to 3280bis.  A comment has been added to the ASN.1 for
>>>  KeyUsage stating that "recent editions of X.509 have renamed
>>>  [the nonRepudiation] bit to contentCommitment"
>>>
>>>This statement is untrue.
>>
>>The paragraph to which I assume you refer contains 3
>>statements - it'd be easier to close these threads if
>>you were more precise. (I think I got what you want
>>by the end of the mail though...)
>>
>>PPS: "This statement is untrue."
>>    Are you from Crete after all? :-)
>>
>>
>>
>>
>>Denis Pinkas wrote:
>>
>>
>>>To the list,
>>>
>>>The disposition of comments states:
>>>
>>>13) The descriptions of the meanings of the digitalSignature and
>>>    nonRepudiation bits of keyUsage may need to be adjusted based
>>>    on the work in X.509
>>>
>>> The new text in X.509 aligns with the text in RFC 3280.  No changes
>>> are required to 3280bis.  A comment has been added to the ASN.1 for
>>> KeyUsage stating that "recent editions of X.509 have renamed
>>> [the nonRepudiation] bit to contentCommitment"
>>>
>>>This statement is untrue.
>>>
>>>The text from X.509 has been published in Corrigendum 3 (04/2004)
>>>on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
>>>
>>>ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).
>>>
>>>An extract from this text is copied below:
>>>
>>>a) digitalSignature: for verifying digital signatures that are used
>>>  with an entity authentication service, a data origin authentication
>>>  service or/and an integrity service;
>>>
>>>b) contentCommitment: for verifying digital signatures which are intended
>>>  to signal that the signer is committing to the content being signed.
>>>  The type of commitment the certificate can be used to support may be
>>>  further constrained by the CA, e.g. through a certificate policy.
>>>  The precise type of commitment of the signer e.g. "reviewed and
>>>  approved" or "with the intent to be bound", may be signalled by the
>>>  content being signed, e.g. the signed document itself or some additional
>>>  signed information.
>>>
>>>  Since a content commitment signing is considered to be a digitally signed
>>>  transaction, the digitalSignature bit need not be set in the certificate.
>>>  If it is set, it does not affect the level of commitment the signer has
>>>  endowed in the signed content.
>>>
>>>  Note that it is not incorrect to refer to this keyUsage bit using the
>>>  identifier nonRepudiation. However, the use of this identifier has been
>>>  deprecated. Regardless of the identifier used, the semantics of this bit
>>>  are as specified in this Directory Specification.
>>>
>>>The text from 3280 is copied below:
>>>
>>>     The digitalSignature bit is asserted when the subject public key
>>>     is used with a digital signature mechanism to support security
>>>     services other than certificate signing (bit 5), or CRL signing
>>>     (bit 6).  Digital signature mechanisms are often used for entity
>>>     authentication and data origin authentication with integrity.
>>>
>>>     The nonRepudiation bit is asserted when the subject public key is
>>>     used to verify digital signatures used to provide a non-
>>>     repudiation service which protects against the signing entity
>>>     falsely denying some action, excluding certificate or CRL signing.
>>>     In the case of later conflict, a reliable third party may
>>>     determine the authenticity of the signed data.
>>>
>>>     Further distinctions between the digitalSignature and
>>>     nonRepudiation bits may be provided in specific certificate
>>>     policies.
>>>
>>>The text from 3280bis does not align with the ISO-ITU text.
>>>Please align with the the ISO-ITU text.
>>>
>>>Denis
> 
> 
> 

To: "Santosh Chokhani" <[email-masked]>
Cc: [email-masked]
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
From: Tom Gindin <[email-masked]>
Date: Thu, 26 May 2005 22:54:56 -0400
Sender: [email-masked]

        Santosh:

        That is indeed the scenario.  I'm glad to hear that both your 
library and Stefan's do reject paths like this.  I didn't say that no one 
does or understands these things, just that I doubted that people who 
hadn't implemented a library did (you ran into an infinite loop in this 
case while testing, which suggests that it hadn't been fully understood 
before that).
        If any implementor interpreted 6.1.3-a-3's "not revoked and not on 
hold status" to not reject cases where his code could not determine the 
status, they could easily accept this path.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
05/26/2005 07:57 AM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: CRL Issue (Was RE: WG Last Call: AIA CRL 
extension)

Tom,

BTW, we may be putting Peter Guttman and rest of the group to sleep again,
which may not be all bad.

You need to provide a clear streamlined scenario.  From what I discern, 
you
are saying the following.

Root R --> C

C --> C1 as CRL issuer & C --> S and C asserts in S C1.

C1 issues CRL.

S goes rouge.  C instructs C1 to put S on CRLgood.

S --> C1.  Now, the new C1 can issue a CRLbad without S on it.

In order to verify signature on CRLbad, you need the path R --> C --> S 
-->
C1.  But, note that in order to verify signature on C --> S either you 
will
find the correct path and CRL (R --> C --> C1 and CRLgood) or you will 
have
circularity since C-->S require C1 CRL.

There is no sense in having this e-mail discussion unless you lay out the
scenario precisely as above as to what the various certification paths 
are.

So far, when I fill in the gaps, all I see is circularity issues or what
Stefan calls infinite loops.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Wednesday, May 25, 2005 10:22 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)

        Santosh:

        I thought that I had made that particular issue clear.  The 
indirect CRL being retrieved governs C's certificates and its issuer name 
(call it C1) is supposed to belong to C.  Indeed, C has issued a CRL 
signing certificate with subject name C1.  However, S has created another 
CRL signing certificate with this same subject name and has created a CRL 
with that key pair.  C did not create any circularity.  The original 
certificate for C1 was issued by C and the corresponding private key 
belongs to an entity under C's control, while the new certificate for C1 
was issued by S and the corresponding private key belongs to a malicious 
subsystem inside S.  While certificates are issued to entities, relying 
parties know the name and the chain but not the entity.
        No relevant CRL is issued by S.  I'm sure that your objection to '
looking at CRL issued by C' actually meant 'issued by S', because you 
normally verify certificates by looking at CRL's issued by the certificate 

issuer or its delegate.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
05/25/2005 08:58 AM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: CRL Issue (Was RE: WG Last Call: AIA CRL 
extension)

Tom,

It is not clear from your example who the indirect CRL issuer is and what
role the "indirect CRL" plays in the attack.  If S is the indirect CRL
issuer, C should be smart enough to not create circularity (a good toolkit
will not verify path when C issues a certificate to S and points to S as 
the
indirect CRL issuer since it causes circularity and chicken and egg
problem).  That scenario can be easily rectified within current standard 
by
C not declaring S as the indirect CRL issuer for certificate issued to S. 
C
can declare itself in the CDP or some other issuer.

I suspect you do not mean this.  Your example may be simpler.  To me the
attack is still not plausible.  Your scenario is not detailed enough to
illustrate an attack.  It does not seem that there is a way to validate 
the
certificate issued to C by S without looking at CRL issued by C, resulting
in circularity, which relying party clients should not accept. 

(Note that my November presentation to IETF in DC covered the circularity
issues in CRL and OCSP and recommendations for 3280 and 2560 in addition 
to
the CRL certification path)

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2005 7:50 AM
To: Santosh Chokhani
Cc: [email-masked]; 'Julien Stern'
Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension)

        Santosh:

        A relatively concrete example would be the following:
        Assume a trust anchor called A, and CA it has issued a cross 
certificate to called C.  Further assume that C uses indirect CRL's, and 
has issued a cross certificate without name constraints to another CA 
called S. Then assume that S goes rogue and creates a CRL signing 
certificate with the same name as C uses for its indirect CRL's (the key 
pair in that certificate is hereinafter called the "rogue CRL signer"). 
Further assume that C finds out about this and creates a CRL listing S as 
revoked, but that S successfully replaces that CRL in the repository by 
one signed by the rogue CRL signer.
        Does RFC 3280 path validation consider S invalid?  If so, which 
step loops or fails?  It looks to me like 6.3.3-b-1 passes.  Is there 
always a bi-modal loop between 6.3.3-f and 6.1.3-a-3?  If not, what else 
would be likely to cause S to be recognized as invalid?  You could 
probably patch any difficulties by adding "if the certificate whose 
revocation is being checked appears in the path, reject it" to 6.3.3-f.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
05/24/2005 06:42 PM
 
        To:     Tom Gindin/Watson/IBM@IBMUS, <[email-masked]>
        cc:     "'Julien Stern'" <[email-masked]>
        Subject:        CRL Issue (Was RE: WG Last Call: AIA CRL 
extension)

Tom,

I assume you are talking about CRL certification path solution I proposed
will not permit the scenario?  I still do not see in your case, if the
Subject CA (cross certified CA) is revoked, you will verify the path to it
in the first place.  May be I am not understanding your scenario properly.
How does the revoked CA gets verified?

Julien,

We have defined and proven the solution for how to do this.  The scenario
you proposed is not something X.509 worries about (A CA that is still 
valid,
but has gone bad).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Julien Stern
Sent: Tuesday, May 24, 2005 3:49 PM
To: Stefan Santesson
Cc: Tom Gindin; [email-masked]
Subject: Re: WG Last Call: AIA CRL extension

On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> Tom and Julien,
> 
> Since this is a repetition of the discussion we had before San Diego 
> and I don't want to repeat it here. I'm not saying that this 
> discussion is invalid; it is just directed towards the wrong draft.

Stefan,

I agree with you. Actually, I would tend to believe that a _real_ 
discussion
would have to take place at some point regarding the overall security 
model
of CRL validation, but I have absolutely no objection to the AIA, as soon 
as
it is made clear that it's only goal is to simplify path building
implementations, and not to adress security issues. My very humble take on
the subject is that Denis and yourself have been arguing on the list on
absolutely valid but different matters.

So, I chose not to comment expect for my last mail (and will not any more)
about AIA, but I still think that a discusssion regarding revocation
validation should take place for RFC3280bis, eventually.

Regards,

--
Julien Stern

> 
> As Tom pointed out:
> > this fraudulently issued CRL will probably be validated whether it
> > contains an AIA or not.
> 
> This indicates once again that this is not an issue caused by the use 
> of AIA in CRLs but a generic CRL validation issue that belongs with 
> RFC 3280bis and not with the CRL-AIA draft.
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > On Behalf Of Julien Stern
> > Sent: den 24 maj 2005 09:39
> > To: Tom Gindin
> > Cc: [email-masked]
> > Subject: Re: WG Last Call: AIA CRL extension
> > 
> > 
> > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > >
> > >         There is one scenario permitted by the "same trust anchor"
> rule
> > > for CRL signers which seems to me to be a serious security hole.
> Let us
> > > assume a valid CA which is a direct subordinate of one of the RP's
> trust
> > > anchors.  This CA issues separate CRL's and ARL's, in a quite 
> > > usual
> way,
> > > and issues cross certificates.  After months or years of 
> > > operation,
> it
> > > revokes one of its cross certificates because the subject's 
> > > operator
> has
> > > gone rogue.  That rogue subject then issues a fraudulent CRL 
> > > Signing certificate with the DN that the superior certificate has 
> > > been using
> to
> > > sign ARL's, a public key which it has newly generated, and various 
> > > extensions including an SKID.  It then issues an updated copy of 
> > > an
> old
> > > ARL under the fraudulent CRL signer's certificate and with an AKID 
> > > matching the fraudulent signer's SKID.  If the rogue can break 
> > > into
> the
> > > repository where the CRL is expected, this fraudulently issued CRL
> will
> > > probably be validated whether it contains an AIA or not.  It will 
> > > certainly pass the "same trust anchor" condition.
> > >         This scenario, in which a rogue CA issues an ARL
> > > certifiying
> > that
> > > its primary certificate has not been revoked and gets the ARL
> accepted,
> > is
> > > possible under "same trust anchor" but not under "signed by path
> > member".
> > 
> > I agree with the validity of this scenario. I believe this is very 
> > close to the issue I attempted to bring on the list a short time 
> > ago. Of course, it assumes the existence of a rogue CA at some point 
> > in
> time.
> > 
> > Note that the CRL could be directly inserted into a "long term" 
> > signature (according to RFC3126 for example). This does not require 
> > a repository break-in and makes the "attack" even more realistic.
> > 
> > Regards.
> > 
> > --
> > Julien Stern
> > 
> > >
> > >                 Tom Gindin
> > >
> > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
> -----
> > >
> > >
> > > Tom Gindin
> > > 05/23/2005 10:46 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> [email-masked],
> > > [email-masked]
> > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > >         Subject:        Re: WG Last Call: AIA CRL extension
> > >
> > >         Tim:
> > >
> > >         I should probably have brought this up earlier, but are we
> > certain
> > > that "same trust anchor" is a strong enough check that the CRL
> signer is
> > > the one expected by the issuing CA?  While I was not in San Diego
> when
> > > this wording was included in the 3280 series, I do not really 
> > > think
> that
> > > that check is strong enough.  I would suggest instead that the CRL 
> > > signer's certificate needs to be directly issued by one of the 
> > > CA's
> in
> > the
> > > certification path back to the trust anchor used for the
> certificate's
> > > verification, or by that anchor itself, unless people have 
> > > practical experience with CA structures which that rule would 
> > > prohibit.
> Forcing
> > the
> > > CRL to be issued by the CA itself (as I understand Denis to have
> > > suggested) prohibits the reasonable case where the CRL is issued 
> > > by
> a
> > > hierarchical superior, so it is IMHO too strict.
> > >         I am personally not sure, FWIW, that a CRL should be
> permitted
> > to
> > > be signed by a second-cousin certificate of the issuer's
> certificate.
> > By
> > > analogy to the use of the terms in families, "sibling" 
> > > certificates
> > would
> > > have the same issuer, "first-cousin" certificates would be issued 
> > > by siblings, and "second-cousin" certificates would be issued by 
> > > first cousins - so they are both three levels down from the same 
> > > trust
> anchor,
> > > or from the last common CA in their paths.  This issue is not 
> > > newly
> > caused
> > > by CRL AIA, since the same issue can arise with CRL's containing
> only
> > > AKID.  AIA only allows RP's to build a path (whether right or
> > > wrong)
> > more
> > > quickly.
> > >         In any case, nothing more than a note in Security
> Considerations
> > > is appropriate in any of our RFC's other than 3280 and its
> successor.
> > >
> > >         Tom Gindin
> > > P.S. -  The above views are mine, and not necessarily those of my
> > employer
> > >
> > >
> > >
> > >
> > >
> > > Tim Polk <[email-masked]>
> > > Sent by: [email-masked]
> > > 05/10/2005 05:27 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> > [email-masked]
> > >         Subject:        WG Last Call: AIA CRL extension
> > >
> > >
> > >
> > >
> > > This message initiates working group Last Call for the 
> > > specification "Internet X.509 Public Key Infrastructure: Authority 
> > > Information
> Access
> > > CRL
> > > Extension".  While some issues raised in the working group are
> > unresolved,
> > >
> > > the editors believe that rough consensus supports the current 
> > > specification.
> > >
> > > The URL for this Internet-Draft is:
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > >
> > > Last Call will run for (at least) two weeks. That is, Last Call 
> > > will
> not
> > > close before May 24.
> > >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > >
> > >
> 

Date: Thu, 26 May 2005 12:15:54 -0700
To: Stephen Farrell <[email-masked]>, Denis Pinkas <[email-masked]>
From: Hoyt L Kesterson II <[email-masked]>
Subject: Re: 3280bis: key usage (13)
Cc: pkix <[email-masked]>
Sender: [email-masked]

Stephen

I am somewhat dismayed at your reaction to the new text in X.509. I am not going to argue with you here (maybe in a bar the next time we run into each other). However, I do want to mention several points.

1) I initiated the change in text because of the various interpretations by implementors that were resulting in non-interoperable implementations. It was a conversation with a PKIXer at a RSA conference a few years ago that caused me to articulate a private concern.

2) The legal community was very confused. There was even a paper castigating the standard developers for mandating that one could not repudiate an action.

3) There were several meetings held where there was significant participation by people in the IETF PKIX group (as well as lawyers). All agreed there was a problem with the published text. Denis and I argued long and hard over wording but we didn't disagree on the need for new text and its general intent.

4) Russ was concerned that change would cause a problem with existing IETF standards and was not too happy with a change to the name of the bit. That's why I put the line in that you referenced. However, that was to grandfather existing text, not to allow new text to continue using the old term and definitions.

5) It is the definition that is important. I recommend that any new text align with the definition in the approved technical corrigenda against the 4th edition and in the upcoming 5th edition.

    hoyt

At 14:49 +0100 5/26/05, Stephen Farrell wrote:
>Denis,
>
> > Please align with the the ISO-ITU text.
>
>Do you mean we should rename the bits and include the
>other new x.509 text? The design team were against
>doing that.
>
>Is there any (good) reason other than alignment to
>make such a change?
>
>Personally, I find the new x.509 text worse, although
>it does say: "Note that it is not incorrect to refer to
>this keyUsage bit using the identifier nonRepudiation."
>So I can argue that we are aligned, just not identical.
>
>But of course, I'm from the non-repudiation is non-sense
>camp so I may not be the best judge.
>
>Stephen.
>
>PS: A quibble:
>
>>   The new text in X.509 aligns with the text in RFC 3280.  No changes
>>   are required to 3280bis.  A comment has been added to the ASN.1 for
>>   KeyUsage stating that "recent editions of X.509 have renamed
>>   [the nonRepudiation] bit to contentCommitment"
>>
>> This statement is untrue.
>
>The paragraph to which I assume you refer contains 3
>statements - it'd be easier to close these threads if
>you were more precise. (I think I got what you want
>by the end of the mail though...)
>
>PPS: "This statement is untrue."
>     Are you from Crete after all? :-)
>
>
>
>
>Denis Pinkas wrote:
>
>>
>>To the list,
>>
>>The disposition of comments states:
>>
>> 13) The descriptions of the meanings of the digitalSignature and
>>     nonRepudiation bits of keyUsage may need to be adjusted based
>>     on the work in X.509
>>
>>  The new text in X.509 aligns with the text in RFC 3280.  No changes
>>  are required to 3280bis.  A comment has been added to the ASN.1 for
>>  KeyUsage stating that "recent editions of X.509 have renamed
>>  [the nonRepudiation] bit to contentCommitment"
>>
>>This statement is untrue.
>>
>>The text from X.509 has been published in Corrigendum 3 (04/2004)
>>on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
>>
>>ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).
>>
>>An extract from this text is copied below:
>>
>>a) digitalSignature: for verifying digital signatures that are used
>>   with an entity authentication service, a data origin authentication
>>   service or/and an integrity service;
>>
>>b) contentCommitment: for verifying digital signatures which are intended
>>   to signal that the signer is committing to the content being signed.
>>   The type of commitment the certificate can be used to support may be
>>   further constrained by the CA, e.g. through a certificate policy.
>>   The precise type of commitment of the signer e.g. "reviewed and
>>   approved" or "with the intent to be bound", may be signalled by the
>>   content being signed, e.g. the signed document itself or some additional
>>   signed information.
>>
>>   Since a content commitment signing is considered to be a digitally signed
>>   transaction, the digitalSignature bit need not be set in the certificate.
>>   If it is set, it does not affect the level of commitment the signer has
>>   endowed in the signed content.
>>
>>   Note that it is not incorrect to refer to this keyUsage bit using the
>>   identifier nonRepudiation. However, the use of this identifier has been
>>   deprecated. Regardless of the identifier used, the semantics of this bit
>>   are as specified in this Directory Specification.
>>
>>The text from 3280 is copied below:
>>
>>      The digitalSignature bit is asserted when the subject public key
>>      is used with a digital signature mechanism to support security
>>      services other than certificate signing (bit 5), or CRL signing
>>      (bit 6).  Digital signature mechanisms are often used for entity
>>      authentication and data origin authentication with integrity.
>>
>>      The nonRepudiation bit is asserted when the subject public key is
>>      used to verify digital signatures used to provide a non-
>>      repudiation service which protects against the signing entity
>>      falsely denying some action, excluding certificate or CRL signing.
>>      In the case of later conflict, a reliable third party may
>>      determine the authenticity of the signed data.
>>
>>      Further distinctions between the digitalSignature and
>>      nonRepudiation bits may be provided in specific certificate
>>      policies.
>>
>>The text from 3280bis does not align with the ISO-ITU text.
>>Please align with the the ISO-ITU text.
>>
>>Denis

Content-class: urn:content-classes:message
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
Date: Thu, 26 May 2005 19:55:17 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: "Santosh Chokhani" <[email-masked]>, <[email-masked]>, "Julien Stern" <[email-masked]>
Sender: [email-masked]

Tom,

Just Speaking as implementer, MS CAPI will quit and fail the validation
once it detects a loop like this one.

This is also true for indirect loops such as if https access to the CRL
requires the target cert to be established. Such CDP will also be
regarded as invalid.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> From: Tom Gindin [mailto:[email-masked]]
> Sent: den 25 maj 2005 19:22
> To: Stefan Santesson
> Cc: Santosh Chokhani; [email-masked]; Julien Stern
> Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
> 
>         Stefan:
> 
>         I can't find any loop control text on this subject in 3280 or
> 3280-bis.  I don't know what a practical validation library would do
with
> a potential loop like this, and I doubt if anybody who hasn't written
such
> a library knows either.  One of the things it might do is note that
the
> certificate is already being validated and assume that its validation
> result is sufficient.  That avoids the loop, at the cost of letting
this
> certificate through.  Being sure that the library will encounter a
loop
> depends on the library's author interpreting "Obtain and validate the
> certification path for the complete CRL issuer" to include calling a
> revocation check on each element in the path and not assuming that a
bad
> certificate already being validated once will be caught elsewhere in
the
> algorithm.
>         On a related issue, the certpathbuild I-D may be just as
involved
> in our discussions as 3280-bis.  Its security considerations section
on
> CRL signer paths is considerably more elaborate than 3280's
discussion,
> and does not consider that terminating at the same trust anchor is
good
> enough.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> "Stefan Santesson" <[email-masked]>
> 05/25/2005 02:17 PM
> 
>         To:     Tom Gindin/Watson/IBM@IBMUS, "Santosh Chokhani"
> <[email-masked]>
>         cc:     <[email-masked]>, "Julien Stern"
> <[email-masked]>
>         Subject:        RE: CRL Issue (Was RE: WG Last Call: AIA CRL
> extension)
> 
> 
> Tom,
> 
> If the substitution would be successful the validation would go into
an
> infinite loop and fail.
> Validation of S's fake CRL requires validation of C's cross
certificate
> to S which triggers another validation of S's fake CRL and so on.
> 
> I think we added some text against infinite loops but I don't have it
> fresh in my memory.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> > On Behalf Of Tom Gindin
> > Sent: den 25 maj 2005 04:50
> > To: Santosh Chokhani
> > Cc: [email-masked]; 'Julien Stern'
> > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
> >
> >
> >         Santosh:
> >
> >         A relatively concrete example would be the following:
> >         Assume a trust anchor called A, and CA it has issued a cross
> > certificate to called C.  Further assume that C uses indirect CRL's,
> and
> > has issued a cross certificate without name constraints to another
CA
> > called S. Then assume that S goes rogue and creates a CRL signing
> > certificate with the same name as C uses for its indirect CRL's (the
> key
> > pair in that certificate is hereinafter called the "rogue CRL
> signer").
> > Further assume that C finds out about this and creates a CRL listing
S
> as
> > revoked, but that S successfully replaces that CRL in the repository
> by
> > one signed by the rogue CRL signer.
> >         Does RFC 3280 path validation consider S invalid?  If so,
> which
> > step loops or fails?  It looks to me like 6.3.3-b-1 passes.  Is
there
> > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3?  If not, what
> else
> > would be likely to cause S to be recognized as invalid?  You could
> > probably patch any difficulties by adding "if the certificate whose
> > revocation is being checked appears in the path, reject it" to
> 6.3.3-f.
> >
> >                 Tom Gindin
> >
> >
> >
> >
> >
> >
> > "Santosh Chokhani" <[email-masked]>
> > 05/24/2005 06:42 PM
> >
> >         To:     Tom Gindin/Watson/IBM@IBMUS, <[email-masked]>
> >         cc:     "'Julien Stern'" <[email-masked]>
> >         Subject:        CRL Issue (Was RE: WG Last Call: AIA CRL
> > extension)
> >
> >
> > Tom,
> >
> >
> > I assume you are talking about CRL certification path solution I
> proposed
> > will not permit the scenario?  I still do not see in your case, if
the
> > Subject CA (cross certified CA) is revoked, you will verify the path
> to it
> > in the first place.  May be I am not understanding your scenario
> properly.
> > How does the revoked CA gets verified?
> >
> >
> > Julien,
> >
> > We have defined and proven the solution for how to do this.  The
> scenario
> > you proposed is not something X.509 worries about (A CA that is
still
> > valid,
> > but has gone bad).
> > On
> > Behalf Of Julien Stern
> > Sent: Tuesday, May 24, 2005 3:49 PM
> > To: Stefan Santesson
> > Cc: Tom Gindin; [email-masked]
> > Subject: Re: WG Last Call: AIA CRL extension
> >
> >
> >
> > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> > > Tom and Julien,
> > >
> > > Since this is a repetition of the discussion we had before San
Diego
> > > and I don't want to repeat it here. I'm not saying that this
> > > discussion is invalid; it is just directed towards the wrong
draft.
> >
> > Stefan,
> >
> > I agree with you. Actually, I would tend to believe that a _real_
> > discussion
> > would have to take place at some point regarding the overall
security
> > model
> > of CRL validation, but I have absolutely no objection to the AIA, as
> soon
> > as
> > it is made clear that it's only goal is to simplify path building
> > implementations, and not to adress security issues. My very humble
> take on
> > the subject is that Denis and yourself have been arguing on the list
> on
> > absolutely valid but different matters.
> >
> > So, I chose not to comment expect for my last mail (and will not any
> more)
> > about AIA, but I still think that a discusssion regarding revocation
> > validation should take place for RFC3280bis, eventually.
> >
> > Regards,
> >
> > --
> > Julien Stern
> >
> > >
> > > As Tom pointed out:
> > > > this fraudulently issued CRL will probably be validated whether
it
> > > > contains an AIA or not.
> > >
> > > This indicates once again that this is not an issue caused by the
> use
> > > of AIA in CRLs but a generic CRL validation issue that belongs
with
> > > RFC 3280bis and not with the CRL-AIA draft.
> > >
> > > Stefan Santesson
> > > Program Manager, Standards Liaison
> > > Windows Security
> > >
> > >
> > > > On Behalf Of Julien Stern
> > > > Sent: den 24 maj 2005 09:39
> > > > To: Tom Gindin
> > > > Cc: [email-masked]
> > > > Subject: Re: WG Last Call: AIA CRL extension
> > > >
> > > >
> > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > > > >
> > > > >         There is one scenario permitted by the "same trust
> anchor"
> > > rule
> > > > > for CRL signers which seems to me to be a serious security
hole.
> > > Let us
> > > > > assume a valid CA which is a direct subordinate of one of the
> RP's
> > > trust
> > > > > anchors.  This CA issues separate CRL's and ARL's, in a quite
> > > > > usual
> > > way,
> > > > > and issues cross certificates.  After months or years of
> > > > > operation,
> > > it
> > > > > revokes one of its cross certificates because the subject's
> > > > > operator
> > > has
> > > > > gone rogue.  That rogue subject then issues a fraudulent CRL
> > > > > Signing certificate with the DN that the superior certificate
> has
> > > > > been using
> > > to
> > > > > sign ARL's, a public key which it has newly generated, and
> various
> > > > > extensions including an SKID.  It then issues an updated copy
of
> > > > > an
> > > old
> > > > > ARL under the fraudulent CRL signer's certificate and with an
> AKID
> > > > > matching the fraudulent signer's SKID.  If the rogue can break
> > > > > into
> > > the
> > > > > repository where the CRL is expected, this fraudulently issued
> CRL
> > > will
> > > > > probably be validated whether it contains an AIA or not.  It
> will
> > > > > certainly pass the "same trust anchor" condition.
> > > > >         This scenario, in which a rogue CA issues an ARL
> > > > > certifiying
> > > > that
> > > > > its primary certificate has not been revoked and gets the ARL
> > > accepted,
> > > > is
> > > > > possible under "same trust anchor" but not under "signed by
path
> > > > member".
> > > >
> > > > I agree with the validity of this scenario. I believe this is
very
> > > > close to the issue I attempted to bring on the list a short time
> > > > ago. Of course, it assumes the existence of a rogue CA at some
> point
> > > > in
> > > time.
> > > >
> > > > Note that the CRL could be directly inserted into a "long term"
> > > > signature (according to RFC3126 for example). This does not
> require
> > > > a repository break-in and makes the "attack" even more
realistic.
> > > >
> > > > Regards.
> > > >
> > > > --
> > > > Julien Stern
> > > >
> > > > >
> > > > >                 Tom Gindin
> > > > >
> > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13
AM
> > > -----
> > > > >
> > > > >
> > > > > Tom Gindin
> > > > > 05/23/2005 10:46 PM
> > > > >
> > > > >         To:     [email-masked]
> > > > >         cc:     [email-masked], [email-masked],
> > > [email-masked],
> > > > > [email-masked]
> > > > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > > > >         Subject:        Re: WG Last Call: AIA CRL extension
> > > > >
> > > > >         Tim:
> > > > >
> > > > >         I should probably have brought this up earlier, but
are
> we
> > > > certain
> > > > > that "same trust anchor" is a strong enough check that the CRL
> > > signer is
> > > > > the one expected by the issuing CA?  While I was not in San
> Diego
> > > when
> > > > > this wording was included in the 3280 series, I do not really
> > > > > think
> > > that
> > > > > that check is strong enough.  I would suggest instead that the
> CRL
> > > > > signer's certificate needs to be directly issued by one of the
> > > > > CA's
> > > in
> > > > the
> > > > > certification path back to the trust anchor used for the
> > > certificate's
> > > > > verification, or by that anchor itself, unless people have
> > > > > practical experience with CA structures which that rule would
> > > > > prohibit.
> > > Forcing
> > > > the
> > > > > CRL to be issued by the CA itself (as I understand Denis to
have
> > > > > suggested) prohibits the reasonable case where the CRL is
issued
> > > > > by
> > > a
> > > > > hierarchical superior, so it is IMHO too strict.
> > > > >         I am personally not sure, FWIW, that a CRL should be
> > > permitted
> > > > to
> > > > > be signed by a second-cousin certificate of the issuer's
> > > certificate.
> > > > By
> > > > > analogy to the use of the terms in families, "sibling"
> > > > > certificates
> > > > would
> > > > > have the same issuer, "first-cousin" certificates would be
> issued
> > > > > by siblings, and "second-cousin" certificates would be issued
by
> > > > > first cousins - so they are both three levels down from the
same
> > > > > trust
> > > anchor,
> > > > > or from the last common CA in their paths.  This issue is not
> > > > > newly
> > > > caused
> > > > > by CRL AIA, since the same issue can arise with CRL's
containing
> > > only
> > > > > AKID.  AIA only allows RP's to build a path (whether right or
> > > > > wrong)
> > > > more
> > > > > quickly.
> > > > >         In any case, nothing more than a note in Security
> > > Considerations
> > > > > is appropriate in any of our RFC's other than 3280 and its
> > > successor.
> > > > >
> > > > >         Tom Gindin
> > > > > P.S. -  The above views are mine, and not necessarily those of
> my
> > > > employer
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Tim Polk <[email-masked]>
> > > > > Sent by: [email-masked]
> > > > > 05/10/2005 05:27 PM
> > > > >
> > > > >         To:     [email-masked]
> > > > >         cc:     [email-masked], [email-masked],
> > > > [email-masked]
> > > > >         Subject:        WG Last Call: AIA CRL extension
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > This message initiates working group Last Call for the
> > > > > specification "Internet X.509 Public Key Infrastructure:
> Authority
> > > > > Information
> > > Access
> > > > > CRL
> > > > > Extension".  While some issues raised in the working group are
> > > > unresolved,
> > > > >
> > > > > the editors believe that rough consensus supports the current
> > > > > specification.
> > > > >
> > > > > The URL for this Internet-Draft is:
> > > > >
> > > > >
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > > > >
> > > > > Last Call will run for (at least) two weeks. That is, Last
Call
> > > > > will
> > > not
> > > > > close before May 24.
> > > > > Thanks,
> > > > > Tim Polk

From: "Santosh Chokhani" <[email-masked]>
To: "'pgut001'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Comments on / suggested changes for RFC3280bis
Date: Thu, 26 May 2005 12:40:31 -0400
Importance: Normal
Sender: [email-masked]

Peter Guttman,

The KIDs are there for us to have fun.  No just kidding.  They are there for
performance enhancement during certification path development and should
play no role in path validation.

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Thursday, May 26, 2005 12:27 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Comments on / suggested changes for RFC3280bis

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

>Location: 4.2.1.2, 2nd para, last sentence
>Original Text: "Applications are not required to verify that key 
>identifiers match when performing certification path validation."
>Recommendation: "Applications SHOULD NOT verify that key identifiers 
>match when performing certification path validation."
>Reason: Key identifier matching is not part of determining whether or 
>not a certification path is valid.

I hate to be the guy who always has to ask the blindingly obvious questions,
but if they're not required and SHOULD NOT be used, why are they there in
the first place?

(I know the answer to this question, but I'm interested in seeing what
responses are provided).

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on / suggested changes for RFC3280bis
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 27 May 2005 04:27:23 +1200
Sender: [email-masked]

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

>Location: 4.2.1.2, 2nd para, last sentence
>Original Text: "Applications are not required to verify that key identifiers
>match when performing certification path validation."
>Recommendation: "Applications SHOULD NOT verify that key identifiers match
>when performing certification path validation."
>Reason: Key identifier matching is not part of determining whether or not a
>certification path is valid.

I hate to be the guy who always has to ask the blindingly obvious questions,
but if they're not required and SHOULD NOT be used, why are they there in the
first place?

(I know the answer to this question, but I'm interested in seeing what
 responses are provided).

Peter.

Date: Thu, 26 May 2005 12:22:30 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: [draft-ietf-pkix-sim-04.txt]
Cc: [email-masked]
Sender: [email-masked]

Peter:

SFL uses enhanced SNACC, which is freeware and it only supports the 1988 
syntax.

I do not think it is laziness.  However, I am not going to be dragged down 
that rat hole.

Russ

At 10:34 AM 5/26/2005, Peter Gutmann wrote:
>Russ Housley <[email-masked]> writes:
>
> >It is not fair to abuse new authors for following long-standing PKIX and
> >S/MIME WG convention.  These WGs have chosen to use the 1988 ASN.1 syntax
> >because there are free tools that support it.   If you have information 
> about
> >freeware tools that support the later syntax, please let us know.
>
>These WGs have chosen to use the obsolete 1988 ASN.1 syntax because they
>couldn't be bothered learning anything newer.  The (un)availability of
>freeware tools is merely the most convenient red herring available to support
>this position.  I'n not aware of a single OSS/freeware project that is
>hampered by the unavailability of freeware ASN.1 tools (the only project of
>this kind that I know of that even uses one is SFL, and that doesn't seem to
>have any problems).
>
>Peter.

From: "Peter Hesse" <[email-masked]>
To: <[email-masked]>, "'David A. Cooper'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Zagar, Terry (Mission Systems)'" <[email-masked]>, "'Guy Tallent [SIG] (E-mail)'" <[email-masked]>, "'Gary Secrest [JJCUS] (E-mail)'" <[email-masked]>
Subject: Comments on / suggested changes for RFC3280bis
Date: Thu, 26 May 2005 11:14:27 -0400
Sender: [email-masked]

PKIX list and RFC3280bis editors,
 
I apologize in advance for the length of this message.  Below are comments
on the RFC3280bis draft developed on behalf of Gemini Security and the
SAFE-Biopharma Association.  The SAFE-Biopharma Association's mission is to
deliver unique electronic identity credentials for strong authentication and
for the application of digital signatures for use in electronic systems and
transactions across the bio-pharmaceutical industry.  The SAFE-Biopharma
Association manages the SAFE digital signature standard and associated
operating policies for its Members, which include the world's leading
biopharmaceutical companies, their business partners, and regulatory
agencies.

This message contains specific comments on and suggested changes to the
RFC3280bis draft.  For the most part these changes are meant to clarify and
normalize the language used to specify required behavior of certificate
processing systems and CAs/CRL issuers.  Some additional changes are
requested and reasons for them are also given.
 
A real-world example of the unclear language related to behavior causing a
problem: RFC3280 specified that the inhibitAnyPolicy extension be marked
critical.  At least one version of the Sun Java CertPath implementation
rejects any certification paths containing inhibitAnyPolicy extensions which
are not marked critical.  The wording in RFC3280 was not clear that this was
a requirement for issuers and not for implementations.  (This issue has been
fixed the current RFC3280bis draft, but remains in other places for other
extensions.)
 
I will also be providing these changes in a Word document with tracked
changes to David Cooper for his use in developing the next draft.  See below
for the actual comments.  I appreciate your willingness to consider these
changes for the next draft. 
 
Sincerely,
 
Peter Hesse
 
------------------------------------------------
 
Location: 3.3, 4th para, 6th line
Original Text: "all currently issued CRLs are updated"
Recommendation: "all currently issued CRLs are scheduled to be updated".
Reason: Whether or not the CRL is updated doesn't affect notification, it is
whether a scheduled update (specified in nextUpdate) was due to occur.
 
Location: 4.2, 2nd para, last sentence
Original Text: "The text for each extension specifies the acceptable values
for the critical field."
Recommendation: "The text for each extension specifies the acceptable values
for conforming CAs and CRL Issuers to place in the critical field.
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.1, 5th para 
Original Text: "This extension MUST NOT be marked critical."
Recommendation: "Conforming CAs MUST mark this extension non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.2, 2nd para, last sentence
Original Text: "Applications are not required to verify that key identifiers
match when performing certification path validation."
Recommendation: "Applications SHOULD NOT verify that key identifiers match
when performing certification path validation."
Reason: Key identifier matching is not part of determining whether or not a
certification path is valid.
 
Location: 4.2.1.2, next-to-last para
Original Text: "This extension MUST NOT be marked critical."
Recommendation:" Conforming CAs MUST mark this extension non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.3, 2nd para, last sentence
Original Text: "When this extension appears, it SHOULD be marked critical."
Recommendation: "When this extension appears, conforming CAs SHOULD mark it
critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.4, 3rd para, last sentence
Original Text: "If this extension is critical, the path validation software
MUST be able to interpret this extension (including the optional qualifier),
or MUST reject the certificate."
Comment: This sentence seems like an unnecessary repetition of the behavior
required on all extensions, specified in the first para of 4.2.  I recommend
this sentence be removed.
 
Location: 4.2.1.5, 5th para
Original Text: "This extension MAY be supported by CAs and/or applications,
and it SHOULD be critical."
Recommendation: "This extension MAY be supported by CAs and/or applications,
and conforming CAs SHOULD mark this extension critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.6, 3rd para, last sentence
Original Text: "If the subject field contains an empty sequence, the
subjectAltName extension MUST be marked critical."
Recommendation: Add the following sentence.  "Otherwise, conforming CAs
SHOULD mark this extension non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.7, 2nd para
Original Text: "Where present, this extension SHOULD NOT be marked
critical."
Recommendation: "Where present, conforming CAs SHOULD mark this extension
non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.9, 4th para, 1st sentence
Original Text: "This extension MUST appear in all CA certificates that
contain public keys used to validate digital signatures on certificates."
Recommendation: "Conforming CAs must place this extension in all CA
certificates that contain public keys used to validate digital signatures on
certificates."
Reason: This statement is in conflict with the statement "verify that
certificate i is a CA certificate through out-of-band means" in section
6.1.4.
 
Location: 4.2.1.9, 4th para, 3rd sentence
Original Text: "This extension MAY appear as a critical or non-critical
extension in CA certificates that contain public keys..."
Recommendation: "Conforming CAs MAY mark this extension as critical or
non-critical in CA certificates that contain public keys..."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.9, 4th para, last sentence
Original Text: "This extension MAY appear as a critical or non-critical
extension in end entity certificates."
Recommendation: "Conforming CAs MAY mark this extension as critical or
non-critical in end entity certificates."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.11, 4th para, last sentence
Original Text: "If the policyConstraints extension is marked critical and
the inhibitPolicyMapping field is present, applications that do not
implement support for the inhibitPolicyMapping field MUST reject the
certificate."
Comment: This seems to be encouraging different behavior depending on the
criticality of the field, which goes against the spirit of extension
processing.
 
Location: 4.2.1.12, 6th para
Original Text: "This extension MAY, at the option of the certificate issuer,
be either critical or non-critical."
Recommendation: "Conforming CAs MAY mark this extension either critical or
non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) &
normalization of text
 
Location: 4.2.1.12, 8th para
Original Text: "If the anyExtendedKeyUsage keyPurposeID is present, the
extension SHOULD NOT be critical."
Recommendation: "If the anyExtendedKeyUsage keyPurposeID is present,
conforming CAs SHOULD NOT mark this extension critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.13, 1st para, 2nd sentence
Original Text: "The extension SHOULD be non-critical,"
Recommendation: "Conforming CAs SHOULD mark this extension non-critical,"
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.13, 2nd para, 4th sentence
Original Text: "...not the CRL issuer, then the cRLIssuer field MUST be
present and contain the Name of the CRL issuer."
Recommendation: "...not the CRL issuer, then conforming CAs MUST include the
cRLIssuer field containing the Name of the CRL issuer."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.13, 2nd para, 5th sentence
Original Text: "...is also the CRL issuer, then the cRLIssuer field MUST be
omitted and the distributionPoint field MUST be present."
Recommendation: "...is also the CRL issuer, then conforming CAs MUST omit
the cRLIssuer field and MUST include the distributionPoint field."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.13, 2nd para, last sentence
Original Text: "If the distributionPoint field is omitted, cRLIssuer MUST be
present and include a Name..."
Recommendation: "If the distributionPoint field is omitted, conforming CAs
MUST include the cRLIssuer field and include a Name..."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 4.2.1.13, 5th para, last sentence
Original Text: "DistributionPointName SHOULD include at least one LDAP or
HTTP URI."
Recommendation: Add the following sentence. "If both HTTP and LDAP
DistributionPointName URI values are specified, the HTTP
DistributionPointName SHOULD appear first."
Reason: Firewalls are more likely to allow HTTP through, and HTTP typically
results in faster access.  Applications typically try distribution points in
the order in which they appear.
 
Location: 4.2.2.1, 13th para, 2nd sentence
Original Text: "...and MAY specify a host name (e.g.,
ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?cACertificate;bina
ry,crossCertificatePair;binary).
Recommendation: remove ",crossCertificatePair;binary" from the example
Reason: Attributes containing cross-certificate pairs should not be
recommended.  There is no way for the client to know whether or not they
will be encountering cross-certificate pairs as opposed to certificates,
without attempting to decode them and failing.  Retrieving only
cACertificate attribute should be sufficient if LDAPv3 schema is being
followed.
 
Location: 4.2.2.1, 13th para, last sentence
Original Text: "The URI MUST list appropriate attribute descriptions for one
or more attributes holding DER [X.690] encoded certificates or
cross-certificate pairs."
Recommendation: remove "or cross-certificate pairs"
Reason: Same as above (4.2.2.1, 13th para, 2nd sentence).
 
Location: 4.2.2.1, 16th para
Original Text: " .p7c   A DER encoded "certs-only" CMS message as specified
in [RFC 2797]."
Recommendation: " .p7c   A DER encoded "certs-only" CMS message as specified
in [RFC 2797] which MUST NOT contain self-signed certificates."
Reason: Self-signed certificates retrieved externally should not be included
because they cannot be trusted,
 
Location: 4.2.2.1, 18th para
Original Text: "The semantics of other id-ad-caIssuers accessLocation name
forms are not defined."
Recommendation: Add a new paragraph before this one: "If both HTTP and LDAP
accessLocations are specified, the HTTP accessLocation SHOULD appear first."
Reason: Same as above (4.2.1.13, 5th para, last sentence).
 
Location: 4.2.2.2, 9th para, 2nd sentence
Original Text: "...and MAY specify a host name (e.g.,
ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?cACertificate;bina
ry,crossCertificatePair;binary).
Recommendation: remove ",crossCertificatePair;binary" from the example
Reason: Same as above (4.2.2.1, 13th para, 2nd sentence).
 
Location: 4.2.2.2, 9th para, last sentence
Original Text: "The URI MUST list appropriate attribute descriptions for one
or more attributes holding DER [X.690] encoded certificates or
cross-certificate pairs."
Recommendation: remove "or cross-certificate pairs"
Reason: Same as above (4.2.2.1, 13th para, 2nd sentence).
 
Location: 4.2.2.2, 12th para
Original Text: " .p7c   A DER encoded "certs-only" CMS message as specified
in [RFC 2797]."
Recommendation: " .p7c   A DER encoded "certs-only" CMS message as specified
in [RFC 2797] which MUST NOT contain self-signed certificates."
Reason: Self-signed certificates retrieved externally should not be included
because they cannot be trusted,
 
Location: 4.2.2.2, 14th para
Original Text: "The semantics of other id-ad-caRepository accessLocation
name forms are not defined."
Recommendation: Add a new paragraph before this one: "If both HTTP and LDAP
accessLocations are specified, the HTTP accessLocation SHOULD appear first."
Reason: Same as above (4.2.1.13, 5th para, last sentence).
 
Location: 5.1.2.5, 2nd para, 1st sentence 
Original Text: "This profile requires inclusion of nextUpdate in all CRLs
issued by conforming CRL issuers." 
Recommendation: "Conforming CRL issuers MUST include the nextUpdate field in
all CRLs."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) &
normalization of text
 
Location: 5.2.2, 2nd para
Original Text: "The issuerAltName extension SHOULD NOT be marked critical."
Recommendation: "Conforming CRL issuers SHOULD NOT mark the issuerAltName
extension critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 5.2.3, 1st para
Original Text: "The CRL number is a non-critical CRL extension which...MUST
include this extension in all CRLs."
Recommendation: "The CRL number is a CRL extension which...MUST include this
extension in all CRLs and MUST mark this extension non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) &
normalization of text
 
Location: 5.2.4, 1st para
Original Text: "The delta CRL indicator is a critical CRL extension
that...the local database without reprocessing information."
Recommendation: "The delta CRL indicator is a CRL extension that...the local
database without reprocessing information.  Conforming CRL issuers MUST mark
the delta CRL indicator extension critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) &
normalization of text
 
Location: 5.2.5, 1st para, 2nd sentence
Original Text: "Although the extension is critical, conforming
implementations are not required to support this extension."
Recommendation: "Conforming CRL Issuers MUST mark this extension critical,
but conforming implementations are not required to support this extension."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 5.2.6, 1st para, 2nd sentence
Original Text: "The extension MUST be non-critical."
Recommendation: "Conforming CRL issuers must mark this extension
non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 5.3.1, 1st para, 1st sentence
Original Text: "The reasonCode is a non-critical CRL entry extension that
identifies the reason for the certificate revocation."
Recommendation: "The reasonCode is a CRL entry extension that identifies the
reason for the certificate revocation.  Conforming CRL issuers MUST mark
this entry extension non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 5.3.2, 1st para
Original Text: "The hold instruction code is a non-critical CRL entry
extension that...placed on hold."
Recommendation: "The hold instruction code is a CRL entry extension
that...placed on hold. Conforming CRL issuers MUST mark this entry extension
non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 5.3.3, 1st para 
Original Text: "The invalidity date is a non-critical CRL entry extension
that...to share it with CRL users."
Recommendation: "The invalidity date is a CRL entry extension that...to
share it with CRL users.  Conforming CRL issuers MUST mark this entry
extension non-critical."
Reason: Clarification of behavior (CA/CRL Issuer vs. processing system)
 
Location: 5.3.4, 5th para, 1st sentence 
Original Text: "If used by conforming CRL issuers, this extension MUST
always be critical."
Recommendation: "If used by conforming CRL issuers, this extension MUST be
marked critical."
Reason: Normalization of text

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [draft-ietf-pkix-sim-04.txt]
Cc: [email-masked], [email-masked]
Date: Fri, 27 May 2005 02:34:13 +1200
Sender: [email-masked]

Russ Housley <[email-masked]> writes:

>It is not fair to abuse new authors for following long-standing PKIX and
>S/MIME WG convention.  These WGs have chosen to use the 1988 ASN.1 syntax
>because there are free tools that support it.   If you have information about
>freeware tools that support the later syntax, please let us know.

These WGs have chosen to use the obsolete 1988 ASN.1 syntax because they
couldn't be bothered learning anything newer.  The (un)availability of
freeware tools is merely the most convenient red herring available to support
this position.  I'n not aware of a single OSS/freeware project that is
hampered by the unavailability of freeware ASN.1 tools (the only project of
this kind that I know of that even uses one is SFL, and that doesn't seem to
have any problems).

Peter.

Date: Thu, 26 May 2005 10:01:14 -0400
To: Olivier Dubuisson <[email-masked]>, Andrew Sciberras <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: [draft-ietf-pkix-sim-04.txt]
Cc: Jaeho Yoon <[email-masked]>, [email-masked]
Sender: [email-masked]

It is not fair to abuse new authors for following long-standing PKIX and 
S/MIME WG convention.  These WGs have chosen to use the 1988 ASN.1 syntax 
because there are free tools that support it.   If you have information 
about freeware tools that support the later syntax, please let us know.

Russ

At 02:53 AM 5/26/2005, Olivier Dubuisson wrote:
>Why redefine the UTF8String instead of using the one standardized in the
>ASN.1 standard?

Date: Thu, 26 May 2005 14:49:31 +0100
From: Stephen Farrell <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: 3280bis: key usage (13)
Sender: [email-masked]

Denis,

 > Please align with the the ISO-ITU text.

Do you mean we should rename the bits and include the
other new x.509 text? The design team were against
doing that.

Is there any (good) reason other than alignment to
make such a change?

Personally, I find the new x.509 text worse, although
it does say: "Note that it is not incorrect to refer to
this keyUsage bit using the identifier nonRepudiation."
So I can argue that we are aligned, just not identical.

But of course, I'm from the non-repudiation is non-sense
camp so I may not be the best judge.

Stephen.

PS: A quibble:

 >   The new text in X.509 aligns with the text in RFC 3280.  No changes
 >   are required to 3280bis.  A comment has been added to the ASN.1 for
 >   KeyUsage stating that "recent editions of X.509 have renamed
 >   [the nonRepudiation] bit to contentCommitment"
 >
 > This statement is untrue.

The paragraph to which I assume you refer contains 3
statements - it'd be easier to close these threads if
you were more precise. (I think I got what you want
by the end of the mail though...)

PPS: "This statement is untrue."
      Are you from Crete after all? :-)

Denis Pinkas wrote:

> 
> To the list,
> 
> The disposition of comments states:
> 
>  13) The descriptions of the meanings of the digitalSignature and
>      nonRepudiation bits of keyUsage may need to be adjusted based
>      on the work in X.509
> 
>   The new text in X.509 aligns with the text in RFC 3280.  No changes
>   are required to 3280bis.  A comment has been added to the ASN.1 for
>   KeyUsage stating that "recent editions of X.509 have renamed
>   [the nonRepudiation] bit to contentCommitment"
> 
> This statement is untrue.
> 
> The text from X.509 has been published in Corrigendum 3 (04/2004)
> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
> 
> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).
> 
> An extract from this text is copied below:
> 
> a) digitalSignature: for verifying digital signatures that are used
>    with an entity authentication service, a data origin authentication
>    service or/and an integrity service;
> 
> b) contentCommitment: for verifying digital signatures which are intended
>    to signal that the signer is committing to the content being signed.
>    The type of commitment the certificate can be used to support may be
>    further constrained by the CA, e.g. through a certificate policy.
>    The precise type of commitment of the signer e.g. "reviewed and
>    approved" or "with the intent to be bound", may be signalled by the
>    content being signed, e.g. the signed document itself or some additional
>    signed information.
> 
>    Since a content commitment signing is considered to be a digitally 
> signed
>    transaction, the digitalSignature bit need not be set in the 
> certificate.
>    If it is set, it does not affect the level of commitment the signer has
>    endowed in the signed content.
> 
>    Note that it is not incorrect to refer to this keyUsage bit using the
>    identifier nonRepudiation. However, the use of this identifier has been
>    deprecated. Regardless of the identifier used, the semantics of this bit
>    are as specified in this Directory Specification.
> 
> The text from 3280 is copied below:
> 
>       The digitalSignature bit is asserted when the subject public key
>       is used with a digital signature mechanism to support security
>       services other than certificate signing (bit 5), or CRL signing
>       (bit 6).  Digital signature mechanisms are often used for entity
>       authentication and data origin authentication with integrity.
> 
>       The nonRepudiation bit is asserted when the subject public key is
>       used to verify digital signatures used to provide a non-
>       repudiation service which protects against the signing entity
>       falsely denying some action, excluding certificate or CRL signing.
>       In the case of later conflict, a reliable third party may
>       determine the authenticity of the signed data.
> 
>       Further distinctions between the digitalSignature and
>       nonRepudiation bits may be provided in specific certificate
>       policies.
> 
> The text from 3280bis does not align with the ISO-ITU text.
> Please align with the the ISO-ITU text.
> 
> Denis
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
Date: Thu, 26 May 2005 08:03:26 -0400
Importance: Normal
Sender: [email-masked]

Tom and Stefan,

See below in [Santosh:]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Wednesday, May 25, 2005 10:22 PM
To: Stefan Santesson
Cc: Santosh Chokhani; [email-masked]; Julien Stern
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)

        Stefan:

        I can't find any loop control text on this subject in 3280 or 
3280-bis.  I don't know what a practical validation library would do with 
a potential loop like this, and I doubt if anybody who hasn't written such 
a library knows either.

[Santosh: We at Orion has developed a library called PKIF for USMC that
exactly does this.  We found this circularity problem and our library went
into neverland with infinite loop and we added loop control logic.  So,
saying that no one does or understands these things is dangerous and wrong
in this case.]

  One of the things it might do is note that the 
certificate is already being validated and assume that its validation 
result is sufficient.  That avoids the loop, at the cost of letting this 
certificate through.  Being sure that the library will encounter a loop 
depends on the library's author interpreting "Obtain and validate the 
certification path for the complete CRL issuer" to include calling a 
revocation check on each element in the path and not assuming that a bad 
certificate already being validated once will be caught elsewhere in the 
algorithm.

[Santosh: If I understand the above, be assured that X.509 requires that a
CRL signature be verified using a public key that is fully validated per the
X.509 certification path validation requirement, including revocation status
checking of all the certificates in the CRL certification path]

        On a related issue, the certpathbuild I-D may be just as involved 
in our discussions as 3280-bis.  Its security considerations section on 
CRL signer paths is considerably more elaborate than 3280's discussion, 
and does not consider that terminating at the same trust anchor is good 
enough.

                Tom Gindin

"Stefan Santesson" <[email-masked]>
05/25/2005 02:17 PM
 
        To:     Tom Gindin/Watson/IBM@IBMUS, "Santosh Chokhani" 
<[email-masked]>
        cc:     <[email-masked]>, "Julien Stern" 
<[email-masked]>
        Subject:        RE: CRL Issue (Was RE: WG Last Call: AIA CRL 
extension)

Tom,

If the substitution would be successful the validation would go into an
infinite loop and fail. Validation of S's fake CRL requires validation of
C's cross certificate to S which triggers another validation of S's fake CRL
and so on.

I think we added some text against infinite loops but I don't have it fresh
in my memory.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> On Behalf Of Tom Gindin
> Sent: den 25 maj 2005 04:50
> To: Santosh Chokhani
> Cc: [email-masked]; 'Julien Stern'
> Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
> 
> 
>         Santosh:
> 
>         A relatively concrete example would be the following:
>         Assume a trust anchor called A, and CA it has issued a cross 
> certificate to called C.  Further assume that C uses indirect CRL's,
and
> has issued a cross certificate without name constraints to another CA 
> called S. Then assume that S goes rogue and creates a CRL signing 
> certificate with the same name as C uses for its indirect CRL's (the
key
> pair in that certificate is hereinafter called the "rogue CRL
signer").
> Further assume that C finds out about this and creates a CRL listing S
as
> revoked, but that S successfully replaces that CRL in the repository
by
> one signed by the rogue CRL signer.
>         Does RFC 3280 path validation consider S invalid?  If so,
which
> step loops or fails?  It looks to me like 6.3.3-b-1 passes.  Is there 
> always a bi-modal loop between 6.3.3-f and 6.1.3-a-3?  If not, what
else
> would be likely to cause S to be recognized as invalid?  You could 
> probably patch any difficulties by adding "if the certificate whose 
> revocation is being checked appears in the path, reject it" to
6.3.3-f.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>
> 05/24/2005 06:42 PM
> 
>         To:     Tom Gindin/Watson/IBM@IBMUS, <[email-masked]>
>         cc:     "'Julien Stern'" <[email-masked]>
>         Subject:        CRL Issue (Was RE: WG Last Call: AIA CRL
> extension)
> 
> 
> Tom,
> 
> 
> I assume you are talking about CRL certification path solution I
proposed
> will not permit the scenario?  I still do not see in your case, if the 
> Subject CA (cross certified CA) is revoked, you will verify the path
to it
> in the first place.  May be I am not understanding your scenario
properly.
> How does the revoked CA gets verified?
> 
> 
> Julien,
> 
> We have defined and proven the solution for how to do this.  The
scenario
> you proposed is not something X.509 worries about (A CA that is still 
> valid, but has gone bad).
> 
> On
> Behalf Of Julien Stern
> Sent: Tuesday, May 24, 2005 3:49 PM
> To: Stefan Santesson
> Cc: Tom Gindin; [email-masked]
> Subject: Re: WG Last Call: AIA CRL extension
> 
> 
> 
> On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> > Tom and Julien,
> >
> > Since this is a repetition of the discussion we had before San Diego 
> > and I don't want to repeat it here. I'm not saying that this 
> > discussion is invalid; it is just directed towards the wrong draft.
> 
> Stefan,
> 
> I agree with you. Actually, I would tend to believe that a _real_ 
> discussion would have to take place at some point regarding the 
> overall security model
> of CRL validation, but I have absolutely no objection to the AIA, as
soon
> as
> it is made clear that it's only goal is to simplify path building 
> implementations, and not to adress security issues. My very humble
take on
> the subject is that Denis and yourself have been arguing on the list
on
> absolutely valid but different matters.
> 
> So, I chose not to comment expect for my last mail (and will not any
more)
> about AIA, but I still think that a discusssion regarding revocation 
> validation should take place for RFC3280bis, eventually.
> 
> Regards,
> 
> --
> Julien Stern
> 
> >
> > As Tom pointed out:
> > > this fraudulently issued CRL will probably be validated whether it 
> > > contains an AIA or not.
> >
> > This indicates once again that this is not an issue caused by the
use
> > of AIA in CRLs but a generic CRL validation issue that belongs with 
> > RFC 3280bis and not with the CRL-AIA draft.
> >
> > Stefan Santesson
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> > > On Behalf Of Julien Stern
> > > Sent: den 24 maj 2005 09:39
> > > To: Tom Gindin
> > > Cc: [email-masked]
> > > Subject: Re: WG Last Call: AIA CRL extension
> > >
> > >
> > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > > >
> > > >         There is one scenario permitted by the "same trust
anchor"
> > rule
> > > > for CRL signers which seems to me to be a serious security hole.
> > Let us
> > > > assume a valid CA which is a direct subordinate of one of the
RP's
> > trust
> > > > anchors.  This CA issues separate CRL's and ARL's, in a quite 
> > > > usual
> > way,
> > > > and issues cross certificates.  After months or years of 
> > > > operation,
> > it
> > > > revokes one of its cross certificates because the subject's 
> > > > operator
> > has
> > > > gone rogue.  That rogue subject then issues a fraudulent CRL 
> > > > Signing certificate with the DN that the superior certificate
has
> > > > been using
> > to
> > > > sign ARL's, a public key which it has newly generated, and
various
> > > > extensions including an SKID.  It then issues an updated copy of 
> > > > an
> > old
> > > > ARL under the fraudulent CRL signer's certificate and with an
AKID
> > > > matching the fraudulent signer's SKID.  If the rogue can break 
> > > > into
> > the
> > > > repository where the CRL is expected, this fraudulently issued
CRL
> > will
> > > > probably be validated whether it contains an AIA or not.  It
will
> > > > certainly pass the "same trust anchor" condition.
> > > >         This scenario, in which a rogue CA issues an ARL 
> > > > certifiying
> > > that
> > > > its primary certificate has not been revoked and gets the ARL
> > accepted,
> > > is
> > > > possible under "same trust anchor" but not under "signed by path
> > > member".
> > >
> > > I agree with the validity of this scenario. I believe this is very 
> > > close to the issue I attempted to bring on the list a short time 
> > > ago. Of course, it assumes the existence of a rogue CA at some
point
> > > in
> > time.
> > >
> > > Note that the CRL could be directly inserted into a "long term" 
> > > signature (according to RFC3126 for example). This does not
require
> > > a repository break-in and makes the "attack" even more realistic.
> > >
> > > Regards.
> > >
> > > --
> > > Julien Stern
> > >
> > > >
> > > >                 Tom Gindin
> > > >
> > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
> > -----
> > > >
> > > >
> > > > Tom Gindin
> > > > 05/23/2005 10:46 PM
> > > >
> > > >         To:     [email-masked]
> > > >         cc:     [email-masked], [email-masked],
> > [email-masked],
> > > > [email-masked]
> > > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > > >         Subject:        Re: WG Last Call: AIA CRL extension
> > > >
> > > >         Tim:
> > > >
> > > >         I should probably have brought this up earlier, but are
we
> > > certain
> > > > that "same trust anchor" is a strong enough check that the CRL
> > signer is
> > > > the one expected by the issuing CA?  While I was not in San
Diego
> > when
> > > > this wording was included in the 3280 series, I do not really 
> > > > think
> > that
> > > > that check is strong enough.  I would suggest instead that the
CRL
> > > > signer's certificate needs to be directly issued by one of the 
> > > > CA's
> > in
> > > the
> > > > certification path back to the trust anchor used for the
> > certificate's
> > > > verification, or by that anchor itself, unless people have 
> > > > practical experience with CA structures which that rule would 
> > > > prohibit.
> > Forcing
> > > the
> > > > CRL to be issued by the CA itself (as I understand Denis to have
> > > > suggested) prohibits the reasonable case where the CRL is issued 
> > > > by
> > a
> > > > hierarchical superior, so it is IMHO too strict.
> > > >         I am personally not sure, FWIW, that a CRL should be
> > permitted
> > > to
> > > > be signed by a second-cousin certificate of the issuer's
> > certificate.
> > > By
> > > > analogy to the use of the terms in families, "sibling" 
> > > > certificates
> > > would
> > > > have the same issuer, "first-cousin" certificates would be
issued
> > > > by siblings, and "second-cousin" certificates would be issued by 
> > > > first cousins - so they are both three levels down from the same 
> > > > trust
> > anchor,
> > > > or from the last common CA in their paths.  This issue is not 
> > > > newly
> > > caused
> > > > by CRL AIA, since the same issue can arise with CRL's containing
> > only
> > > > AKID.  AIA only allows RP's to build a path (whether right or
> > > > wrong)
> > > more
> > > > quickly.
> > > >         In any case, nothing more than a note in Security
> > Considerations
> > > > is appropriate in any of our RFC's other than 3280 and its
> > successor.
> > > >
> > > >         Tom Gindin
> > > > P.S. -  The above views are mine, and not necessarily those of
my
> > > employer
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Tim Polk <[email-masked]>
> > > > Sent by: [email-masked]
> > > > 05/10/2005 05:27 PM
> > > >
> > > >         To:     [email-masked]
> > > >         cc:     [email-masked], [email-masked],
> > > [email-masked]
> > > >         Subject:        WG Last Call: AIA CRL extension
> > > >
> > > >
> > > >
> > > >
> > > > This message initiates working group Last Call for the 
> > > > specification "Internet X.509 Public Key Infrastructure:
Authority
> > > > Information
> > Access
> > > > CRL
> > > > Extension".  While some issues raised in the working group are
> > > unresolved,
> > > >
> > > > the editors believe that rough consensus supports the current 
> > > > specification.
> > > >
> > > > The URL for this Internet-Draft is:
> > > >
> > > >
http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > > >
> > > > Last Call will run for (at least) two weeks. That is, Last Call 
> > > > will
> > not
> > > > close before May 24.
> > > >
> > > > Thanks,
> > > >
> > > > Tim Polk
> > > >
> > > >
> > > >
> >
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
Date: Thu, 26 May 2005 07:57:59 -0400
Importance: Normal
Sender: [email-masked]

Tom,

BTW, we may be putting Peter Guttman and rest of the group to sleep again,
which may not be all bad.

You need to provide a clear streamlined scenario.  From what I discern, you
are saying the following.

Root R --> C

C --> C1 as CRL issuer & C --> S and C asserts in S C1.

C1 issues CRL.

S goes rouge.  C instructs C1 to put S on CRLgood.

S --> C1.  Now, the new C1 can issue a CRLbad without S on it.

In order to verify signature on CRLbad, you need the path R --> C --> S -->
C1.  But, note that in order to verify signature on C --> S either you will
find the correct path and CRL (R --> C --> C1 and CRLgood) or you will have
circularity since C-->S require C1 CRL.

There is no sense in having this e-mail discussion unless you lay out the
scenario precisely as above as to what the various certification paths are.

So far, when I fill in the gaps, all I see is circularity issues or what
Stefan calls infinite loops.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Wednesday, May 25, 2005 10:22 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)

        Santosh:

        I thought that I had made that particular issue clear.  The 
indirect CRL being retrieved governs C's certificates and its issuer name 
(call it C1) is supposed to belong to C.  Indeed, C has issued a CRL 
signing certificate with subject name C1.  However, S has created another 
CRL signing certificate with this same subject name and has created a CRL 
with that key pair.  C did not create any circularity.  The original 
certificate for C1 was issued by C and the corresponding private key 
belongs to an entity under C's control, while the new certificate for C1 
was issued by S and the corresponding private key belongs to a malicious 
subsystem inside S.  While certificates are issued to entities, relying 
parties know the name and the chain but not the entity.
        No relevant CRL is issued by S.  I'm sure that your objection to '
looking at CRL issued by C' actually meant 'issued by S', because you 
normally verify certificates by looking at CRL's issued by the certificate 
issuer or its delegate.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
05/25/2005 08:58 AM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: CRL Issue (Was RE: WG Last Call: AIA CRL 
extension)

Tom,

It is not clear from your example who the indirect CRL issuer is and what
role the "indirect CRL" plays in the attack.  If S is the indirect CRL
issuer, C should be smart enough to not create circularity (a good toolkit
will not verify path when C issues a certificate to S and points to S as 
the
indirect CRL issuer since it causes circularity and chicken and egg
problem).  That scenario can be easily rectified within current standard 
by
C not declaring S as the indirect CRL issuer for certificate issued to S. 
C
can declare itself in the CDP or some other issuer.

I suspect you do not mean this.  Your example may be simpler.  To me the
attack is still not plausible.  Your scenario is not detailed enough to
illustrate an attack.  It does not seem that there is a way to validate 
the
certificate issued to C by S without looking at CRL issued by C, resulting
in circularity, which relying party clients should not accept. 

(Note that my November presentation to IETF in DC covered the circularity
issues in CRL and OCSP and recommendations for 3280 and 2560 in addition 
to
the CRL certification path)

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2005 7:50 AM
To: Santosh Chokhani
Cc: [email-masked]; 'Julien Stern'
Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension)

        Santosh:

        A relatively concrete example would be the following:
        Assume a trust anchor called A, and CA it has issued a cross 
certificate to called C.  Further assume that C uses indirect CRL's, and 
has issued a cross certificate without name constraints to another CA 
called S. Then assume that S goes rogue and creates a CRL signing 
certificate with the same name as C uses for its indirect CRL's (the key 
pair in that certificate is hereinafter called the "rogue CRL signer"). 
Further assume that C finds out about this and creates a CRL listing S as 
revoked, but that S successfully replaces that CRL in the repository by 
one signed by the rogue CRL signer.
        Does RFC 3280 path validation consider S invalid?  If so, which 
step loops or fails?  It looks to me like 6.3.3-b-1 passes.  Is there 
always a bi-modal loop between 6.3.3-f and 6.1.3-a-3?  If not, what else 
would be likely to cause S to be recognized as invalid?  You could 
probably patch any difficulties by adding "if the certificate whose 
revocation is being checked appears in the path, reject it" to 6.3.3-f.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
05/24/2005 06:42 PM
 
        To:     Tom Gindin/Watson/IBM@IBMUS, <[email-masked]>
        cc:     "'Julien Stern'" <[email-masked]>
        Subject:        CRL Issue (Was RE: WG Last Call: AIA CRL 
extension)

Tom,

I assume you are talking about CRL certification path solution I proposed
will not permit the scenario?  I still do not see in your case, if the
Subject CA (cross certified CA) is revoked, you will verify the path to it
in the first place.  May be I am not understanding your scenario properly.
How does the revoked CA gets verified?

Julien,

We have defined and proven the solution for how to do this.  The scenario
you proposed is not something X.509 worries about (A CA that is still 
valid,
but has gone bad).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Julien Stern
Sent: Tuesday, May 24, 2005 3:49 PM
To: Stefan Santesson
Cc: Tom Gindin; [email-masked]
Subject: Re: WG Last Call: AIA CRL extension

On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> Tom and Julien,
> 
> Since this is a repetition of the discussion we had before San Diego 
> and I don't want to repeat it here. I'm not saying that this 
> discussion is invalid; it is just directed towards the wrong draft.

Stefan,

I agree with you. Actually, I would tend to believe that a _real_ 
discussion
would have to take place at some point regarding the overall security 
model
of CRL validation, but I have absolutely no objection to the AIA, as soon 
as
it is made clear that it's only goal is to simplify path building
implementations, and not to adress security issues. My very humble take on
the subject is that Denis and yourself have been arguing on the list on
absolutely valid but different matters.

So, I chose not to comment expect for my last mail (and will not any more)
about AIA, but I still think that a discusssion regarding revocation
validation should take place for RFC3280bis, eventually.

Regards,

--
Julien Stern

> 
> As Tom pointed out:
> > this fraudulently issued CRL will probably be validated whether it
> > contains an AIA or not.
> 
> This indicates once again that this is not an issue caused by the use 
> of AIA in CRLs but a generic CRL validation issue that belongs with 
> RFC 3280bis and not with the CRL-AIA draft.
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > On Behalf Of Julien Stern
> > Sent: den 24 maj 2005 09:39
> > To: Tom Gindin
> > Cc: [email-masked]
> > Subject: Re: WG Last Call: AIA CRL extension
> > 
> > 
> > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > >
> > >         There is one scenario permitted by the "same trust anchor"
> rule
> > > for CRL signers which seems to me to be a serious security hole.
> Let us
> > > assume a valid CA which is a direct subordinate of one of the RP's
> trust
> > > anchors.  This CA issues separate CRL's and ARL's, in a quite 
> > > usual
> way,
> > > and issues cross certificates.  After months or years of 
> > > operation,
> it
> > > revokes one of its cross certificates because the subject's 
> > > operator
> has
> > > gone rogue.  That rogue subject then issues a fraudulent CRL 
> > > Signing certificate with the DN that the superior certificate has 
> > > been using
> to
> > > sign ARL's, a public key which it has newly generated, and various 
> > > extensions including an SKID.  It then issues an updated copy of 
> > > an
> old
> > > ARL under the fraudulent CRL signer's certificate and with an AKID 
> > > matching the fraudulent signer's SKID.  If the rogue can break 
> > > into
> the
> > > repository where the CRL is expected, this fraudulently issued CRL
> will
> > > probably be validated whether it contains an AIA or not.  It will 
> > > certainly pass the "same trust anchor" condition.
> > >         This scenario, in which a rogue CA issues an ARL
> > > certifiying
> > that
> > > its primary certificate has not been revoked and gets the ARL
> accepted,
> > is
> > > possible under "same trust anchor" but not under "signed by path
> > member".
> > 
> > I agree with the validity of this scenario. I believe this is very 
> > close to the issue I attempted to bring on the list a short time 
> > ago. Of course, it assumes the existence of a rogue CA at some point 
> > in
> time.
> > 
> > Note that the CRL could be directly inserted into a "long term" 
> > signature (according to RFC3126 for example). This does not require 
> > a repository break-in and makes the "attack" even more realistic.
> > 
> > Regards.
> > 
> > --
> > Julien Stern
> > 
> > >
> > >                 Tom Gindin
> > >
> > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
> -----
> > >
> > >
> > > Tom Gindin
> > > 05/23/2005 10:46 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> [email-masked],
> > > [email-masked]
> > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > >         Subject:        Re: WG Last Call: AIA CRL extension
> > >
> > >         Tim:
> > >
> > >         I should probably have brought this up earlier, but are we
> > certain
> > > that "same trust anchor" is a strong enough check that the CRL
> signer is
> > > the one expected by the issuing CA?  While I was not in San Diego
> when
> > > this wording was included in the 3280 series, I do not really 
> > > think
> that
> > > that check is strong enough.  I would suggest instead that the CRL 
> > > signer's certificate needs to be directly issued by one of the 
> > > CA's
> in
> > the
> > > certification path back to the trust anchor used for the
> certificate's
> > > verification, or by that anchor itself, unless people have 
> > > practical experience with CA structures which that rule would 
> > > prohibit.
> Forcing
> > the
> > > CRL to be issued by the CA itself (as I understand Denis to have
> > > suggested) prohibits the reasonable case where the CRL is issued 
> > > by
> a
> > > hierarchical superior, so it is IMHO too strict.
> > >         I am personally not sure, FWIW, that a CRL should be
> permitted
> > to
> > > be signed by a second-cousin certificate of the issuer's
> certificate.
> > By
> > > analogy to the use of the terms in families, "sibling" 
> > > certificates
> > would
> > > have the same issuer, "first-cousin" certificates would be issued 
> > > by siblings, and "second-cousin" certificates would be issued by 
> > > first cousins - so they are both three levels down from the same 
> > > trust
> anchor,
> > > or from the last common CA in their paths.  This issue is not 
> > > newly
> > caused
> > > by CRL AIA, since the same issue can arise with CRL's containing
> only
> > > AKID.  AIA only allows RP's to build a path (whether right or
> > > wrong)
> > more
> > > quickly.
> > >         In any case, nothing more than a note in Security
> Considerations
> > > is appropriate in any of our RFC's other than 3280 and its
> successor.
> > >
> > >         Tom Gindin
> > > P.S. -  The above views are mine, and not necessarily those of my
> > employer
> > >
> > >
> > >
> > >
> > >
> > > Tim Polk <[email-masked]>
> > > Sent by: [email-masked]
> > > 05/10/2005 05:27 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> > [email-masked]
> > >         Subject:        WG Last Call: AIA CRL extension
> > >
> > >
> > >
> > >
> > > This message initiates working group Last Call for the 
> > > specification "Internet X.509 Public Key Infrastructure: Authority 
> > > Information
> Access
> > > CRL
> > > Extension".  While some issues raised in the working group are
> > unresolved,
> > >
> > > the editors believe that rough consensus supports the current 
> > > specification.
> > >
> > > The URL for this Internet-Draft is:
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > >
> > > Last Call will run for (at least) two weeks. That is, Last Call 
> > > will
> not
> > > close before May 24.
> > >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > >
> > >
> 

Content-Class: urn:content-classes:message
Subject: RE: 3280bis:  CRL validation
Date: Thu, 26 May 2005 11:00:30 +0200
From: "Alberti Antoine" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

The fact that a cert is a trust anchor becomes very personal when using a cross-certified model: two parties are not supposed to have the same ones, but can still communicate.

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]]De la part de Denis Pinkas
> Envoyé : jeudi 26 mai 2005 10:44
> À : pkix
> Objet : 3280bis: CRL validation
> 
> 
> 
> To the list,
> 
> I changed the name of the thread which is now under 3280bis.
> 
> As Tim mentioned: "it is clear that the current content of 
> 3280bis with 
> respect to CRL validation does not enjoy consensus within the 
> working group".
> 
> Issues 33 and 43 are directly related to this topic. They are 
> both copied 
> below:
> 
> 33) The certificateIssuer CRL entry extension contains a 
> GeneralNames. 
> While RFC 3280 does not state this, there seems to be general 
> agreement that 
> the certificateIssuer extension should only contain the DN 
> from the issuer 
> field of the certificate being revoked.
> 
>    3280bis states: "Conforming CRL issuers MUST include in [the
>    certificateIssuer] extension the distinguished name (DN) from the
>    issuer field of the certificate that corresponds to this CRL entry.
>    The encoding of the DN MUST be identical to the encoding 
> used in the
>    certificate."
> 
> 
>   43) It should be noted in 3280bis that there is a risk that 
> two different
>       CAs (or a CA and a CRL issuer) may issue certificates 
> and CRLs under
>       the same name and that if this happens there is a risk 
> that a relying
>       party will validate a certificate issued by one of 
> these entities
>       using a CRL issued by the other.
> 
>    The security considerations section of 3280bis states that 
> CAs and CRL
>    issuers should be formed in a way that reduces the 
> likelihood of name
>    collisions.  It also states that implementations 
> validating CRLs MUST
>    ensure that the certification path of the target 
> certificate and the
>    CRL issuer certification path used to validate the target 
> certificate
>    terminate at the same trust anchor.
> 
> Both statements are incorrect.
> 
> For issue 43: name collisions are possible and a design 
> cannot be based on 
> the assumption that name collisions, whether accidental or 
> intentional, will 
> never happen. This means that chosing names to "reduce the 
> likehood of name 
> collisions" is not a way to solve the issue. Termination at 
> the same trust 
> anchor without additional details does not solve the issue either.
> 
> For issue 33: the certificateIssuer extension is defined as :
> 
>       certificateIssuer ::= GeneralNames
> 
> with
> 
>       GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
> 
> It is not defined as:
> 
>       certificateIssuer ::= GeneralName
> 
> ... and this is NOT an error.
> 
> To go directly to the point, certificateIssuer may contain in 
> practice either:
> 
>   - one name, or
>   - a sequence of names.
> 
> If it contains one name, this means that this name MUST be 
> certified by the 
> CA that has issued the certificate where the extension appears.
> 
> If it contains a sequence of names, this means that the 
> certification path 
> of the CRL issuer certificate formed using that sequence of 
> names MUST also 
> terminate at the trust anchor of the target certificate.
> 
> This is secure and avoids any name collision, either 
> deliberate or intentional.
> 
> Denis
> 
> 

Date: Thu, 26 May 2005 11:00:52 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: pkix <[email-masked]>
Subject: 3280bis: key usage (13)
Sender: [email-masked]

To the list,

The disposition of comments states:

  13) The descriptions of the meanings of the digitalSignature and
      nonRepudiation bits of keyUsage may need to be adjusted based
      on the work in X.509

   The new text in X.509 aligns with the text in RFC 3280.  No changes
   are required to 3280bis.  A comment has been added to the ASN.1 for
   KeyUsage stating that "recent editions of X.509 have renamed
   [the nonRepudiation] bit to contentCommitment"

This statement is untrue.

The text from X.509 has been published in Corrigendum 3 (04/2004)
on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called

ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).

An extract from this text is copied below:

a) digitalSignature: for verifying digital signatures that are used
    with an entity authentication service, a data origin authentication
    service or/and an integrity service;

b) contentCommitment: for verifying digital signatures which are intended
    to signal that the signer is committing to the content being signed.
    The type of commitment the certificate can be used to support may be
    further constrained by the CA, e.g. through a certificate policy.
    The precise type of commitment of the signer e.g. "reviewed and
    approved" or "with the intent to be bound", may be signalled by the
    content being signed, e.g. the signed document itself or some additional
    signed information.

    Since a content commitment signing is considered to be a digitally signed
    transaction, the digitalSignature bit need not be set in the certificate.
    If it is set, it does not affect the level of commitment the signer has
    endowed in the signed content.

    Note that it is not incorrect to refer to this keyUsage bit using the
    identifier nonRepudiation. However, the use of this identifier has been
    deprecated. Regardless of the identifier used, the semantics of this bit
    are as specified in this Directory Specification.

The text from 3280 is copied below:

       The digitalSignature bit is asserted when the subject public key
       is used with a digital signature mechanism to support security
       services other than certificate signing (bit 5), or CRL signing
       (bit 6).  Digital signature mechanisms are often used for entity
       authentication and data origin authentication with integrity.

       The nonRepudiation bit is asserted when the subject public key is
       used to verify digital signatures used to provide a non-
       repudiation service which protects against the signing entity
       falsely denying some action, excluding certificate or CRL signing.
       In the case of later conflict, a reliable third party may
       determine the authenticity of the signed data.

       Further distinctions between the digitalSignature and
       nonRepudiation bits may be provided in specific certificate
       policies.

The text from 3280bis does not align with the ISO-ITU text.
Please align with the the ISO-ITU text.

Denis

Date: Thu, 26 May 2005 10:43:30 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: pkix <[email-masked]>
Subject: 3280bis:  CRL validation
Sender: [email-masked]

To the list,

I changed the name of the thread which is now under 3280bis.

As Tim mentioned: "it is clear that the current content of 3280bis with 
respect to CRL validation does not enjoy consensus within the working group".

Issues 33 and 43 are directly related to this topic. They are both copied 
below:

33) The certificateIssuer CRL entry extension contains a GeneralNames. 
While RFC 3280 does not state this, there seems to be general agreement that 
the certificateIssuer extension should only contain the DN from the issuer 
field of the certificate being revoked.

   3280bis states: "Conforming CRL issuers MUST include in [the
   certificateIssuer] extension the distinguished name (DN) from the
   issuer field of the certificate that corresponds to this CRL entry.
   The encoding of the DN MUST be identical to the encoding used in the
   certificate."

  43) It should be noted in 3280bis that there is a risk that two different
      CAs (or a CA and a CRL issuer) may issue certificates and CRLs under
      the same name and that if this happens there is a risk that a relying
      party will validate a certificate issued by one of these entities
      using a CRL issued by the other.

   The security considerations section of 3280bis states that CAs and CRL
   issuers should be formed in a way that reduces the likelihood of name
   collisions.  It also states that implementations validating CRLs MUST
   ensure that the certification path of the target certificate and the
   CRL issuer certification path used to validate the target certificate
   terminate at the same trust anchor.

Both statements are incorrect.

For issue 43: name collisions are possible and a design cannot be based on 
the assumption that name collisions, whether accidental or intentional, will 
never happen. This means that chosing names to "reduce the likehood of name 
collisions" is not a way to solve the issue. Termination at the same trust 
anchor without additional details does not solve the issue either.

For issue 33: the certificateIssuer extension is defined as :

      certificateIssuer ::= GeneralNames

with

      GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

It is not defined as:

      certificateIssuer ::= GeneralName

... and this is NOT an error.

To go directly to the point, certificateIssuer may contain in practice either:

  - one name, or
  - a sequence of names.

If it contains one name, this means that this name MUST be certified by the 
CA that has issued the certificate where the extension appears.

If it contains a sequence of names, this means that the certification path 
of the CRL issuer certificate formed using that sequence of names MUST also 
terminate at the trust anchor of the target certificate.

This is secure and avoids any name collision, either deliberate or intentional.

Denis

Date: Thu, 26 May 2005 08:53:49 +0200
From: Olivier Dubuisson <[email-masked]>
Organization: France Telecom - Research & Development
To: Andrew Sciberras <[email-masked]>
CC: Jaeho Yoon <[email-masked]>, [email-masked]
Subject: Re: [draft-ietf-pkix-sim-04.txt]
Sender: [email-masked]

Andrew Sciberras wrote:

> Jaeho Yoon wrote:
> 
>> Please review and comment on the following draft :
>> Internet X.509 Public Key Infrastructure Subject Identification Method 
>> (SIM)
>> <draft-ietf-pkix-sim-04.txt>
> 
> Hi,
> 
> Just a couple of little things...
> 
> Since your defining ASN.1 types, it would probably be a good idea to 
> reference an ASN.1 specification, including the year.

The right references are there:
http://asn1.elibel.tm.fr/en/standards/index.htm

> The year is
> important because newer versions of the specification wont accept (or 
> compile) your ASN.1 module do to the usage of the UTF8String reserved 
> keyword as a typereference.

Why redefine the UTF8String instead of using the one standardized in the
ASN.1 standard?
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/

To: "Stefan Santesson" <[email-masked]>
Cc: "Santosh Chokhani" <[email-masked]>, [email-masked], "Julien Stern" <[email-masked]>
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
From: Tom Gindin <[email-masked]>
Date: Wed, 25 May 2005 22:21:59 -0400
Sender: [email-masked]

        Stefan:

        I can't find any loop control text on this subject in 3280 or 
3280-bis.  I don't know what a practical validation library would do with 
a potential loop like this, and I doubt if anybody who hasn't written such 
a library knows either.  One of the things it might do is note that the 
certificate is already being validated and assume that its validation 
result is sufficient.  That avoids the loop, at the cost of letting this 
certificate through.  Being sure that the library will encounter a loop 
depends on the library's author interpreting "Obtain and validate the 
certification path for the complete CRL issuer" to include calling a 
revocation check on each element in the path and not assuming that a bad 
certificate already being validated once will be caught elsewhere in the 
algorithm.
        On a related issue, the certpathbuild I-D may be just as involved 
in our discussions as 3280-bis.  Its security considerations section on 
CRL signer paths is considerably more elaborate than 3280's discussion, 
and does not consider that terminating at the same trust anchor is good 
enough.

                Tom Gindin

"Stefan Santesson" <[email-masked]>
05/25/2005 02:17 PM
 
        To:     Tom Gindin/Watson/IBM@IBMUS, "Santosh Chokhani" 
<[email-masked]>
        cc:     <[email-masked]>, "Julien Stern" 
<[email-masked]>
        Subject:        RE: CRL Issue (Was RE: WG Last Call: AIA CRL 
extension)

Tom,

If the substitution would be successful the validation would go into an
infinite loop and fail.
Validation of S's fake CRL requires validation of C's cross certificate
to S which triggers another validation of S's fake CRL and so on.

I think we added some text against infinite loops but I don't have it
fresh in my memory.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> On Behalf Of Tom Gindin
> Sent: den 25 maj 2005 04:50
> To: Santosh Chokhani
> Cc: [email-masked]; 'Julien Stern'
> Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
> 
> 
>         Santosh:
> 
>         A relatively concrete example would be the following:
>         Assume a trust anchor called A, and CA it has issued a cross
> certificate to called C.  Further assume that C uses indirect CRL's,
and
> has issued a cross certificate without name constraints to another CA
> called S. Then assume that S goes rogue and creates a CRL signing
> certificate with the same name as C uses for its indirect CRL's (the
key
> pair in that certificate is hereinafter called the "rogue CRL
signer").
> Further assume that C finds out about this and creates a CRL listing S
as
> revoked, but that S successfully replaces that CRL in the repository
by
> one signed by the rogue CRL signer.
>         Does RFC 3280 path validation consider S invalid?  If so,
which
> step loops or fails?  It looks to me like 6.3.3-b-1 passes.  Is there
> always a bi-modal loop between 6.3.3-f and 6.1.3-a-3?  If not, what
else
> would be likely to cause S to be recognized as invalid?  You could
> probably patch any difficulties by adding "if the certificate whose
> revocation is being checked appears in the path, reject it" to
6.3.3-f.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>
> 05/24/2005 06:42 PM
> 
>         To:     Tom Gindin/Watson/IBM@IBMUS, <[email-masked]>
>         cc:     "'Julien Stern'" <[email-masked]>
>         Subject:        CRL Issue (Was RE: WG Last Call: AIA CRL
> extension)
> 
> 
> Tom,
> 
> 
> I assume you are talking about CRL certification path solution I
proposed
> will not permit the scenario?  I still do not see in your case, if the
> Subject CA (cross certified CA) is revoked, you will verify the path
to it
> in the first place.  May be I am not understanding your scenario
properly.
> How does the revoked CA gets verified?
> 
> 
> Julien,
> 
> We have defined and proven the solution for how to do this.  The
scenario
> you proposed is not something X.509 worries about (A CA that is still
> valid,
> but has gone bad).
> 
> On
> Behalf Of Julien Stern
> Sent: Tuesday, May 24, 2005 3:49 PM
> To: Stefan Santesson
> Cc: Tom Gindin; [email-masked]
> Subject: Re: WG Last Call: AIA CRL extension
> 
> 
> 
> On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> > Tom and Julien,
> >
> > Since this is a repetition of the discussion we had before San Diego
> > and I don't want to repeat it here. I'm not saying that this
> > discussion is invalid; it is just directed towards the wrong draft.
> 
> Stefan,
> 
> I agree with you. Actually, I would tend to believe that a _real_
> discussion
> would have to take place at some point regarding the overall security
> model
> of CRL validation, but I have absolutely no objection to the AIA, as
soon
> as
> it is made clear that it's only goal is to simplify path building
> implementations, and not to adress security issues. My very humble
take on
> the subject is that Denis and yourself have been arguing on the list
on
> absolutely valid but different matters.
> 
> So, I chose not to comment expect for my last mail (and will not any
more)
> about AIA, but I still think that a discusssion regarding revocation
> validation should take place for RFC3280bis, eventually.
> 
> Regards,
> 
> --
> Julien Stern
> 
> >
> > As Tom pointed out:
> > > this fraudulently issued CRL will probably be validated whether it
> > > contains an AIA or not.
> >
> > This indicates once again that this is not an issue caused by the
use
> > of AIA in CRLs but a generic CRL validation issue that belongs with
> > RFC 3280bis and not with the CRL-AIA draft.
> >
> > Stefan Santesson
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> > > On Behalf Of Julien Stern
> > > Sent: den 24 maj 2005 09:39
> > > To: Tom Gindin
> > > Cc: [email-masked]
> > > Subject: Re: WG Last Call: AIA CRL extension
> > >
> > >
> > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > > >
> > > >         There is one scenario permitted by the "same trust
anchor"
> > rule
> > > > for CRL signers which seems to me to be a serious security hole.
> > Let us
> > > > assume a valid CA which is a direct subordinate of one of the
RP's
> > trust
> > > > anchors.  This CA issues separate CRL's and ARL's, in a quite
> > > > usual
> > way,
> > > > and issues cross certificates.  After months or years of
> > > > operation,
> > it
> > > > revokes one of its cross certificates because the subject's
> > > > operator
> > has
> > > > gone rogue.  That rogue subject then issues a fraudulent CRL
> > > > Signing certificate with the DN that the superior certificate
has
> > > > been using
> > to
> > > > sign ARL's, a public key which it has newly generated, and
various
> > > > extensions including an SKID.  It then issues an updated copy of
> > > > an
> > old
> > > > ARL under the fraudulent CRL signer's certificate and with an
AKID
> > > > matching the fraudulent signer's SKID.  If the rogue can break
> > > > into
> > the
> > > > repository where the CRL is expected, this fraudulently issued
CRL
> > will
> > > > probably be validated whether it contains an AIA or not.  It
will
> > > > certainly pass the "same trust anchor" condition.
> > > >         This scenario, in which a rogue CA issues an ARL
> > > > certifiying
> > > that
> > > > its primary certificate has not been revoked and gets the ARL
> > accepted,
> > > is
> > > > possible under "same trust anchor" but not under "signed by path
> > > member".
> > >
> > > I agree with the validity of this scenario. I believe this is very
> > > close to the issue I attempted to bring on the list a short time
> > > ago. Of course, it assumes the existence of a rogue CA at some
point
> > > in
> > time.
> > >
> > > Note that the CRL could be directly inserted into a "long term"
> > > signature (according to RFC3126 for example). This does not
require
> > > a repository break-in and makes the "attack" even more realistic.
> > >
> > > Regards.
> > >
> > > --
> > > Julien Stern
> > >
> > > >
> > > >                 Tom Gindin
> > > >
> > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
> > -----
> > > >
> > > >
> > > > Tom Gindin
> > > > 05/23/2005 10:46 PM
> > > >
> > > >         To:     [email-masked]
> > > >         cc:     [email-masked], [email-masked],
> > [email-masked],
> > > > [email-masked]
> > > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > > >         Subject:        Re: WG Last Call: AIA CRL extension
> > > >
> > > >         Tim:
> > > >
> > > >         I should probably have brought this up earlier, but are
we
> > > certain
> > > > that "same trust anchor" is a strong enough check that the CRL
> > signer is
> > > > the one expected by the issuing CA?  While I was not in San
Diego
> > when
> > > > this wording was included in the 3280 series, I do not really
> > > > think
> > that
> > > > that check is strong enough.  I would suggest instead that the
CRL
> > > > signer's certificate needs to be directly issued by one of the
> > > > CA's
> > in
> > > the
> > > > certification path back to the trust anchor used for the
> > certificate's
> > > > verification, or by that anchor itself, unless people have
> > > > practical experience with CA structures which that rule would
> > > > prohibit.
> > Forcing
> > > the
> > > > CRL to be issued by the CA itself (as I understand Denis to have
> > > > suggested) prohibits the reasonable case where the CRL is issued
> > > > by
> > a
> > > > hierarchical superior, so it is IMHO too strict.
> > > >         I am personally not sure, FWIW, that a CRL should be
> > permitted
> > > to
> > > > be signed by a second-cousin certificate of the issuer's
> > certificate.
> > > By
> > > > analogy to the use of the terms in families, "sibling"
> > > > certificates
> > > would
> > > > have the same issuer, "first-cousin" certificates would be
issued
> > > > by siblings, and "second-cousin" certificates would be issued by
> > > > first cousins - so they are both three levels down from the same
> > > > trust
> > anchor,
> > > > or from the last common CA in their paths.  This issue is not
> > > > newly
> > > caused
> > > > by CRL AIA, since the same issue can arise with CRL's containing
> > only
> > > > AKID.  AIA only allows RP's to build a path (whether right or
> > > > wrong)
> > > more
> > > > quickly.
> > > >         In any case, nothing more than a note in Security
> > Considerations
> > > > is appropriate in any of our RFC's other than 3280 and its
> > successor.
> > > >
> > > >         Tom Gindin
> > > > P.S. -  The above views are mine, and not necessarily those of
my
> > > employer
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Tim Polk <[email-masked]>
> > > > Sent by: [email-masked]
> > > > 05/10/2005 05:27 PM
> > > >
> > > >         To:     [email-masked]
> > > >         cc:     [email-masked], [email-masked],
> > > [email-masked]
> > > >         Subject:        WG Last Call: AIA CRL extension
> > > >
> > > >
> > > >
> > > >
> > > > This message initiates working group Last Call for the
> > > > specification "Internet X.509 Public Key Infrastructure:
Authority
> > > > Information
> > Access
> > > > CRL
> > > > Extension".  While some issues raised in the working group are
> > > unresolved,
> > > >
> > > > the editors believe that rough consensus supports the current
> > > > specification.
> > > >
> > > > The URL for this Internet-Draft is:
> > > >
> > > >
http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > > >
> > > > Last Call will run for (at least) two weeks. That is, Last Call
> > > > will
> > not
> > > > close before May 24.
> > > >
> > > > Thanks,
> > > >
> > > > Tim Polk
> > > >
> > > >
> > > >
> >
> 
> 

To: "Santosh Chokhani" <[email-masked]>
Cc: [email-masked]
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
From: Tom Gindin <[email-masked]>
Date: Wed, 25 May 2005 22:21:54 -0400
Sender: [email-masked]

        Santosh:

        I thought that I had made that particular issue clear.  The 
indirect CRL being retrieved governs C's certificates and its issuer name 
(call it C1) is supposed to belong to C.  Indeed, C has issued a CRL 
signing certificate with subject name C1.  However, S has created another 
CRL signing certificate with this same subject name and has created a CRL 
with that key pair.  C did not create any circularity.  The original 
certificate for C1 was issued by C and the corresponding private key 
belongs to an entity under C's control, while the new certificate for C1 
was issued by S and the corresponding private key belongs to a malicious 
subsystem inside S.  While certificates are issued to entities, relying 
parties know the name and the chain but not the entity.
        No relevant CRL is issued by S.  I'm sure that your objection to '
looking at CRL issued by C' actually meant 'issued by S', because you 
normally verify certificates by looking at CRL's issued by the certificate 
issuer or its delegate.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
05/25/2005 08:58 AM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: CRL Issue (Was RE: WG Last Call: AIA CRL 
extension)

Tom,

It is not clear from your example who the indirect CRL issuer is and what
role the "indirect CRL" plays in the attack.  If S is the indirect CRL
issuer, C should be smart enough to not create circularity (a good toolkit
will not verify path when C issues a certificate to S and points to S as 
the
indirect CRL issuer since it causes circularity and chicken and egg
problem).  That scenario can be easily rectified within current standard 
by
C not declaring S as the indirect CRL issuer for certificate issued to S. 
C
can declare itself in the CDP or some other issuer.

I suspect you do not mean this.  Your example may be simpler.  To me the
attack is still not plausible.  Your scenario is not detailed enough to
illustrate an attack.  It does not seem that there is a way to validate 
the
certificate issued to C by S without looking at CRL issued by C, resulting
in circularity, which relying party clients should not accept. 

(Note that my November presentation to IETF in DC covered the circularity
issues in CRL and OCSP and recommendations for 3280 and 2560 in addition 
to
the CRL certification path)

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2005 7:50 AM
To: Santosh Chokhani
Cc: [email-masked]; 'Julien Stern'
Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension)

        Santosh:

        A relatively concrete example would be the following:
        Assume a trust anchor called A, and CA it has issued a cross 
certificate to called C.  Further assume that C uses indirect CRL's, and 
has issued a cross certificate without name constraints to another CA 
called S. Then assume that S goes rogue and creates a CRL signing 
certificate with the same name as C uses for its indirect CRL's (the key 
pair in that certificate is hereinafter called the "rogue CRL signer"). 
Further assume that C finds out about this and creates a CRL listing S as 
revoked, but that S successfully replaces that CRL in the repository by 
one signed by the rogue CRL signer.
        Does RFC 3280 path validation consider S invalid?  If so, which 
step loops or fails?  It looks to me like 6.3.3-b-1 passes.  Is there 
always a bi-modal loop between 6.3.3-f and 6.1.3-a-3?  If not, what else 
would be likely to cause S to be recognized as invalid?  You could 
probably patch any difficulties by adding "if the certificate whose 
revocation is being checked appears in the path, reject it" to 6.3.3-f.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
05/24/2005 06:42 PM
 
        To:     Tom Gindin/Watson/IBM@IBMUS, <[email-masked]>
        cc:     "'Julien Stern'" <[email-masked]>
        Subject:        CRL Issue (Was RE: WG Last Call: AIA CRL 
extension)

Tom,

I assume you are talking about CRL certification path solution I proposed
will not permit the scenario?  I still do not see in your case, if the
Subject CA (cross certified CA) is revoked, you will verify the path to it
in the first place.  May be I am not understanding your scenario properly.
How does the revoked CA gets verified?

Julien,

We have defined and proven the solution for how to do this.  The scenario
you proposed is not something X.509 worries about (A CA that is still 
valid,
but has gone bad).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Julien Stern
Sent: Tuesday, May 24, 2005 3:49 PM
To: Stefan Santesson
Cc: Tom Gindin; [email-masked]
Subject: Re: WG Last Call: AIA CRL extension

On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> Tom and Julien,
> 
> Since this is a repetition of the discussion we had before San Diego
> and I don't want to repeat it here. I'm not saying that this 
> discussion is invalid; it is just directed towards the wrong draft.

Stefan,

I agree with you. Actually, I would tend to believe that a _real_ 
discussion
would have to take place at some point regarding the overall security 
model
of CRL validation, but I have absolutely no objection to the AIA, as soon 
as
it is made clear that it's only goal is to simplify path building
implementations, and not to adress security issues. My very humble take on
the subject is that Denis and yourself have been arguing on the list on
absolutely valid but different matters.

So, I chose not to comment expect for my last mail (and will not any more)
about AIA, but I still think that a discusssion regarding revocation
validation should take place for RFC3280bis, eventually.

Regards,

--
Julien Stern

> 
> As Tom pointed out:
> > this fraudulently issued CRL will probably be validated whether it 
> > contains an AIA or not.
> 
> This indicates once again that this is not an issue caused by the use
> of AIA in CRLs but a generic CRL validation issue that belongs with 
> RFC 3280bis and not with the CRL-AIA draft.
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > On Behalf Of Julien Stern
> > Sent: den 24 maj 2005 09:39
> > To: Tom Gindin
> > Cc: [email-masked]
> > Subject: Re: WG Last Call: AIA CRL extension
> > 
> > 
> > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > >
> > >         There is one scenario permitted by the "same trust anchor"
> rule
> > > for CRL signers which seems to me to be a serious security hole.
> Let us
> > > assume a valid CA which is a direct subordinate of one of the RP's
> trust
> > > anchors.  This CA issues separate CRL's and ARL's, in a quite
> > > usual
> way,
> > > and issues cross certificates.  After months or years of
> > > operation,
> it
> > > revokes one of its cross certificates because the subject's
> > > operator
> has
> > > gone rogue.  That rogue subject then issues a fraudulent CRL
> > > Signing certificate with the DN that the superior certificate has 
> > > been using
> to
> > > sign ARL's, a public key which it has newly generated, and various
> > > extensions including an SKID.  It then issues an updated copy of 
> > > an
> old
> > > ARL under the fraudulent CRL signer's certificate and with an AKID
> > > matching the fraudulent signer's SKID.  If the rogue can break 
> > > into
> the
> > > repository where the CRL is expected, this fraudulently issued CRL
> will
> > > probably be validated whether it contains an AIA or not.  It will
> > > certainly pass the "same trust anchor" condition.
> > >         This scenario, in which a rogue CA issues an ARL 
> > > certifiying
> > that
> > > its primary certificate has not been revoked and gets the ARL
> accepted,
> > is
> > > possible under "same trust anchor" but not under "signed by path
> > member".
> > 
> > I agree with the validity of this scenario. I believe this is very
> > close to the issue I attempted to bring on the list a short time 
> > ago. Of course, it assumes the existence of a rogue CA at some point 
> > in
> time.
> > 
> > Note that the CRL could be directly inserted into a "long term"
> > signature (according to RFC3126 for example). This does not require 
> > a repository break-in and makes the "attack" even more realistic.
> > 
> > Regards.
> > 
> > --
> > Julien Stern
> > 
> > >
> > >                 Tom Gindin
> > >
> > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
> -----
> > >
> > >
> > > Tom Gindin
> > > 05/23/2005 10:46 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> [email-masked],
> > > [email-masked]
> > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > >         Subject:        Re: WG Last Call: AIA CRL extension
> > >
> > >         Tim:
> > >
> > >         I should probably have brought this up earlier, but are we
> > certain
> > > that "same trust anchor" is a strong enough check that the CRL
> signer is
> > > the one expected by the issuing CA?  While I was not in San Diego
> when
> > > this wording was included in the 3280 series, I do not really
> > > think
> that
> > > that check is strong enough.  I would suggest instead that the CRL
> > > signer's certificate needs to be directly issued by one of the 
> > > CA's
> in
> > the
> > > certification path back to the trust anchor used for the
> certificate's
> > > verification, or by that anchor itself, unless people have
> > > practical experience with CA structures which that rule would 
> > > prohibit.
> Forcing
> > the
> > > CRL to be issued by the CA itself (as I understand Denis to have
> > > suggested) prohibits the reasonable case where the CRL is issued
> > > by
> a
> > > hierarchical superior, so it is IMHO too strict.
> > >         I am personally not sure, FWIW, that a CRL should be
> permitted
> > to
> > > be signed by a second-cousin certificate of the issuer's
> certificate.
> > By
> > > analogy to the use of the terms in families, "sibling"
> > > certificates
> > would
> > > have the same issuer, "first-cousin" certificates would be issued
> > > by siblings, and "second-cousin" certificates would be issued by 
> > > first cousins - so they are both three levels down from the same 
> > > trust
> anchor,
> > > or from the last common CA in their paths.  This issue is not
> > > newly
> > caused
> > > by CRL AIA, since the same issue can arise with CRL's containing
> only
> > > AKID.  AIA only allows RP's to build a path (whether right or
> > > wrong)
> > more
> > > quickly.
> > >         In any case, nothing more than a note in Security
> Considerations
> > > is appropriate in any of our RFC's other than 3280 and its
> successor.
> > >
> > >         Tom Gindin
> > > P.S. -  The above views are mine, and not necessarily those of my
> > employer
> > >
> > >
> > >
> > >
> > >
> > > Tim Polk <[email-masked]>
> > > Sent by: [email-masked]
> > > 05/10/2005 05:27 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> > [email-masked]
> > >         Subject:        WG Last Call: AIA CRL extension
> > >
> > >
> > >
> > >
> > > This message initiates working group Last Call for the
> > > specification "Internet X.509 Public Key Infrastructure: Authority 
> > > Information
> Access
> > > CRL
> > > Extension".  While some issues raised in the working group are
> > unresolved,
> > >
> > > the editors believe that rough consensus supports the current
> > > specification.
> > >
> > > The URL for this Internet-Draft is:
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > >
> > > Last Call will run for (at least) two weeks. That is, Last Call
> > > will
> not
> > > close before May 24.
> > >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > >
> > >
> 

Date: Thu, 26 May 2005 12:03:13 +1000
From: Andrew Sciberras <[email-masked]>
Organization: eB2Bcom
To: Jaeho Yoon <[email-masked]>
CC: [email-masked]
Subject: Re: [draft-ietf-pkix-sim-04.txt]
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=EUC-KR" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Jaeho Yoon wrote:
<blockquote cite="mid001501c56188$964f40b0$720710ac@5434d1" type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.2627" name="GENERATOR">
  <style></style>
  <div>Please review and comment on the following draft : </div>
  <div>Internet X.509 Public Key Infrastructure Subject&nbsp;Identification
Method (SIM)<br>
&lt;draft-ietf-pkix-sim-04.txt&gt; </div>
</blockquote>
Hi,<br>
<br>
Just a couple of little things...<br>
<br>
Since your defining ASN.1 types, it would probably be a good idea to
reference an ASN.1 specification, including the year. The year is
important because newer versions of the specification wont accept (or
compile) your ASN.1 module do to the usage of the UTF8String reserved
keyword as a typereference.<br>
<br>
The [PI] reference should probably refer to RFC4043<br>
<br>
Cheers,<br>
Andrew<br>
</body>
</html>

From: "Jaeho Yoon" <[email-masked]>
To: <[email-masked]>
Subject: [draft-ietf-pkix-sim-04.txt]
Date: Thu, 26 May 2005 09:19:31 +0900
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C561D4.05FB6650
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_0012_01C561D4.05FB6650
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

------=_NextPart_000_0012_01C561D4.05FB6650--

Date: Wed, 25 May 2005 15:40:18 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: WG Last Call: AIA CRL extension
Cc: Denis Pinkas <[email-masked]>, Stefan Santesson <[email-masked]>, Russ Housley <[email-masked]>
Sender: [email-masked]

Folks,

My reading of this thread says that rough consensus has been achieved on 
the AIA CRL extension ID, and that I can forward the document to the 
appropriate Area Director after deletion of these sentences.  (If anyone 
disagrees, please say so on list ASAP!)

As noted, this issue will have to be addressed in the context of 
3280bis.  It is clear that the current content of 3280bis with respect to 
CRL validation does not enjoy consensus within the working group.

Thanks,

Tim Polk

At 04:36 PM 5/25/2005 +0200, Denis Pinkas wrote:

>Stefan and Russ,
>
>>Denis,
>
>>I discussed this with Russ and our conclusion is that if this resolves
>>your last call issues, then we can live with deleting these sentences.
>
>If so, my concern is solved.
>
>Thanks,
>
>Denis
>
>PS: Stefan, we do not need to meet anymore next week on this topic,
>     and we can spend more time to enjoy some good food on the
>     French Riviera.  :-)
>
>>Stefan Santesson
>>Program Manager, Standards Liaison
>>Windows Security
>>
>>
>>>On Behalf Of Denis Pinkas
>>>Sent: den 25 maj 2005 00:47
>>>To: Russ Housley
>>>Cc: [email-masked]
>>>Subject: Re: WG Last Call: AIA CRL extension
>>>
>>>
>>>Russ,
>>>
>>>Two points:
>>>
>>>1. The current text in the security considerations section contains
>>>    text which suggest a solution to the problem but which is not.
>>>    At least the two following sentences SHALL be deleted:
>>>
>>>    " As means of reducing problems and security issues related to
>>issuer
>>
>>>    name collisions, CA names SHOULD be formed in a way that reduce
>>the
>>
>>>    likelihood of name collisions.  Implementations validating CRLs
>>>    MUST ensure that the certification path of the target certificate
>>>    and the CRL issuer certification path used to validate the target
>>>    certificate, terminate at the same trust anchor".
>>>
>>>2. We strongly agree that 3280bis MUST address this issue and
>>currently
>>
>>>    it does not do it correctly (otherwise we would not have this
>>>    loooong discussion), ... that we can continue within the scope
>>>    of 3280bis.
>>>
>>>Denis
>>>
>>>
>>>>Julien & Tom:
>>>>
>>>>Two points:
>>>>
>>>>1.  I understand this scenario.  The change that you advocate as a
>>>>countermeasure will prevent Indirect CRLs from working in scenarios
>>that
>>
>>>>are intended.
>>>>
>>>>2.  This observation has noting to do with the CRL AIA extension.
>>The
>>
>>>>attacker is inserting the bogus revocation information into the
>>>>repository.  Any relying party that uses that repository (when using
>>the
>>
>>>>CRL AIA extension or any other configuration information to locate
>>it)
>>
>>>>will get the bogus revocation information.
>>>>
>>>>If this is a concern, then it needs to be addressed in RFC3280bis,
>>not
>>
>>>>here.
>>>>
>>>>Russ
>>>>
>>>>At 12:38 PM 5/24/2005, Julien Stern wrote:
>>>>
>>>>
>>>>>On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
>>>>>
>>>>>>        There is one scenario permitted by the "same trust
>>anchor"
>>
>>>rule
>>>
>>>>>>for CRL signers which seems to me to be a serious security hole.
>>>>>
>>>>>Let us
>>>>>
>>>>>>assume a valid CA which is a direct subordinate of one of the
>>RP's
>>
>>>>>trust
>>>>>
>>>>>>anchors.  This CA issues separate CRL's and ARL's, in a quite
>>usual
>>
>>>>>way,
>>>>>
>>>>>>and issues cross certificates.  After months or years of
>>operation,
>>
>>>it
>>>
>>>>>>revokes one of its cross certificates because the subject's
>>operator
>>
>>>>>has
>>>>>
>>>>>>gone rogue.  That rogue subject then issues a fraudulent CRL
>>Signing
>>
>>>>>>certificate with the DN that the superior certificate has been
>>using
>>
>>>to
>>>
>>>>>>sign ARL's, a public key which it has newly generated, and
>>various
>>
>>>>>>extensions including an SKID.  It then issues an updated copy of
>>an
>>
>>>old
>>>
>>>>>>ARL under the fraudulent CRL signer's certificate and with an
>>AKID
>>
>>>>>>matching the fraudulent signer's SKID.  If the rogue can break
>>into
>>
>>>the
>>>
>>>>>>repository where the CRL is expected, this fraudulently issued
>>CRL
>>
>>>will
>>>
>>>>>>probably be validated whether it contains an AIA or not.  It will
>>>>>>certainly pass the "same trust anchor" condition.
>>>>>>        This scenario, in which a rogue CA issues an ARL
>>certifiying
>>
>>>>>that
>>>>>
>>>>>>its primary certificate has not been revoked and gets the ARL
>>>>>
>>>>>accepted, is
>>>>>
>>>>>>possible under "same trust anchor" but not under "signed by path
>>>>>
>>>>>member".
>>>>>
>>>>>I agree with the validity of this scenario. I believe this is very
>>>>>close to the issue I attempted to bring on the list a short time
>>ago.
>>
>>>>>Of course, it assumes the existence of a rogue CA at some point in
>>>time.
>>>
>>>>>Note that the CRL could be directly inserted into a "long term"
>>>>>signature (according to RFC3126 for example). This does not require
>>>>>a repository break-in and makes the "attack" even more realistic.
>>>>>
>>>>>Regards.
>>>>>
>>>>>--
>>>>>Julien Stern
>>>>>
>>>>>
>>>>>>                Tom Gindin
>>>>>>
>>>>>>----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
>>-----
>>
>>>>>>
>>>>>>Tom Gindin
>>>>>>05/23/2005 10:46 PM
>>>>>>
>>>>>>        To:     [email-masked]
>>>>>>        cc:     [email-masked], [email-masked],
>>>[email-masked],
>>>
>>>>>>[email-masked]
>>>>>>        From:   Tom Gindin/Watson/IBM@IBMUS
>>>>>>        Subject:        Re: WG Last Call: AIA CRL extension
>>>>>>
>>>>>>        Tim:
>>>>>>
>>>>>>        I should probably have brought this up earlier, but are
>>we
>>
>>>>>certain
>>>>>
>>>>>>that "same trust anchor" is a strong enough check that the CRL
>>>>>
>>>>>signer is
>>>>>
>>>>>>the one expected by the issuing CA?  While I was not in San Diego
>>>when
>>>
>>>>>>this wording was included in the 3280 series, I do not really
>>think
>>
>>>>>that
>>>>>
>>>>>>that check is strong enough.  I would suggest instead that the
>>CRL
>>
>>>>>>signer's certificate needs to be directly issued by one of the
>>CA's
>>
>>>>>in the
>>>>>
>>>>>>certification path back to the trust anchor used for the
>>>certificate's
>>>
>>>>>>verification, or by that anchor itself, unless people have
>>practical
>>
>>>>>>experience with CA structures which that rule would prohibit.
>>>>>
>>>>>Forcing the
>>>>>
>>>>>>CRL to be issued by the CA itself (as I understand Denis to have
>>>>>>suggested) prohibits the reasonable case where the CRL is issued
>>by a
>>
>>>>>>hierarchical superior, so it is IMHO too strict.
>>>>>>        I am personally not sure, FWIW, that a CRL should be
>>>>>
>>>>>permitted to
>>>>>
>>>>>>be signed by a second-cousin certificate of the issuer's
>>>>>
>>>>>certificate.  By
>>>>>
>>>>>>analogy to the use of the terms in families, "sibling"
>>certificates
>>
>>>>>would
>>>>>
>>>>>>have the same issuer, "first-cousin" certificates would be issued
>>by
>>
>>>>>>siblings, and "second-cousin" certificates would be issued by
>>first
>>
>>>>>>cousins - so they are both three levels down from the same trust
>>>>>
>>>>>anchor,
>>>>>
>>>>>>or from the last common CA in their paths.  This issue is not
>>newly
>>
>>>>>caused
>>>>>
>>>>>>by CRL AIA, since the same issue can arise with CRL's containing
>>only
>>
>>>>>>AKID.  AIA only allows RP's to build a path (whether right or
>>wrong)
>>
>>>>>more
>>>>>
>>>>>>quickly.
>>>>>>        In any case, nothing more than a note in Security
>>>>>
>>>>>Considerations
>>>>>
>>>>>>is appropriate in any of our RFC's other than 3280 and its
>>successor.
>>
>>>>>>        Tom Gindin
>>>>>>P.S. -  The above views are mine, and not necessarily those of my
>>>>>
>>>>>employer
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Tim Polk <[email-masked]>
>>>>>>Sent by: [email-masked]
>>>>>>05/10/2005 05:27 PM
>>>>>>
>>>>>>        To:     [email-masked]
>>>>>>        cc:     [email-masked], [email-masked],
>>>>>
>>>>>[email-masked]
>>>>>
>>>>>>        Subject:        WG Last Call: AIA CRL extension
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>This message initiates working group Last Call for the
>>specification
>>
>>>>>>"Internet X.509 Public Key Infrastructure: Authority Information
>>>Access
>>>
>>>>>>CRL
>>>>>>Extension".  While some issues raised in the working group are
>>>>>
>>>>>unresolved,
>>>>>
>>>>>>the editors believe that rough consensus supports the current
>>>>>>specification.
>>>>>>
>>>>>>The URL for this Internet-Draft is:
>>>>>>
>>>>>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
>>>>>>
>>>>>>Last Call will run for (at least) two weeks. That is, Last Call
>>will
>>
>>>>>not
>>>>>
>>>>>>close before May 24.
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>Tim Polk
>>>>>>
>>>>>>
>>>>
>>>>
>
>

Content-class: urn:content-classes:message
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
Date: Wed, 25 May 2005 20:34:51 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

Agree, I was talking about 3280bis.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of Santosh Chokhani
> Sent: den 25 maj 2005 11:23
> To: [email-masked]
> Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
> 
> 
> Stephan,
> 
> Validation related text (e.g., infinite loops) belongs more in 3280.
> Having
> it in the new I-D does not harm.  But, validation should be addressed
by
> 3280 and not diced up in multiple RFC and then served.
> 
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Wednesday, May 25, 2005 2:18 PM
> To: Tom Gindin; Santosh Chokhani
> Cc: [email-masked]; Julien Stern
> Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
> 
> 
> Tom,
> 
> If the substitution would be successful the validation would go into
an
> infinite loop and fail. Validation of S's fake CRL requires validation
of
> C's cross certificate to S which triggers another validation of S's
fake
> CRL
> and so on.
> 
> I think we added some text against infinite loops but I don't have it
> fresh
> in my memory.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> > On Behalf Of Tom Gindin
> > Sent: den 25 maj 2005 04:50
> > To: Santosh Chokhani
> > Cc: [email-masked]; 'Julien Stern'
> > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
> >
> >
> >         Santosh:
> >
> >         A relatively concrete example would be the following:
> >         Assume a trust anchor called A, and CA it has issued a cross
> > certificate to called C.  Further assume that C uses indirect CRL's,
> and
> > has issued a cross certificate without name constraints to another
CA
> > called S. Then assume that S goes rogue and creates a CRL signing
> > certificate with the same name as C uses for its indirect CRL's (the
> key
> > pair in that certificate is hereinafter called the "rogue CRL
> signer").
> > Further assume that C finds out about this and creates a CRL listing
S
> as
> > revoked, but that S successfully replaces that CRL in the repository
> by
> > one signed by the rogue CRL signer.
> >         Does RFC 3280 path validation consider S invalid?  If so,
> which
> > step loops or fails?  It looks to me like 6.3.3-b-1 passes.  Is
there
> > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3?  If not, what
> else
> > would be likely to cause S to be recognized as invalid?  You could
> > probably patch any difficulties by adding "if the certificate whose
> > revocation is being checked appears in the path, reject it" to
> 6.3.3-f.
> >
> >                 Tom Gindin
> >
> >
> >
> >
> >
> >
> > "Santosh Chokhani" <[email-masked]>
> > 05/24/2005 06:42 PM
> >
> >         To:     Tom Gindin/Watson/IBM@IBMUS, <[email-masked]>
> >         cc:     "'Julien Stern'" <[email-masked]>
> >         Subject:        CRL Issue (Was RE: WG Last Call: AIA CRL
> > extension)
> >
> >
> > Tom,
> >
> >
> > I assume you are talking about CRL certification path solution I
> proposed
> > will not permit the scenario?  I still do not see in your case, if
the
> > Subject CA (cross certified CA) is revoked, you will verify the path
> to it
> > in the first place.  May be I am not understanding your scenario
> properly.
> > How does the revoked CA gets verified?
> >
> >
> > Julien,
> >
> > We have defined and proven the solution for how to do this.  The
> scenario
> > you proposed is not something X.509 worries about (A CA that is
still
> > valid, but has gone bad).
> >
> > On
> > Behalf Of Julien Stern
> > Sent: Tuesday, May 24, 2005 3:49 PM
> > To: Stefan Santesson
> > Cc: Tom Gindin; [email-masked]
> > Subject: Re: WG Last Call: AIA CRL extension
> >
> >
> >
> > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> > > Tom and Julien,
> > >
> > > Since this is a repetition of the discussion we had before San
Diego
> > > and I don't want to repeat it here. I'm not saying that this
> > > discussion is invalid; it is just directed towards the wrong
draft.
> >
> > Stefan,
> >
> > I agree with you. Actually, I would tend to believe that a _real_
> > discussion would have to take place at some point regarding the
> > overall security model
> > of CRL validation, but I have absolutely no objection to the AIA, as
> soon
> > as
> > it is made clear that it's only goal is to simplify path building
> > implementations, and not to adress security issues. My very humble
> take on
> > the subject is that Denis and yourself have been arguing on the list
> on
> > absolutely valid but different matters.
> >
> > So, I chose not to comment expect for my last mail (and will not any
> more)
> > about AIA, but I still think that a discusssion regarding revocation
> > validation should take place for RFC3280bis, eventually.
> >
> > Regards,
> >
> > --
> > Julien Stern
> >
> > >
> > > As Tom pointed out:
> > > > this fraudulently issued CRL will probably be validated whether
it
> > > > contains an AIA or not.
> > >
> > > This indicates once again that this is not an issue caused by the
> use
> > > of AIA in CRLs but a generic CRL validation issue that belongs
with
> > > RFC 3280bis and not with the CRL-AIA draft.
> > >
> > > Stefan Santesson
> > > Program Manager, Standards Liaison
> > > Windows Security
> > >
> > >
> > > > On Behalf Of Julien Stern
> > > > Sent: den 24 maj 2005 09:39
> > > > To: Tom Gindin
> > > > Cc: [email-masked]
> > > > Subject: Re: WG Last Call: AIA CRL extension
> > > >
> > > >
> > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > > > >
> > > > >         There is one scenario permitted by the "same trust
> anchor"
> > > rule
> > > > > for CRL signers which seems to me to be a serious security
hole.
> > > Let us
> > > > > assume a valid CA which is a direct subordinate of one of the
> RP's
> > > trust
> > > > > anchors.  This CA issues separate CRL's and ARL's, in a quite
> > > > > usual
> > > way,
> > > > > and issues cross certificates.  After months or years of
> > > > > operation,
> > > it
> > > > > revokes one of its cross certificates because the subject's
> > > > > operator
> > > has
> > > > > gone rogue.  That rogue subject then issues a fraudulent CRL
> > > > > Signing certificate with the DN that the superior certificate
> has
> > > > > been using
> > > to
> > > > > sign ARL's, a public key which it has newly generated, and
> various
> > > > > extensions including an SKID.  It then issues an updated copy
of
> > > > > an
> > > old
> > > > > ARL under the fraudulent CRL signer's certificate and with an
> AKID
> > > > > matching the fraudulent signer's SKID.  If the rogue can break
> > > > > into
> > > the
> > > > > repository where the CRL is expected, this fraudulently issued
> CRL
> > > will
> > > > > probably be validated whether it contains an AIA or not.  It
> will
> > > > > certainly pass the "same trust anchor" condition.
> > > > >         This scenario, in which a rogue CA issues an ARL
> > > > > certifiying
> > > > that
> > > > > its primary certificate has not been revoked and gets the ARL
> > > accepted,
> > > > is
> > > > > possible under "same trust anchor" but not under "signed by
path
> > > > member".
> > > >
> > > > I agree with the validity of this scenario. I believe this is
very
> > > > close to the issue I attempted to bring on the list a short time
> > > > ago. Of course, it assumes the existence of a rogue CA at some
> point
> > > > in
> > > time.
> > > >
> > > > Note that the CRL could be directly inserted into a "long term"
> > > > signature (according to RFC3126 for example). This does not
> require
> > > > a repository break-in and makes the "attack" even more
realistic.
> > > >
> > > > Regards.
> > > >
> > > > --
> > > > Julien Stern
> > > >
> > > > >
> > > > >                 Tom Gindin
> > > > >
> > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13
AM
> > > -----
> > > > >
> > > > >
> > > > > Tom Gindin
> > > > > 05/23/2005 10:46 PM
> > > > >
> > > > >         To:     [email-masked]
> > > > >         cc:     [email-masked], [email-masked],
> > > [email-masked],
> > > > > [email-masked]
> > > > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > > > >         Subject:        Re: WG Last Call: AIA CRL extension
> > > > >
> > > > >         Tim:
> > > > >
> > > > >         I should probably have brought this up earlier, but
are
> we
> > > > certain
> > > > > that "same trust anchor" is a strong enough check that the CRL
> > > signer is
> > > > > the one expected by the issuing CA?  While I was not in San
> Diego
> > > when
> > > > > this wording was included in the 3280 series, I do not really
> > > > > think
> > > that
> > > > > that check is strong enough.  I would suggest instead that the
> CRL
> > > > > signer's certificate needs to be directly issued by one of the
> > > > > CA's
> > > in
> > > > the
> > > > > certification path back to the trust anchor used for the
> > > certificate's
> > > > > verification, or by that anchor itself, unless people have
> > > > > practical experience with CA structures which that rule would
> > > > > prohibit.
> > > Forcing
> > > > the
> > > > > CRL to be issued by the CA itself (as I understand Denis to
have
> > > > > suggested) prohibits the reasonable case where the CRL is
issued
> > > > > by
> > > a
> > > > > hierarchical superior, so it is IMHO too strict.
> > > > >         I am personally not sure, FWIW, that a CRL should be
> > > permitted
> > > > to
> > > > > be signed by a second-cousin certificate of the issuer's
> > > certificate.
> > > > By
> > > > > analogy to the use of the terms in families, "sibling"
> > > > > certificates
> > > > would
> > > > > have the same issuer, "first-cousin" certificates would be
> issued
> > > > > by siblings, and "second-cousin" certificates would be issued
by
> > > > > first cousins - so they are both three levels down from the
same
> > > > > trust
> > > anchor,
> > > > > or from the last common CA in their paths.  This issue is not
> > > > > newly
> > > > caused
> > > > > by CRL AIA, since the same issue can arise with CRL's
containing
> > > only
> > > > > AKID.  AIA only allows RP's to build a path (whether right or
> > > > > wrong)
> > > > more
> > > > > quickly.
> > > > >         In any case, nothing more than a note in Security
> > > Considerations
> > > > > is appropriate in any of our RFC's other than 3280 and its
> > > successor.
> > > > >
> > > > >         Tom Gindin
> > > > > P.S. -  The above views are mine, and not necessarily those of
> my
> > > > employer
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Tim Polk <[email-masked]>
> > > > > Sent by: [email-masked]
> > > > > 05/10/2005 05:27 PM
> > > > >
> > > > >         To:     [email-masked]
> > > > >         cc:     [email-masked], [email-masked],
> > > > [email-masked]
> > > > >         Subject:        WG Last Call: AIA CRL extension
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > This message initiates working group Last Call for the
> > > > > specification "Internet X.509 Public Key Infrastructure:
> Authority
> > > > > Information
> > > Access
> > > > > CRL
> > > > > Extension".  While some issues raised in the working group are
> > > > unresolved,
> > > > >
> > > > > the editors believe that rough consensus supports the current
> > > > > specification.
> > > > >
> > > > > The URL for this Internet-Draft is:
> > > > >
> > > > >
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > > > >
> > > > > Last Call will run for (at least) two weeks. That is, Last
Call
> > > > > will
> > > not
> > > > > close before May 24.
> > > > > Thanks,
> > > > > Tim Polk

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
Date: Wed, 25 May 2005 14:22:44 -0400
Importance: Normal
Sender: [email-masked]

Stephan,

Validation related text (e.g., infinite loops) belongs more in 3280.  Having
it in the new I-D does not harm.  But, validation should be addressed by
3280 and not diced up in multiple RFC and then served.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2005 2:18 PM
To: Tom Gindin; Santosh Chokhani
Cc: [email-masked]; Julien Stern
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)

Tom,

If the substitution would be successful the validation would go into an
infinite loop and fail. Validation of S's fake CRL requires validation of
C's cross certificate to S which triggers another validation of S's fake CRL
and so on.

I think we added some text against infinite loops but I don't have it fresh
in my memory.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> On Behalf Of Tom Gindin
> Sent: den 25 maj 2005 04:50
> To: Santosh Chokhani
> Cc: [email-masked]; 'Julien Stern'
> Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
> 
> 
>         Santosh:
> 
>         A relatively concrete example would be the following:
>         Assume a trust anchor called A, and CA it has issued a cross 
> certificate to called C.  Further assume that C uses indirect CRL's,
and
> has issued a cross certificate without name constraints to another CA 
> called S. Then assume that S goes rogue and creates a CRL signing 
> certificate with the same name as C uses for its indirect CRL's (the
key
> pair in that certificate is hereinafter called the "rogue CRL
signer").
> Further assume that C finds out about this and creates a CRL listing S
as
> revoked, but that S successfully replaces that CRL in the repository
by
> one signed by the rogue CRL signer.
>         Does RFC 3280 path validation consider S invalid?  If so,
which
> step loops or fails?  It looks to me like 6.3.3-b-1 passes.  Is there 
> always a bi-modal loop between 6.3.3-f and 6.1.3-a-3?  If not, what
else
> would be likely to cause S to be recognized as invalid?  You could 
> probably patch any difficulties by adding "if the certificate whose 
> revocation is being checked appears in the path, reject it" to
6.3.3-f.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>
> 05/24/2005 06:42 PM
> 
>         To:     Tom Gindin/Watson/IBM@IBMUS, <[email-masked]>
>         cc:     "'Julien Stern'" <[email-masked]>
>         Subject:        CRL Issue (Was RE: WG Last Call: AIA CRL
> extension)
> 
> 
> Tom,
> 
> 
> I assume you are talking about CRL certification path solution I
proposed
> will not permit the scenario?  I still do not see in your case, if the 
> Subject CA (cross certified CA) is revoked, you will verify the path
to it
> in the first place.  May be I am not understanding your scenario
properly.
> How does the revoked CA gets verified?
> 
> 
> Julien,
> 
> We have defined and proven the solution for how to do this.  The
scenario
> you proposed is not something X.509 worries about (A CA that is still 
> valid, but has gone bad).
> 
> On
> Behalf Of Julien Stern
> Sent: Tuesday, May 24, 2005 3:49 PM
> To: Stefan Santesson
> Cc: Tom Gindin; [email-masked]
> Subject: Re: WG Last Call: AIA CRL extension
> 
> 
> 
> On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> > Tom and Julien,
> >
> > Since this is a repetition of the discussion we had before San Diego 
> > and I don't want to repeat it here. I'm not saying that this 
> > discussion is invalid; it is just directed towards the wrong draft.
> 
> Stefan,
> 
> I agree with you. Actually, I would tend to believe that a _real_ 
> discussion would have to take place at some point regarding the 
> overall security model
> of CRL validation, but I have absolutely no objection to the AIA, as
soon
> as
> it is made clear that it's only goal is to simplify path building 
> implementations, and not to adress security issues. My very humble
take on
> the subject is that Denis and yourself have been arguing on the list
on
> absolutely valid but different matters.
> 
> So, I chose not to comment expect for my last mail (and will not any
more)
> about AIA, but I still think that a discusssion regarding revocation 
> validation should take place for RFC3280bis, eventually.
> 
> Regards,
> 
> --
> Julien Stern
> 
> >
> > As Tom pointed out:
> > > this fraudulently issued CRL will probably be validated whether it 
> > > contains an AIA or not.
> >
> > This indicates once again that this is not an issue caused by the
use
> > of AIA in CRLs but a generic CRL validation issue that belongs with 
> > RFC 3280bis and not with the CRL-AIA draft.
> >
> > Stefan Santesson
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> > > On Behalf Of Julien Stern
> > > Sent: den 24 maj 2005 09:39
> > > To: Tom Gindin
> > > Cc: [email-masked]
> > > Subject: Re: WG Last Call: AIA CRL extension
> > >
> > >
> > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > > >
> > > >         There is one scenario permitted by the "same trust
anchor"
> > rule
> > > > for CRL signers which seems to me to be a serious security hole.
> > Let us
> > > > assume a valid CA which is a direct subordinate of one of the
RP's
> > trust
> > > > anchors.  This CA issues separate CRL's and ARL's, in a quite 
> > > > usual
> > way,
> > > > and issues cross certificates.  After months or years of 
> > > > operation,
> > it
> > > > revokes one of its cross certificates because the subject's 
> > > > operator
> > has
> > > > gone rogue.  That rogue subject then issues a fraudulent CRL 
> > > > Signing certificate with the DN that the superior certificate
has
> > > > been using
> > to
> > > > sign ARL's, a public key which it has newly generated, and
various
> > > > extensions including an SKID.  It then issues an updated copy of 
> > > > an
> > old
> > > > ARL under the fraudulent CRL signer's certificate and with an
AKID
> > > > matching the fraudulent signer's SKID.  If the rogue can break 
> > > > into
> > the
> > > > repository where the CRL is expected, this fraudulently issued
CRL
> > will
> > > > probably be validated whether it contains an AIA or not.  It
will
> > > > certainly pass the "same trust anchor" condition.
> > > >         This scenario, in which a rogue CA issues an ARL 
> > > > certifiying
> > > that
> > > > its primary certificate has not been revoked and gets the ARL
> > accepted,
> > > is
> > > > possible under "same trust anchor" but not under "signed by path
> > > member".
> > >
> > > I agree with the validity of this scenario. I believe this is very 
> > > close to the issue I attempted to bring on the list a short time 
> > > ago. Of course, it assumes the existence of a rogue CA at some
point
> > > in
> > time.
> > >
> > > Note that the CRL could be directly inserted into a "long term" 
> > > signature (according to RFC3126 for example). This does not
require
> > > a repository break-in and makes the "attack" even more realistic.
> > >
> > > Regards.
> > >
> > > --
> > > Julien Stern
> > >
> > > >
> > > >                 Tom Gindin
> > > >
> > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
> > -----
> > > >
> > > >
> > > > Tom Gindin
> > > > 05/23/2005 10:46 PM
> > > >
> > > >         To:     [email-masked]
> > > >         cc:     [email-masked], [email-masked],
> > [email-masked],
> > > > [email-masked]
> > > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > > >         Subject:        Re: WG Last Call: AIA CRL extension
> > > >
> > > >         Tim:
> > > >
> > > >         I should probably have brought this up earlier, but are
we
> > > certain
> > > > that "same trust anchor" is a strong enough check that the CRL
> > signer is
> > > > the one expected by the issuing CA?  While I was not in San
Diego
> > when
> > > > this wording was included in the 3280 series, I do not really 
> > > > think
> > that
> > > > that check is strong enough.  I would suggest instead that the
CRL
> > > > signer's certificate needs to be directly issued by one of the 
> > > > CA's
> > in
> > > the
> > > > certification path back to the trust anchor used for the
> > certificate's
> > > > verification, or by that anchor itself, unless people have 
> > > > practical experience with CA structures which that rule would 
> > > > prohibit.
> > Forcing
> > > the
> > > > CRL to be issued by the CA itself (as I understand Denis to have
> > > > suggested) prohibits the reasonable case where the CRL is issued 
> > > > by
> > a
> > > > hierarchical superior, so it is IMHO too strict.
> > > >         I am personally not sure, FWIW, that a CRL should be
> > permitted
> > > to
> > > > be signed by a second-cousin certificate of the issuer's
> > certificate.
> > > By
> > > > analogy to the use of the terms in families, "sibling" 
> > > > certificates
> > > would
> > > > have the same issuer, "first-cousin" certificates would be
issued
> > > > by siblings, and "second-cousin" certificates would be issued by 
> > > > first cousins - so they are both three levels down from the same 
> > > > trust
> > anchor,
> > > > or from the last common CA in their paths.  This issue is not 
> > > > newly
> > > caused
> > > > by CRL AIA, since the same issue can arise with CRL's containing
> > only
> > > > AKID.  AIA only allows RP's to build a path (whether right or
> > > > wrong)
> > > more
> > > > quickly.
> > > >         In any case, nothing more than a note in Security
> > Considerations
> > > > is appropriate in any of our RFC's other than 3280 and its
> > successor.
> > > >
> > > >         Tom Gindin
> > > > P.S. -  The above views are mine, and not necessarily those of
my
> > > employer
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Tim Polk <[email-masked]>
> > > > Sent by: [email-masked]
> > > > 05/10/2005 05:27 PM
> > > >
> > > >         To:     [email-masked]
> > > >         cc:     [email-masked], [email-masked],
> > > [email-masked]
> > > >         Subject:        WG Last Call: AIA CRL extension
> > > >
> > > >
> > > >
> > > >
> > > > This message initiates working group Last Call for the 
> > > > specification "Internet X.509 Public Key Infrastructure:
Authority
> > > > Information
> > Access
> > > > CRL
> > > > Extension".  While some issues raised in the working group are
> > > unresolved,
> > > >
> > > > the editors believe that rough consensus supports the current 
> > > > specification.
> > > >
> > > > The URL for this Internet-Draft is:
> > > >
> > > >
http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > > >
> > > > Last Call will run for (at least) two weeks. That is, Last Call 
> > > > will
> > not
> > > > close before May 24.
> > > >
> > > > Thanks,
> > > >
> > > > Tim Polk
> > > >
> > > >
> > > >
> >
> 
> 

Content-class: urn:content-classes:message
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
Date: Wed, 25 May 2005 19:17:51 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Tom Gindin" <[email-masked]>, "Santosh Chokhani" <[email-masked]>
Cc: <[email-masked]>, "Julien Stern" <[email-masked]>
Sender: [email-masked]

Tom,

If the substitution would be successful the validation would go into an
infinite loop and fail.
Validation of S's fake CRL requires validation of C's cross certificate
to S which triggers another validation of S's fake CRL and so on.

I think we added some text against infinite loops but I don't have it
fresh in my memory.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> On Behalf Of Tom Gindin
> Sent: den 25 maj 2005 04:50
> To: Santosh Chokhani
> Cc: [email-masked]; 'Julien Stern'
> Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
> 
> 
>         Santosh:
> 
>         A relatively concrete example would be the following:
>         Assume a trust anchor called A, and CA it has issued a cross
> certificate to called C.  Further assume that C uses indirect CRL's,
and
> has issued a cross certificate without name constraints to another CA
> called S. Then assume that S goes rogue and creates a CRL signing
> certificate with the same name as C uses for its indirect CRL's (the
key
> pair in that certificate is hereinafter called the "rogue CRL
signer").
> Further assume that C finds out about this and creates a CRL listing S
as
> revoked, but that S successfully replaces that CRL in the repository
by
> one signed by the rogue CRL signer.
>         Does RFC 3280 path validation consider S invalid?  If so,
which
> step loops or fails?  It looks to me like 6.3.3-b-1 passes.  Is there
> always a bi-modal loop between 6.3.3-f and 6.1.3-a-3?  If not, what
else
> would be likely to cause S to be recognized as invalid?  You could
> probably patch any difficulties by adding "if the certificate whose
> revocation is being checked appears in the path, reject it" to
6.3.3-f.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>
> 05/24/2005 06:42 PM
> 
>         To:     Tom Gindin/Watson/IBM@IBMUS, <[email-masked]>
>         cc:     "'Julien Stern'" <[email-masked]>
>         Subject:        CRL Issue (Was RE: WG Last Call: AIA CRL
> extension)
> 
> 
> Tom,
> 
> 
> I assume you are talking about CRL certification path solution I
proposed
> will not permit the scenario?  I still do not see in your case, if the
> Subject CA (cross certified CA) is revoked, you will verify the path
to it
> in the first place.  May be I am not understanding your scenario
properly.
> How does the revoked CA gets verified?
> 
> 
> Julien,
> 
> We have defined and proven the solution for how to do this.  The
scenario
> you proposed is not something X.509 worries about (A CA that is still
> valid,
> but has gone bad).
> 
> On
> Behalf Of Julien Stern
> Sent: Tuesday, May 24, 2005 3:49 PM
> To: Stefan Santesson
> Cc: Tom Gindin; [email-masked]
> Subject: Re: WG Last Call: AIA CRL extension
> 
> 
> 
> On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> > Tom and Julien,
> >
> > Since this is a repetition of the discussion we had before San Diego
> > and I don't want to repeat it here. I'm not saying that this
> > discussion is invalid; it is just directed towards the wrong draft.
> 
> Stefan,
> 
> I agree with you. Actually, I would tend to believe that a _real_
> discussion
> would have to take place at some point regarding the overall security
> model
> of CRL validation, but I have absolutely no objection to the AIA, as
soon
> as
> it is made clear that it's only goal is to simplify path building
> implementations, and not to adress security issues. My very humble
take on
> the subject is that Denis and yourself have been arguing on the list
on
> absolutely valid but different matters.
> 
> So, I chose not to comment expect for my last mail (and will not any
more)
> about AIA, but I still think that a discusssion regarding revocation
> validation should take place for RFC3280bis, eventually.
> 
> Regards,
> 
> --
> Julien Stern
> 
> >
> > As Tom pointed out:
> > > this fraudulently issued CRL will probably be validated whether it
> > > contains an AIA or not.
> >
> > This indicates once again that this is not an issue caused by the
use
> > of AIA in CRLs but a generic CRL validation issue that belongs with
> > RFC 3280bis and not with the CRL-AIA draft.
> >
> > Stefan Santesson
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> > > On Behalf Of Julien Stern
> > > Sent: den 24 maj 2005 09:39
> > > To: Tom Gindin
> > > Cc: [email-masked]
> > > Subject: Re: WG Last Call: AIA CRL extension
> > >
> > >
> > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > > >
> > > >         There is one scenario permitted by the "same trust
anchor"
> > rule
> > > > for CRL signers which seems to me to be a serious security hole.
> > Let us
> > > > assume a valid CA which is a direct subordinate of one of the
RP's
> > trust
> > > > anchors.  This CA issues separate CRL's and ARL's, in a quite
> > > > usual
> > way,
> > > > and issues cross certificates.  After months or years of
> > > > operation,
> > it
> > > > revokes one of its cross certificates because the subject's
> > > > operator
> > has
> > > > gone rogue.  That rogue subject then issues a fraudulent CRL
> > > > Signing certificate with the DN that the superior certificate
has
> > > > been using
> > to
> > > > sign ARL's, a public key which it has newly generated, and
various
> > > > extensions including an SKID.  It then issues an updated copy of
> > > > an
> > old
> > > > ARL under the fraudulent CRL signer's certificate and with an
AKID
> > > > matching the fraudulent signer's SKID.  If the rogue can break
> > > > into
> > the
> > > > repository where the CRL is expected, this fraudulently issued
CRL
> > will
> > > > probably be validated whether it contains an AIA or not.  It
will
> > > > certainly pass the "same trust anchor" condition.
> > > >         This scenario, in which a rogue CA issues an ARL
> > > > certifiying
> > > that
> > > > its primary certificate has not been revoked and gets the ARL
> > accepted,
> > > is
> > > > possible under "same trust anchor" but not under "signed by path
> > > member".
> > >
> > > I agree with the validity of this scenario. I believe this is very
> > > close to the issue I attempted to bring on the list a short time
> > > ago. Of course, it assumes the existence of a rogue CA at some
point
> > > in
> > time.
> > >
> > > Note that the CRL could be directly inserted into a "long term"
> > > signature (according to RFC3126 for example). This does not
require
> > > a repository break-in and makes the "attack" even more realistic.
> > >
> > > Regards.
> > >
> > > --
> > > Julien Stern
> > >
> > > >
> > > >                 Tom Gindin
> > > >
> > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
> > -----
> > > >
> > > >
> > > > Tom Gindin
> > > > 05/23/2005 10:46 PM
> > > >
> > > >         To:     [email-masked]
> > > >         cc:     [email-masked], [email-masked],
> > [email-masked],
> > > > [email-masked]
> > > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > > >         Subject:        Re: WG Last Call: AIA CRL extension
> > > >
> > > >         Tim:
> > > >
> > > >         I should probably have brought this up earlier, but are
we
> > > certain
> > > > that "same trust anchor" is a strong enough check that the CRL
> > signer is
> > > > the one expected by the issuing CA?  While I was not in San
Diego
> > when
> > > > this wording was included in the 3280 series, I do not really
> > > > think
> > that
> > > > that check is strong enough.  I would suggest instead that the
CRL
> > > > signer's certificate needs to be directly issued by one of the
> > > > CA's
> > in
> > > the
> > > > certification path back to the trust anchor used for the
> > certificate's
> > > > verification, or by that anchor itself, unless people have
> > > > practical experience with CA structures which that rule would
> > > > prohibit.
> > Forcing
> > > the
> > > > CRL to be issued by the CA itself (as I understand Denis to have
> > > > suggested) prohibits the reasonable case where the CRL is issued
> > > > by
> > a
> > > > hierarchical superior, so it is IMHO too strict.
> > > >         I am personally not sure, FWIW, that a CRL should be
> > permitted
> > > to
> > > > be signed by a second-cousin certificate of the issuer's
> > certificate.
> > > By
> > > > analogy to the use of the terms in families, "sibling"
> > > > certificates
> > > would
> > > > have the same issuer, "first-cousin" certificates would be
issued
> > > > by siblings, and "second-cousin" certificates would be issued by
> > > > first cousins - so they are both three levels down from the same
> > > > trust
> > anchor,
> > > > or from the last common CA in their paths.  This issue is not
> > > > newly
> > > caused
> > > > by CRL AIA, since the same issue can arise with CRL's containing
> > only
> > > > AKID.  AIA only allows RP's to build a path (whether right or
> > > > wrong)
> > > more
> > > > quickly.
> > > >         In any case, nothing more than a note in Security
> > Considerations
> > > > is appropriate in any of our RFC's other than 3280 and its
> > successor.
> > > >
> > > >         Tom Gindin
> > > > P.S. -  The above views are mine, and not necessarily those of
my
> > > employer
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Tim Polk <[email-masked]>
> > > > Sent by: [email-masked]
> > > > 05/10/2005 05:27 PM
> > > >
> > > >         To:     [email-masked]
> > > >         cc:     [email-masked], [email-masked],
> > > [email-masked]
> > > >         Subject:        WG Last Call: AIA CRL extension
> > > >
> > > >
> > > >
> > > >
> > > > This message initiates working group Last Call for the
> > > > specification "Internet X.509 Public Key Infrastructure:
Authority
> > > > Information
> > Access
> > > > CRL
> > > > Extension".  While some issues raised in the working group are
> > > unresolved,
> > > >
> > > > the editors believe that rough consensus supports the current
> > > > specification.
> > > >
> > > > The URL for this Internet-Draft is:
> > > >
> > > >
http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > > >
> > > > Last Call will run for (at least) two weeks. That is, Last Call
> > > > will
> > not
> > > > close before May 24.
> > > >
> > > > Thanks,
> > > >
> > > > Tim Polk
> > > >
> > > >
> > > >
> >
> 
> 

Date: Wed, 25 May 2005 16:36:22 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>, Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: AIA CRL extension
Sender: [email-masked]

Stefan and Russ,

> Denis,

> I discussed this with Russ and our conclusion is that if this resolves
> your last call issues, then we can live with deleting these sentences.

If so, my concern is solved.

Thanks,

Denis

PS: Stefan, we do not need to meet anymore next week on this topic,
     and we can spend more time to enjoy some good food on the
     French Riviera.  :-)

> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>  
> 
> 
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 25 maj 2005 00:47
>>To: Russ Housley
>>Cc: [email-masked]
>>Subject: Re: WG Last Call: AIA CRL extension
>>
>>
>>Russ,
>>
>>Two points:
>>
>>1. The current text in the security considerations section contains
>>    text which suggest a solution to the problem but which is not.
>>    At least the two following sentences SHALL be deleted:
>>
>>    " As means of reducing problems and security issues related to
> 
> issuer
> 
>>    name collisions, CA names SHOULD be formed in a way that reduce
> 
> the
> 
>>    likelihood of name collisions.  Implementations validating CRLs
>>    MUST ensure that the certification path of the target certificate
>>    and the CRL issuer certification path used to validate the target
>>    certificate, terminate at the same trust anchor".
>>
>>2. We strongly agree that 3280bis MUST address this issue and
> 
> currently
> 
>>    it does not do it correctly (otherwise we would not have this
>>    loooong discussion), ... that we can continue within the scope
>>    of 3280bis.
>>
>>Denis
>>
>>
>>>Julien & Tom:
>>>
>>>Two points:
>>>
>>>1.  I understand this scenario.  The change that you advocate as a
>>>countermeasure will prevent Indirect CRLs from working in scenarios
>>
> that
> 
>>>are intended.
>>>
>>>2.  This observation has noting to do with the CRL AIA extension.
>>
> The
> 
>>>attacker is inserting the bogus revocation information into the
>>>repository.  Any relying party that uses that repository (when using
>>
> the
> 
>>>CRL AIA extension or any other configuration information to locate
>>
> it)
> 
>>>will get the bogus revocation information.
>>>
>>>If this is a concern, then it needs to be addressed in RFC3280bis,
>>
> not
> 
>>>here.
>>>
>>>Russ
>>>
>>>At 12:38 PM 5/24/2005, Julien Stern wrote:
>>>
>>>
>>>>On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
>>>>
>>>>>        There is one scenario permitted by the "same trust
>>>>
> anchor"
> 
>>rule
>>
>>>>>for CRL signers which seems to me to be a serious security hole.
>>>>
>>>>Let us
>>>>
>>>>>assume a valid CA which is a direct subordinate of one of the
>>>>
> RP's
> 
>>>>trust
>>>>
>>>>>anchors.  This CA issues separate CRL's and ARL's, in a quite
>>>>
> usual
> 
>>>>way,
>>>>
>>>>>and issues cross certificates.  After months or years of
>>>>
> operation,
> 
>>it
>>
>>>>>revokes one of its cross certificates because the subject's
>>>>
> operator
> 
>>>>has
>>>>
>>>>>gone rogue.  That rogue subject then issues a fraudulent CRL
>>>>
> Signing
> 
>>>>>certificate with the DN that the superior certificate has been
>>>>
> using
> 
>>to
>>
>>>>>sign ARL's, a public key which it has newly generated, and
>>>>
> various
> 
>>>>>extensions including an SKID.  It then issues an updated copy of
>>>>
> an
> 
>>old
>>
>>>>>ARL under the fraudulent CRL signer's certificate and with an
>>>>
> AKID
> 
>>>>>matching the fraudulent signer's SKID.  If the rogue can break
>>>>
> into
> 
>>the
>>
>>>>>repository where the CRL is expected, this fraudulently issued
>>>>
> CRL
> 
>>will
>>
>>>>>probably be validated whether it contains an AIA or not.  It will
>>>>>certainly pass the "same trust anchor" condition.
>>>>>        This scenario, in which a rogue CA issues an ARL
>>>>
> certifiying
> 
>>>>that
>>>>
>>>>>its primary certificate has not been revoked and gets the ARL
>>>>
>>>>accepted, is
>>>>
>>>>>possible under "same trust anchor" but not under "signed by path
>>>>
>>>>member".
>>>>
>>>>I agree with the validity of this scenario. I believe this is very
>>>>close to the issue I attempted to bring on the list a short time
>>>
> ago.
> 
>>>>Of course, it assumes the existence of a rogue CA at some point in
>>>
>>time.
>>
>>>>Note that the CRL could be directly inserted into a "long term"
>>>>signature (according to RFC3126 for example). This does not require
>>>>a repository break-in and makes the "attack" even more realistic.
>>>>
>>>>Regards.
>>>>
>>>>--
>>>>Julien Stern
>>>>
>>>>
>>>>>                Tom Gindin
>>>>>
>>>>>----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
>>>>
> -----
> 
>>>>>
>>>>>Tom Gindin
>>>>>05/23/2005 10:46 PM
>>>>>
>>>>>        To:     [email-masked]
>>>>>        cc:     [email-masked], [email-masked],
>>>>
>>[email-masked],
>>
>>>>>[email-masked]
>>>>>        From:   Tom Gindin/Watson/IBM@IBMUS
>>>>>        Subject:        Re: WG Last Call: AIA CRL extension
>>>>>
>>>>>        Tim:
>>>>>
>>>>>        I should probably have brought this up earlier, but are
>>>>
> we
> 
>>>>certain
>>>>
>>>>>that "same trust anchor" is a strong enough check that the CRL
>>>>
>>>>signer is
>>>>
>>>>>the one expected by the issuing CA?  While I was not in San Diego
>>>>
>>when
>>
>>>>>this wording was included in the 3280 series, I do not really
>>>>
> think
> 
>>>>that
>>>>
>>>>>that check is strong enough.  I would suggest instead that the
>>>>
> CRL
> 
>>>>>signer's certificate needs to be directly issued by one of the
>>>>
> CA's
> 
>>>>in the
>>>>
>>>>>certification path back to the trust anchor used for the
>>>>
>>certificate's
>>
>>>>>verification, or by that anchor itself, unless people have
>>>>
> practical
> 
>>>>>experience with CA structures which that rule would prohibit.
>>>>
>>>>Forcing the
>>>>
>>>>>CRL to be issued by the CA itself (as I understand Denis to have
>>>>>suggested) prohibits the reasonable case where the CRL is issued
>>>>
> by a
> 
>>>>>hierarchical superior, so it is IMHO too strict.
>>>>>        I am personally not sure, FWIW, that a CRL should be
>>>>
>>>>permitted to
>>>>
>>>>>be signed by a second-cousin certificate of the issuer's
>>>>
>>>>certificate.  By
>>>>
>>>>>analogy to the use of the terms in families, "sibling"
>>>>
> certificates
> 
>>>>would
>>>>
>>>>>have the same issuer, "first-cousin" certificates would be issued
>>>>
> by
> 
>>>>>siblings, and "second-cousin" certificates would be issued by
>>>>
> first
> 
>>>>>cousins - so they are both three levels down from the same trust
>>>>
>>>>anchor,
>>>>
>>>>>or from the last common CA in their paths.  This issue is not
>>>>
> newly
> 
>>>>caused
>>>>
>>>>>by CRL AIA, since the same issue can arise with CRL's containing
>>>>
> only
> 
>>>>>AKID.  AIA only allows RP's to build a path (whether right or
>>>>
> wrong)
> 
>>>>more
>>>>
>>>>>quickly.
>>>>>        In any case, nothing more than a note in Security
>>>>
>>>>Considerations
>>>>
>>>>>is appropriate in any of our RFC's other than 3280 and its
>>>>
> successor.
> 
>>>>>        Tom Gindin
>>>>>P.S. -  The above views are mine, and not necessarily those of my
>>>>
>>>>employer
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Tim Polk <[email-masked]>
>>>>>Sent by: [email-masked]
>>>>>05/10/2005 05:27 PM
>>>>>
>>>>>        To:     [email-masked]
>>>>>        cc:     [email-masked], [email-masked],
>>>>
>>>>[email-masked]
>>>>
>>>>>        Subject:        WG Last Call: AIA CRL extension
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>This message initiates working group Last Call for the
>>>>
> specification
> 
>>>>>"Internet X.509 Public Key Infrastructure: Authority Information
>>>>
>>Access
>>
>>>>>CRL
>>>>>Extension".  While some issues raised in the working group are
>>>>
>>>>unresolved,
>>>>
>>>>>the editors believe that rough consensus supports the current
>>>>>specification.
>>>>>
>>>>>The URL for this Internet-Draft is:
>>>>>
>>>>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
>>>>>
>>>>>Last Call will run for (at least) two weeks. That is, Last Call
>>>>
> will
> 
>>>>not
>>>>
>>>>>close before May 24.
>>>>>
>>>>>Thanks,
>>>>>
>>>>>Tim Polk
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
> 
> 

Content-class: urn:content-classes:message
Subject: RE: WG Last Call: AIA CRL extension
Date: Wed, 25 May 2005 14:49:10 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Denis,

I discussed this with Russ and our conclusion is that if this resolves
your last call issues, then we can live with deleting these sentences.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of Denis Pinkas
> Sent: den 25 maj 2005 00:47
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: WG Last Call: AIA CRL extension
> 
> 
> Russ,
> 
> Two points:
> 
> 1. The current text in the security considerations section contains
>     text which suggest a solution to the problem but which is not.
>     At least the two following sentences SHALL be deleted:
> 
>     " As means of reducing problems and security issues related to
issuer
>     name collisions, CA names SHOULD be formed in a way that reduce
the
>     likelihood of name collisions.  Implementations validating CRLs
>     MUST ensure that the certification path of the target certificate
>     and the CRL issuer certification path used to validate the target
>     certificate, terminate at the same trust anchor".
> 
> 2. We strongly agree that 3280bis MUST address this issue and
currently
>     it does not do it correctly (otherwise we would not have this
>     loooong discussion), ... that we can continue within the scope
>     of 3280bis.
> 
> Denis
> 
> > Julien & Tom:
> >
> > Two points:
> >
> > 1.  I understand this scenario.  The change that you advocate as a
> > countermeasure will prevent Indirect CRLs from working in scenarios
that
> > are intended.
> >
> > 2.  This observation has noting to do with the CRL AIA extension.
The
> > attacker is inserting the bogus revocation information into the
> > repository.  Any relying party that uses that repository (when using
the
> > CRL AIA extension or any other configuration information to locate
it)
> > will get the bogus revocation information.
> >
> > If this is a concern, then it needs to be addressed in RFC3280bis,
not
> > here.
> >
> > Russ
> >
> > At 12:38 PM 5/24/2005, Julien Stern wrote:
> >
> >> On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> >> >
> >> >         There is one scenario permitted by the "same trust
anchor"
> rule
> >> > for CRL signers which seems to me to be a serious security hole.
> >> Let us
> >> > assume a valid CA which is a direct subordinate of one of the
RP's
> >> trust
> >> > anchors.  This CA issues separate CRL's and ARL's, in a quite
usual
> >> way,
> >> > and issues cross certificates.  After months or years of
operation,
> it
> >> > revokes one of its cross certificates because the subject's
operator
> >> has
> >> > gone rogue.  That rogue subject then issues a fraudulent CRL
Signing
> >> > certificate with the DN that the superior certificate has been
using
> to
> >> > sign ARL's, a public key which it has newly generated, and
various
> >> > extensions including an SKID.  It then issues an updated copy of
an
> old
> >> > ARL under the fraudulent CRL signer's certificate and with an
AKID
> >> > matching the fraudulent signer's SKID.  If the rogue can break
into
> the
> >> > repository where the CRL is expected, this fraudulently issued
CRL
> will
> >> > probably be validated whether it contains an AIA or not.  It will
> >> > certainly pass the "same trust anchor" condition.
> >> >         This scenario, in which a rogue CA issues an ARL
certifiying
> >> that
> >> > its primary certificate has not been revoked and gets the ARL
> >> accepted, is
> >> > possible under "same trust anchor" but not under "signed by path
> >> member".
> >>
> >> I agree with the validity of this scenario. I believe this is very
> >> close to the issue I attempted to bring on the list a short time
ago.
> >> Of course, it assumes the existence of a rogue CA at some point in
> time.
> >>
> >> Note that the CRL could be directly inserted into a "long term"
> >> signature (according to RFC3126 for example). This does not require
> >> a repository break-in and makes the "attack" even more realistic.
> >>
> >> Regards.
> >>
> >> --
> >> Julien Stern
> >>
> >> >
> >> >                 Tom Gindin
> >> >
> >> > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
-----
> >> >
> >> >
> >> > Tom Gindin
> >> > 05/23/2005 10:46 PM
> >> >
> >> >         To:     [email-masked]
> >> >         cc:     [email-masked], [email-masked],
> [email-masked],
> >> > [email-masked]
> >> >         From:   Tom Gindin/Watson/IBM@IBMUS
> >> >         Subject:        Re: WG Last Call: AIA CRL extension
> >> >
> >> >         Tim:
> >> >
> >> >         I should probably have brought this up earlier, but are
we
> >> certain
> >> > that "same trust anchor" is a strong enough check that the CRL
> >> signer is
> >> > the one expected by the issuing CA?  While I was not in San Diego
> when
> >> > this wording was included in the 3280 series, I do not really
think
> >> that
> >> > that check is strong enough.  I would suggest instead that the
CRL
> >> > signer's certificate needs to be directly issued by one of the
CA's
> >> in the
> >> > certification path back to the trust anchor used for the
> certificate's
> >> > verification, or by that anchor itself, unless people have
practical
> >> > experience with CA structures which that rule would prohibit.
> >> Forcing the
> >> > CRL to be issued by the CA itself (as I understand Denis to have
> >> > suggested) prohibits the reasonable case where the CRL is issued
by a
> >> > hierarchical superior, so it is IMHO too strict.
> >> >         I am personally not sure, FWIW, that a CRL should be
> >> permitted to
> >> > be signed by a second-cousin certificate of the issuer's
> >> certificate.  By
> >> > analogy to the use of the terms in families, "sibling"
certificates
> >> would
> >> > have the same issuer, "first-cousin" certificates would be issued
by
> >> > siblings, and "second-cousin" certificates would be issued by
first
> >> > cousins - so they are both three levels down from the same trust
> >> anchor,
> >> > or from the last common CA in their paths.  This issue is not
newly
> >> caused
> >> > by CRL AIA, since the same issue can arise with CRL's containing
only
> >> > AKID.  AIA only allows RP's to build a path (whether right or
wrong)
> >> more
> >> > quickly.
> >> >         In any case, nothing more than a note in Security
> >> Considerations
> >> > is appropriate in any of our RFC's other than 3280 and its
successor.
> >> >
> >> >         Tom Gindin
> >> > P.S. -  The above views are mine, and not necessarily those of my
> >> employer
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Tim Polk <[email-masked]>
> >> > Sent by: [email-masked]
> >> > 05/10/2005 05:27 PM
> >> >
> >> >         To:     [email-masked]
> >> >         cc:     [email-masked], [email-masked],
> >> [email-masked]
> >> >         Subject:        WG Last Call: AIA CRL extension
> >> >
> >> >
> >> >
> >> >
> >> > This message initiates working group Last Call for the
specification
> >> > "Internet X.509 Public Key Infrastructure: Authority Information
> Access
> >> > CRL
> >> > Extension".  While some issues raised in the working group are
> >> unresolved,
> >> >
> >> > the editors believe that rough consensus supports the current
> >> > specification.
> >> >
> >> > The URL for this Internet-Draft is:
> >> >
> >> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> >> >
> >> > Last Call will run for (at least) two weeks. That is, Last Call
will
> >> not
> >> > close before May 24.
> >> > Thanks,
> >> > Tim Polk

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
Date: Wed, 25 May 2005 08:58:52 -0400
Importance: Normal
Sender: [email-masked]

Tom,

It is not clear from your example who the indirect CRL issuer is and what
role the "indirect CRL" plays in the attack.  If S is the indirect CRL
issuer, C should be smart enough to not create circularity (a good toolkit
will not verify path when C issues a certificate to S and points to S as the
indirect CRL issuer since it causes circularity and chicken and egg
problem).  That scenario can be easily rectified within current standard by
C not declaring S as the indirect CRL issuer for certificate issued to S.  C
can declare itself in the CDP or some other issuer.

I suspect you do not mean this.  Your example may be simpler.  To me the
attack is still not plausible.  Your scenario is not detailed enough to
illustrate an attack.  It does not seem that there is a way to validate the
certificate issued to C by S without looking at CRL issued by C, resulting
in circularity, which relying party clients should not accept. 

(Note that my November presentation to IETF in DC covered the circularity
issues in CRL and OCSP and recommendations for 3280 and 2560 in addition to
the CRL certification path)

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2005 7:50 AM
To: Santosh Chokhani
Cc: [email-masked]; 'Julien Stern'
Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension)

        Santosh:

        A relatively concrete example would be the following:
        Assume a trust anchor called A, and CA it has issued a cross 
certificate to called C.  Further assume that C uses indirect CRL's, and 
has issued a cross certificate without name constraints to another CA 
called S. Then assume that S goes rogue and creates a CRL signing 
certificate with the same name as C uses for its indirect CRL's (the key 
pair in that certificate is hereinafter called the "rogue CRL signer"). 
Further assume that C finds out about this and creates a CRL listing S as 
revoked, but that S successfully replaces that CRL in the repository by 
one signed by the rogue CRL signer.
        Does RFC 3280 path validation consider S invalid?  If so, which 
step loops or fails?  It looks to me like 6.3.3-b-1 passes.  Is there 
always a bi-modal loop between 6.3.3-f and 6.1.3-a-3?  If not, what else 
would be likely to cause S to be recognized as invalid?  You could 
probably patch any difficulties by adding "if the certificate whose 
revocation is being checked appears in the path, reject it" to 6.3.3-f.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
05/24/2005 06:42 PM
 
        To:     Tom Gindin/Watson/IBM@IBMUS, <[email-masked]>
        cc:     "'Julien Stern'" <[email-masked]>
        Subject:        CRL Issue (Was RE: WG Last Call: AIA CRL 
extension)

Tom,

I assume you are talking about CRL certification path solution I proposed
will not permit the scenario?  I still do not see in your case, if the
Subject CA (cross certified CA) is revoked, you will verify the path to it
in the first place.  May be I am not understanding your scenario properly.
How does the revoked CA gets verified?

Julien,

We have defined and proven the solution for how to do this.  The scenario
you proposed is not something X.509 worries about (A CA that is still 
valid,
but has gone bad).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Julien Stern
Sent: Tuesday, May 24, 2005 3:49 PM
To: Stefan Santesson
Cc: Tom Gindin; [email-masked]
Subject: Re: WG Last Call: AIA CRL extension

On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> Tom and Julien,
> 
> Since this is a repetition of the discussion we had before San Diego
> and I don't want to repeat it here. I'm not saying that this 
> discussion is invalid; it is just directed towards the wrong draft.

Stefan,

I agree with you. Actually, I would tend to believe that a _real_ 
discussion
would have to take place at some point regarding the overall security 
model
of CRL validation, but I have absolutely no objection to the AIA, as soon 
as
it is made clear that it's only goal is to simplify path building
implementations, and not to adress security issues. My very humble take on
the subject is that Denis and yourself have been arguing on the list on
absolutely valid but different matters.

So, I chose not to comment expect for my last mail (and will not any more)
about AIA, but I still think that a discusssion regarding revocation
validation should take place for RFC3280bis, eventually.

Regards,

--
Julien Stern

> 
> As Tom pointed out:
> > this fraudulently issued CRL will probably be validated whether it 
> > contains an AIA or not.
> 
> This indicates once again that this is not an issue caused by the use
> of AIA in CRLs but a generic CRL validation issue that belongs with 
> RFC 3280bis and not with the CRL-AIA draft.
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > On Behalf Of Julien Stern
> > Sent: den 24 maj 2005 09:39
> > To: Tom Gindin
> > Cc: [email-masked]
> > Subject: Re: WG Last Call: AIA CRL extension
> > 
> > 
> > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > >
> > >         There is one scenario permitted by the "same trust anchor"
> rule
> > > for CRL signers which seems to me to be a serious security hole.
> Let us
> > > assume a valid CA which is a direct subordinate of one of the RP's
> trust
> > > anchors.  This CA issues separate CRL's and ARL's, in a quite
> > > usual
> way,
> > > and issues cross certificates.  After months or years of
> > > operation,
> it
> > > revokes one of its cross certificates because the subject's
> > > operator
> has
> > > gone rogue.  That rogue subject then issues a fraudulent CRL
> > > Signing certificate with the DN that the superior certificate has 
> > > been using
> to
> > > sign ARL's, a public key which it has newly generated, and various
> > > extensions including an SKID.  It then issues an updated copy of 
> > > an
> old
> > > ARL under the fraudulent CRL signer's certificate and with an AKID
> > > matching the fraudulent signer's SKID.  If the rogue can break 
> > > into
> the
> > > repository where the CRL is expected, this fraudulently issued CRL
> will
> > > probably be validated whether it contains an AIA or not.  It will
> > > certainly pass the "same trust anchor" condition.
> > >         This scenario, in which a rogue CA issues an ARL 
> > > certifiying
> > that
> > > its primary certificate has not been revoked and gets the ARL
> accepted,
> > is
> > > possible under "same trust anchor" but not under "signed by path
> > member".
> > 
> > I agree with the validity of this scenario. I believe this is very
> > close to the issue I attempted to bring on the list a short time 
> > ago. Of course, it assumes the existence of a rogue CA at some point 
> > in
> time.
> > 
> > Note that the CRL could be directly inserted into a "long term"
> > signature (according to RFC3126 for example). This does not require 
> > a repository break-in and makes the "attack" even more realistic.
> > 
> > Regards.
> > 
> > --
> > Julien Stern
> > 
> > >
> > >                 Tom Gindin
> > >
> > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
> -----
> > >
> > >
> > > Tom Gindin
> > > 05/23/2005 10:46 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> [email-masked],
> > > [email-masked]
> > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > >         Subject:        Re: WG Last Call: AIA CRL extension
> > >
> > >         Tim:
> > >
> > >         I should probably have brought this up earlier, but are we
> > certain
> > > that "same trust anchor" is a strong enough check that the CRL
> signer is
> > > the one expected by the issuing CA?  While I was not in San Diego
> when
> > > this wording was included in the 3280 series, I do not really
> > > think
> that
> > > that check is strong enough.  I would suggest instead that the CRL
> > > signer's certificate needs to be directly issued by one of the 
> > > CA's
> in
> > the
> > > certification path back to the trust anchor used for the
> certificate's
> > > verification, or by that anchor itself, unless people have
> > > practical experience with CA structures which that rule would 
> > > prohibit.
> Forcing
> > the
> > > CRL to be issued by the CA itself (as I understand Denis to have
> > > suggested) prohibits the reasonable case where the CRL is issued
> > > by
> a
> > > hierarchical superior, so it is IMHO too strict.
> > >         I am personally not sure, FWIW, that a CRL should be
> permitted
> > to
> > > be signed by a second-cousin certificate of the issuer's
> certificate.
> > By
> > > analogy to the use of the terms in families, "sibling"
> > > certificates
> > would
> > > have the same issuer, "first-cousin" certificates would be issued
> > > by siblings, and "second-cousin" certificates would be issued by 
> > > first cousins - so they are both three levels down from the same 
> > > trust
> anchor,
> > > or from the last common CA in their paths.  This issue is not
> > > newly
> > caused
> > > by CRL AIA, since the same issue can arise with CRL's containing
> only
> > > AKID.  AIA only allows RP's to build a path (whether right or
> > > wrong)
> > more
> > > quickly.
> > >         In any case, nothing more than a note in Security
> Considerations
> > > is appropriate in any of our RFC's other than 3280 and its
> successor.
> > >
> > >         Tom Gindin
> > > P.S. -  The above views are mine, and not necessarily those of my
> > employer
> > >
> > >
> > >
> > >
> > >
> > > Tim Polk <[email-masked]>
> > > Sent by: [email-masked]
> > > 05/10/2005 05:27 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> > [email-masked]
> > >         Subject:        WG Last Call: AIA CRL extension
> > >
> > >
> > >
> > >
> > > This message initiates working group Last Call for the
> > > specification "Internet X.509 Public Key Infrastructure: Authority 
> > > Information
> Access
> > > CRL
> > > Extension".  While some issues raised in the working group are
> > unresolved,
> > >
> > > the editors believe that rough consensus supports the current
> > > specification.
> > >
> > > The URL for this Internet-Draft is:
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > >
> > > Last Call will run for (at least) two weeks. That is, Last Call
> > > will
> not
> > > close before May 24.
> > >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > >
> > >
> 

To: "Santosh Chokhani" <[email-masked]>
Cc: [email-masked], "'Julien Stern'" <[email-masked]>
Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
From: Tom Gindin <[email-masked]>
Date: Wed, 25 May 2005 07:49:50 -0400
Sender: [email-masked]

        Santosh:

        A relatively concrete example would be the following:
        Assume a trust anchor called A, and CA it has issued a cross 
certificate to called C.  Further assume that C uses indirect CRL's, and 
has issued a cross certificate without name constraints to another CA 
called S. Then assume that S goes rogue and creates a CRL signing 
certificate with the same name as C uses for its indirect CRL's (the key 
pair in that certificate is hereinafter called the "rogue CRL signer"). 
Further assume that C finds out about this and creates a CRL listing S as 
revoked, but that S successfully replaces that CRL in the repository by 
one signed by the rogue CRL signer.
        Does RFC 3280 path validation consider S invalid?  If so, which 
step loops or fails?  It looks to me like 6.3.3-b-1 passes.  Is there 
always a bi-modal loop between 6.3.3-f and 6.1.3-a-3?  If not, what else 
would be likely to cause S to be recognized as invalid?  You could 
probably patch any difficulties by adding "if the certificate whose 
revocation is being checked appears in the path, reject it" to 6.3.3-f.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
05/24/2005 06:42 PM
 
        To:     Tom Gindin/Watson/IBM@IBMUS, <[email-masked]>
        cc:     "'Julien Stern'" <[email-masked]>
        Subject:        CRL Issue (Was RE: WG Last Call: AIA CRL 
extension)

Tom,

I assume you are talking about CRL certification path solution I proposed
will not permit the scenario?  I still do not see in your case, if the
Subject CA (cross certified CA) is revoked, you will verify the path to it
in the first place.  May be I am not understanding your scenario properly.
How does the revoked CA gets verified?

Julien,

We have defined and proven the solution for how to do this.  The scenario
you proposed is not something X.509 worries about (A CA that is still 
valid,
but has gone bad).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Julien Stern
Sent: Tuesday, May 24, 2005 3:49 PM
To: Stefan Santesson
Cc: Tom Gindin; [email-masked]
Subject: Re: WG Last Call: AIA CRL extension

On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> Tom and Julien,
> 
> Since this is a repetition of the discussion we had before San Diego 
> and I don't want to repeat it here. I'm not saying that this 
> discussion is invalid; it is just directed towards the wrong draft.

Stefan,

I agree with you. Actually, I would tend to believe that a _real_ 
discussion
would have to take place at some point regarding the overall security 
model
of CRL validation, but I have absolutely no objection to the AIA, as soon 
as
it is made clear that it's only goal is to simplify path building
implementations, and not to adress security issues. My very humble take on
the subject is that Denis and yourself have been arguing on the list on
absolutely valid but different matters.

So, I chose not to comment expect for my last mail (and will not any more)
about AIA, but I still think that a discusssion regarding revocation
validation should take place for RFC3280bis, eventually.

Regards,

--
Julien Stern

> 
> As Tom pointed out:
> > this fraudulently issued CRL will probably be validated whether it
> > contains an AIA or not.
> 
> This indicates once again that this is not an issue caused by the use 
> of AIA in CRLs but a generic CRL validation issue that belongs with 
> RFC 3280bis and not with the CRL-AIA draft.
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > On Behalf Of Julien Stern
> > Sent: den 24 maj 2005 09:39
> > To: Tom Gindin
> > Cc: [email-masked]
> > Subject: Re: WG Last Call: AIA CRL extension
> > 
> > 
> > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > >
> > >         There is one scenario permitted by the "same trust anchor"
> rule
> > > for CRL signers which seems to me to be a serious security hole.
> Let us
> > > assume a valid CA which is a direct subordinate of one of the RP's
> trust
> > > anchors.  This CA issues separate CRL's and ARL's, in a quite 
> > > usual
> way,
> > > and issues cross certificates.  After months or years of 
> > > operation,
> it
> > > revokes one of its cross certificates because the subject's 
> > > operator
> has
> > > gone rogue.  That rogue subject then issues a fraudulent CRL 
> > > Signing certificate with the DN that the superior certificate has 
> > > been using
> to
> > > sign ARL's, a public key which it has newly generated, and various 
> > > extensions including an SKID.  It then issues an updated copy of 
> > > an
> old
> > > ARL under the fraudulent CRL signer's certificate and with an AKID 
> > > matching the fraudulent signer's SKID.  If the rogue can break 
> > > into
> the
> > > repository where the CRL is expected, this fraudulently issued CRL
> will
> > > probably be validated whether it contains an AIA or not.  It will 
> > > certainly pass the "same trust anchor" condition.
> > >         This scenario, in which a rogue CA issues an ARL 
> > > certifiying
> > that
> > > its primary certificate has not been revoked and gets the ARL
> accepted,
> > is
> > > possible under "same trust anchor" but not under "signed by path
> > member".
> > 
> > I agree with the validity of this scenario. I believe this is very 
> > close to the issue I attempted to bring on the list a short time 
> > ago. Of course, it assumes the existence of a rogue CA at some point 
> > in
> time.
> > 
> > Note that the CRL could be directly inserted into a "long term" 
> > signature (according to RFC3126 for example). This does not require 
> > a repository break-in and makes the "attack" even more realistic.
> > 
> > Regards.
> > 
> > --
> > Julien Stern
> > 
> > >
> > >                 Tom Gindin
> > >
> > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
> -----
> > >
> > >
> > > Tom Gindin
> > > 05/23/2005 10:46 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> [email-masked],
> > > [email-masked]
> > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > >         Subject:        Re: WG Last Call: AIA CRL extension
> > >
> > >         Tim:
> > >
> > >         I should probably have brought this up earlier, but are we
> > certain
> > > that "same trust anchor" is a strong enough check that the CRL
> signer is
> > > the one expected by the issuing CA?  While I was not in San Diego
> when
> > > this wording was included in the 3280 series, I do not really 
> > > think
> that
> > > that check is strong enough.  I would suggest instead that the CRL 
> > > signer's certificate needs to be directly issued by one of the 
> > > CA's
> in
> > the
> > > certification path back to the trust anchor used for the
> certificate's
> > > verification, or by that anchor itself, unless people have 
> > > practical experience with CA structures which that rule would 
> > > prohibit.
> Forcing
> > the
> > > CRL to be issued by the CA itself (as I understand Denis to have
> > > suggested) prohibits the reasonable case where the CRL is issued 
> > > by
> a
> > > hierarchical superior, so it is IMHO too strict.
> > >         I am personally not sure, FWIW, that a CRL should be
> permitted
> > to
> > > be signed by a second-cousin certificate of the issuer's
> certificate.
> > By
> > > analogy to the use of the terms in families, "sibling" 
> > > certificates
> > would
> > > have the same issuer, "first-cousin" certificates would be issued 
> > > by siblings, and "second-cousin" certificates would be issued by 
> > > first cousins - so they are both three levels down from the same 
> > > trust
> anchor,
> > > or from the last common CA in their paths.  This issue is not 
> > > newly
> > caused
> > > by CRL AIA, since the same issue can arise with CRL's containing
> only
> > > AKID.  AIA only allows RP's to build a path (whether right or 
> > > wrong)
> > more
> > > quickly.
> > >         In any case, nothing more than a note in Security
> Considerations
> > > is appropriate in any of our RFC's other than 3280 and its
> successor.
> > >
> > >         Tom Gindin
> > > P.S. -  The above views are mine, and not necessarily those of my
> > employer
> > >
> > >
> > >
> > >
> > >
> > > Tim Polk <[email-masked]>
> > > Sent by: [email-masked]
> > > 05/10/2005 05:27 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> > [email-masked]
> > >         Subject:        WG Last Call: AIA CRL extension
> > >
> > >
> > >
> > >
> > > This message initiates working group Last Call for the 
> > > specification "Internet X.509 Public Key Infrastructure: Authority 
> > > Information
> Access
> > > CRL
> > > Extension".  While some issues raised in the working group are
> > unresolved,
> > >
> > > the editors believe that rough consensus supports the current 
> > > specification.
> > >
> > > The URL for this Internet-Draft is:
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > >
> > > Last Call will run for (at least) two weeks. That is, Last Call 
> > > will
> not
> > > close before May 24.
> > >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > >
> > >
> 

Date: Wed, 25 May 2005 09:46:31 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: AIA CRL extension
Sender: [email-masked]

Russ,

Two points:

1. The current text in the security considerations section contains
    text which suggest a solution to the problem but which is not.
    At least the two following sentences SHALL be deleted:

    " As means of reducing problems and security issues related to issuer
    name collisions, CA names SHOULD be formed in a way that reduce the
    likelihood of name collisions.  Implementations validating CRLs
    MUST ensure that the certification path of the target certificate
    and the CRL issuer certification path used to validate the target
    certificate, terminate at the same trust anchor".

2. We strongly agree that 3280bis MUST address this issue and currently
    it does not do it correctly (otherwise we would not have this
    loooong discussion), ... that we can continue within the scope
    of 3280bis.

Denis

> Julien & Tom:
> 
> Two points:
> 
> 1.  I understand this scenario.  The change that you advocate as a 
> countermeasure will prevent Indirect CRLs from working in scenarios that 
> are intended.
> 
> 2.  This observation has noting to do with the CRL AIA extension.  The 
> attacker is inserting the bogus revocation information into the 
> repository.  Any relying party that uses that repository (when using the 
> CRL AIA extension or any other configuration information to locate it) 
> will get the bogus revocation information.
> 
> If this is a concern, then it needs to be addressed in RFC3280bis, not 
> here.
> 
> Russ
> 
> At 12:38 PM 5/24/2005, Julien Stern wrote:
> 
>> On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
>> >
>> >         There is one scenario permitted by the "same trust anchor" rule
>> > for CRL signers which seems to me to be a serious security hole.  
>> Let us
>> > assume a valid CA which is a direct subordinate of one of the RP's 
>> trust
>> > anchors.  This CA issues separate CRL's and ARL's, in a quite usual 
>> way,
>> > and issues cross certificates.  After months or years of operation, it
>> > revokes one of its cross certificates because the subject's operator 
>> has
>> > gone rogue.  That rogue subject then issues a fraudulent CRL Signing
>> > certificate with the DN that the superior certificate has been using to
>> > sign ARL's, a public key which it has newly generated, and various
>> > extensions including an SKID.  It then issues an updated copy of an old
>> > ARL under the fraudulent CRL signer's certificate and with an AKID
>> > matching the fraudulent signer's SKID.  If the rogue can break into the
>> > repository where the CRL is expected, this fraudulently issued CRL will
>> > probably be validated whether it contains an AIA or not.  It will
>> > certainly pass the "same trust anchor" condition.
>> >         This scenario, in which a rogue CA issues an ARL certifiying 
>> that
>> > its primary certificate has not been revoked and gets the ARL 
>> accepted, is
>> > possible under "same trust anchor" but not under "signed by path 
>> member".
>>
>> I agree with the validity of this scenario. I believe this is very
>> close to the issue I attempted to bring on the list a short time ago.
>> Of course, it assumes the existence of a rogue CA at some point in time.
>>
>> Note that the CRL could be directly inserted into a "long term"
>> signature (according to RFC3126 for example). This does not require
>> a repository break-in and makes the "attack" even more realistic.
>>
>> Regards.
>>
>> -- 
>> Julien Stern
>>
>> >
>> >                 Tom Gindin
>> >
>> > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM -----
>> >
>> >
>> > Tom Gindin
>> > 05/23/2005 10:46 PM
>> >
>> >         To:     [email-masked]
>> >         cc:     [email-masked], [email-masked], [email-masked],
>> > [email-masked]
>> >         From:   Tom Gindin/Watson/IBM@IBMUS
>> >         Subject:        Re: WG Last Call: AIA CRL extension
>> >
>> >         Tim:
>> >
>> >         I should probably have brought this up earlier, but are we 
>> certain
>> > that "same trust anchor" is a strong enough check that the CRL 
>> signer is
>> > the one expected by the issuing CA?  While I was not in San Diego when
>> > this wording was included in the 3280 series, I do not really think 
>> that
>> > that check is strong enough.  I would suggest instead that the CRL
>> > signer's certificate needs to be directly issued by one of the CA's 
>> in the
>> > certification path back to the trust anchor used for the certificate's
>> > verification, or by that anchor itself, unless people have practical
>> > experience with CA structures which that rule would prohibit.  
>> Forcing the
>> > CRL to be issued by the CA itself (as I understand Denis to have
>> > suggested) prohibits the reasonable case where the CRL is issued by a
>> > hierarchical superior, so it is IMHO too strict.
>> >         I am personally not sure, FWIW, that a CRL should be 
>> permitted to
>> > be signed by a second-cousin certificate of the issuer's 
>> certificate.  By
>> > analogy to the use of the terms in families, "sibling" certificates 
>> would
>> > have the same issuer, "first-cousin" certificates would be issued by
>> > siblings, and "second-cousin" certificates would be issued by first
>> > cousins - so they are both three levels down from the same trust 
>> anchor,
>> > or from the last common CA in their paths.  This issue is not newly 
>> caused
>> > by CRL AIA, since the same issue can arise with CRL's containing only
>> > AKID.  AIA only allows RP's to build a path (whether right or wrong) 
>> more
>> > quickly.
>> >         In any case, nothing more than a note in Security 
>> Considerations
>> > is appropriate in any of our RFC's other than 3280 and its successor.
>> >
>> >         Tom Gindin
>> > P.S. -  The above views are mine, and not necessarily those of my 
>> employer
>> >
>> >
>> >
>> >
>> >
>> > Tim Polk <[email-masked]>
>> > Sent by: [email-masked]
>> > 05/10/2005 05:27 PM
>> >
>> >         To:     [email-masked]
>> >         cc:     [email-masked], [email-masked], 
>> [email-masked]
>> >         Subject:        WG Last Call: AIA CRL extension
>> >
>> >
>> >
>> >
>> > This message initiates working group Last Call for the specification
>> > "Internet X.509 Public Key Infrastructure: Authority Information Access
>> > CRL
>> > Extension".  While some issues raised in the working group are 
>> unresolved,
>> >
>> > the editors believe that rough consensus supports the current
>> > specification.
>> >
>> > The URL for this Internet-Draft is:
>> >
>> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
>> >
>> > Last Call will run for (at least) two weeks. That is, Last Call will 
>> not
>> > close before May 24.
>> >
>> > Thanks,
>> >
>> > Tim Polk
>> >
>> >
>> >
> 
> 
> 
> 

From: "Santosh Chokhani" <[email-masked]>
To: "'Tom Gindin'" <[email-masked]>, <[email-masked]>
Cc: "'Julien Stern'" <[email-masked]>
Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension)
Date: Tue, 24 May 2005 18:42:31 -0400
Importance: Normal
Sender: [email-masked]

Tom,

I assume you are talking about CRL certification path solution I proposed
will not permit the scenario?  I still do not see in your case, if the
Subject CA (cross certified CA) is revoked, you will verify the path to it
in the first place.  May be I am not understanding your scenario properly.
How does the revoked CA gets verified?

Julien,

We have defined and proven the solution for how to do this.  The scenario
you proposed is not something X.509 worries about (A CA that is still valid,
but has gone bad).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Tuesday, May 24, 2005 3:49 PM
To: Stefan Santesson
Cc: Tom Gindin; [email-masked]
Subject: Re: WG Last Call: AIA CRL extension

On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> Tom and Julien,
> 
> Since this is a repetition of the discussion we had before San Diego 
> and I don't want to repeat it here. I'm not saying that this 
> discussion is invalid; it is just directed towards the wrong draft.

Stefan,

I agree with you. Actually, I would tend to believe that a _real_ discussion
would have to take place at some point regarding the overall security model
of CRL validation, but I have absolutely no objection to the AIA, as soon as
it is made clear that it's only goal is to simplify path building
implementations, and not to adress security issues. My very humble take on
the subject is that Denis and yourself have been arguing on the list on
absolutely valid but different matters.

So, I chose not to comment expect for my last mail (and will not any more)
about AIA, but I still think that a discusssion regarding revocation
validation should take place for RFC3280bis, eventually.

Regards,

--
Julien Stern

> 
> As Tom pointed out:
> > this fraudulently issued CRL will probably be validated whether it
> > contains an AIA or not.
> 
> This indicates once again that this is not an issue caused by the use 
> of AIA in CRLs but a generic CRL validation issue that belongs with 
> RFC 3280bis and not with the CRL-AIA draft.
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>  
> 
> > On Behalf Of Julien Stern
> > Sent: den 24 maj 2005 09:39
> > To: Tom Gindin
> > Cc: [email-masked]
> > Subject: Re: WG Last Call: AIA CRL extension
> > 
> > 
> > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > >
> > >         There is one scenario permitted by the "same trust anchor"
> rule
> > > for CRL signers which seems to me to be a serious security hole.
> Let us
> > > assume a valid CA which is a direct subordinate of one of the RP's
> trust
> > > anchors.  This CA issues separate CRL's and ARL's, in a quite 
> > > usual
> way,
> > > and issues cross certificates.  After months or years of 
> > > operation,
> it
> > > revokes one of its cross certificates because the subject's 
> > > operator
> has
> > > gone rogue.  That rogue subject then issues a fraudulent CRL 
> > > Signing certificate with the DN that the superior certificate has 
> > > been using
> to
> > > sign ARL's, a public key which it has newly generated, and various 
> > > extensions including an SKID.  It then issues an updated copy of 
> > > an
> old
> > > ARL under the fraudulent CRL signer's certificate and with an AKID 
> > > matching the fraudulent signer's SKID.  If the rogue can break 
> > > into
> the
> > > repository where the CRL is expected, this fraudulently issued CRL
> will
> > > probably be validated whether it contains an AIA or not.  It will 
> > > certainly pass the "same trust anchor" condition.
> > >         This scenario, in which a rogue CA issues an ARL 
> > > certifiying
> > that
> > > its primary certificate has not been revoked and gets the ARL
> accepted,
> > is
> > > possible under "same trust anchor" but not under "signed by path
> > member".
> > 
> > I agree with the validity of this scenario. I believe this is very 
> > close to the issue I attempted to bring on the list a short time 
> > ago. Of course, it assumes the existence of a rogue CA at some point 
> > in
> time.
> > 
> > Note that the CRL could be directly inserted into a "long term" 
> > signature (according to RFC3126 for example). This does not require 
> > a repository break-in and makes the "attack" even more realistic.
> > 
> > Regards.
> > 
> > --
> > Julien Stern
> > 
> > >
> > >                 Tom Gindin
> > >
> > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
> -----
> > >
> > >
> > > Tom Gindin
> > > 05/23/2005 10:46 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> [email-masked],
> > > [email-masked]
> > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > >         Subject:        Re: WG Last Call: AIA CRL extension
> > >
> > >         Tim:
> > >
> > >         I should probably have brought this up earlier, but are we
> > certain
> > > that "same trust anchor" is a strong enough check that the CRL
> signer is
> > > the one expected by the issuing CA?  While I was not in San Diego
> when
> > > this wording was included in the 3280 series, I do not really 
> > > think
> that
> > > that check is strong enough.  I would suggest instead that the CRL 
> > > signer's certificate needs to be directly issued by one of the 
> > > CA's
> in
> > the
> > > certification path back to the trust anchor used for the
> certificate's
> > > verification, or by that anchor itself, unless people have 
> > > practical experience with CA structures which that rule would 
> > > prohibit.
> Forcing
> > the
> > > CRL to be issued by the CA itself (as I understand Denis to have
> > > suggested) prohibits the reasonable case where the CRL is issued 
> > > by
> a
> > > hierarchical superior, so it is IMHO too strict.
> > >         I am personally not sure, FWIW, that a CRL should be
> permitted
> > to
> > > be signed by a second-cousin certificate of the issuer's
> certificate.
> > By
> > > analogy to the use of the terms in families, "sibling" 
> > > certificates
> > would
> > > have the same issuer, "first-cousin" certificates would be issued 
> > > by siblings, and "second-cousin" certificates would be issued by 
> > > first cousins - so they are both three levels down from the same 
> > > trust
> anchor,
> > > or from the last common CA in their paths.  This issue is not 
> > > newly
> > caused
> > > by CRL AIA, since the same issue can arise with CRL's containing
> only
> > > AKID.  AIA only allows RP's to build a path (whether right or 
> > > wrong)
> > more
> > > quickly.
> > >         In any case, nothing more than a note in Security
> Considerations
> > > is appropriate in any of our RFC's other than 3280 and its
> successor.
> > >
> > >         Tom Gindin
> > > P.S. -  The above views are mine, and not necessarily those of my
> > employer
> > >
> > >
> > >
> > >
> > >
> > > Tim Polk <[email-masked]>
> > > Sent by: [email-masked]
> > > 05/10/2005 05:27 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> > [email-masked]
> > >         Subject:        WG Last Call: AIA CRL extension
> > >
> > >
> > >
> > >
> > > This message initiates working group Last Call for the 
> > > specification "Internet X.509 Public Key Infrastructure: Authority 
> > > Information
> Access
> > > CRL
> > > Extension".  While some issues raised in the working group are
> > unresolved,
> > >
> > > the editors believe that rough consensus supports the current 
> > > specification.
> > >
> > > The URL for this Internet-Draft is:
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > >
> > > Last Call will run for (at least) two weeks. That is, Last Call 
> > > will
> not
> > > close before May 24.
> > >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > >
> > >
> 

From: "Julien Stern" <[email-masked]>
Date: Tue, 24 May 2005 21:48:31 +0200
To: Stefan Santesson <[email-masked]>
Cc: Tom Gindin <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: AIA CRL extension
Mail-Followup-To: Julien Stern <[email-masked]>, Stefan Santesson <[email-masked]>, Tom Gindin <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote:
> Tom and Julien,
> 
> Since this is a repetition of the discussion we had before San Diego and
> I don't want to repeat it here. I'm not saying that this discussion is
> invalid; it is just directed towards the wrong draft. 

Stefan,

I agree with you. Actually, I would tend to believe that a _real_
discussion would have to take place at some point regarding the overall
security model of CRL validation, but I have absolutely no objection to
the AIA, as soon as it is made clear that it's only goal is to simplify
path building implementations, and not to adress security issues. My
very humble take on the subject is that Denis and yourself have been
arguing on the list on absolutely valid but different matters.

So, I chose not to comment expect for my last mail (and will not
any more) about AIA, but I still think that a discusssion regarding
revocation validation should take place for RFC3280bis, eventually.

Regards,

--
Julien Stern

> 
> As Tom pointed out:
> > this fraudulently issued CRL will probably be validated whether it 
> > contains an AIA or not.
> 
> This indicates once again that this is not an issue caused by the use of
> AIA in CRLs but a generic CRL validation issue that belongs with RFC
> 3280bis and not with the CRL-AIA draft.
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>  
> 
> > On Behalf Of Julien Stern
> > Sent: den 24 maj 2005 09:39
> > To: Tom Gindin
> > Cc: [email-masked]
> > Subject: Re: WG Last Call: AIA CRL extension
> > 
> > 
> > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> > >
> > >         There is one scenario permitted by the "same trust anchor"
> rule
> > > for CRL signers which seems to me to be a serious security hole.
> Let us
> > > assume a valid CA which is a direct subordinate of one of the RP's
> trust
> > > anchors.  This CA issues separate CRL's and ARL's, in a quite usual
> way,
> > > and issues cross certificates.  After months or years of operation,
> it
> > > revokes one of its cross certificates because the subject's operator
> has
> > > gone rogue.  That rogue subject then issues a fraudulent CRL Signing
> > > certificate with the DN that the superior certificate has been using
> to
> > > sign ARL's, a public key which it has newly generated, and various
> > > extensions including an SKID.  It then issues an updated copy of an
> old
> > > ARL under the fraudulent CRL signer's certificate and with an AKID
> > > matching the fraudulent signer's SKID.  If the rogue can break into
> the
> > > repository where the CRL is expected, this fraudulently issued CRL
> will
> > > probably be validated whether it contains an AIA or not.  It will
> > > certainly pass the "same trust anchor" condition.
> > >         This scenario, in which a rogue CA issues an ARL certifiying
> > that
> > > its primary certificate has not been revoked and gets the ARL
> accepted,
> > is
> > > possible under "same trust anchor" but not under "signed by path
> > member".
> > 
> > I agree with the validity of this scenario. I believe this is very
> > close to the issue I attempted to bring on the list a short time ago.
> > Of course, it assumes the existence of a rogue CA at some point in
> time.
> > 
> > Note that the CRL could be directly inserted into a "long term"
> > signature (according to RFC3126 for example). This does not require
> > a repository break-in and makes the "attack" even more realistic.
> > 
> > Regards.
> > 
> > --
> > Julien Stern
> > 
> > >
> > >                 Tom Gindin
> > >
> > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
> -----
> > >
> > >
> > > Tom Gindin
> > > 05/23/2005 10:46 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> [email-masked],
> > > [email-masked]
> > >         From:   Tom Gindin/Watson/IBM@IBMUS
> > >         Subject:        Re: WG Last Call: AIA CRL extension
> > >
> > >         Tim:
> > >
> > >         I should probably have brought this up earlier, but are we
> > certain
> > > that "same trust anchor" is a strong enough check that the CRL
> signer is
> > > the one expected by the issuing CA?  While I was not in San Diego
> when
> > > this wording was included in the 3280 series, I do not really think
> that
> > > that check is strong enough.  I would suggest instead that the CRL
> > > signer's certificate needs to be directly issued by one of the CA's
> in
> > the
> > > certification path back to the trust anchor used for the
> certificate's
> > > verification, or by that anchor itself, unless people have practical
> > > experience with CA structures which that rule would prohibit.
> Forcing
> > the
> > > CRL to be issued by the CA itself (as I understand Denis to have
> > > suggested) prohibits the reasonable case where the CRL is issued by
> a
> > > hierarchical superior, so it is IMHO too strict.
> > >         I am personally not sure, FWIW, that a CRL should be
> permitted
> > to
> > > be signed by a second-cousin certificate of the issuer's
> certificate.
> > By
> > > analogy to the use of the terms in families, "sibling" certificates
> > would
> > > have the same issuer, "first-cousin" certificates would be issued by
> > > siblings, and "second-cousin" certificates would be issued by first
> > > cousins - so they are both three levels down from the same trust
> anchor,
> > > or from the last common CA in their paths.  This issue is not newly
> > caused
> > > by CRL AIA, since the same issue can arise with CRL's containing
> only
> > > AKID.  AIA only allows RP's to build a path (whether right or wrong)
> > more
> > > quickly.
> > >         In any case, nothing more than a note in Security
> Considerations
> > > is appropriate in any of our RFC's other than 3280 and its
> successor.
> > >
> > >         Tom Gindin
> > > P.S. -  The above views are mine, and not necessarily those of my
> > employer
> > >
> > >
> > >
> > >
> > >
> > > Tim Polk <[email-masked]>
> > > Sent by: [email-masked]
> > > 05/10/2005 05:27 PM
> > >
> > >         To:     [email-masked]
> > >         cc:     [email-masked], [email-masked],
> > [email-masked]
> > >         Subject:        WG Last Call: AIA CRL extension
> > >
> > >
> > >
> > >
> > > This message initiates working group Last Call for the specification
> > > "Internet X.509 Public Key Infrastructure: Authority Information
> Access
> > > CRL
> > > Extension".  While some issues raised in the working group are
> > unresolved,
> > >
> > > the editors believe that rough consensus supports the current
> > > specification.
> > >
> > > The URL for this Internet-Draft is:
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> > >
> > > Last Call will run for (at least) two weeks. That is, Last Call will
> not
> > > close before May 24.
> > >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > >
> > >
> 

Date: Tue, 24 May 2005 14:28:42 -0400
To: "Julien Stern" <[email-masked]>, Tom Gindin <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: WG Last Call: AIA CRL extension
Cc: [email-masked]
Sender: [email-masked]

Julien & Tom:

Two points:

1.  I understand this scenario.  The change that you advocate as a 
countermeasure will prevent Indirect CRLs from working in scenarios that 
are intended.

2.  This observation has noting to do with the CRL AIA extension.  The 
attacker is inserting the bogus revocation information into the 
repository.  Any relying party that uses that repository (when using the 
CRL AIA extension or any other configuration information to locate it) will 
get the bogus revocation information.

If this is a concern, then it needs to be addressed in RFC3280bis, not here.

Russ

At 12:38 PM 5/24/2005, Julien Stern wrote:

>On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> >
> >         There is one scenario permitted by the "same trust anchor" rule
> > for CRL signers which seems to me to be a serious security hole.  Let us
> > assume a valid CA which is a direct subordinate of one of the RP's trust
> > anchors.  This CA issues separate CRL's and ARL's, in a quite usual way,
> > and issues cross certificates.  After months or years of operation, it
> > revokes one of its cross certificates because the subject's operator has
> > gone rogue.  That rogue subject then issues a fraudulent CRL Signing
> > certificate with the DN that the superior certificate has been using to
> > sign ARL's, a public key which it has newly generated, and various
> > extensions including an SKID.  It then issues an updated copy of an old
> > ARL under the fraudulent CRL signer's certificate and with an AKID
> > matching the fraudulent signer's SKID.  If the rogue can break into the
> > repository where the CRL is expected, this fraudulently issued CRL will
> > probably be validated whether it contains an AIA or not.  It will
> > certainly pass the "same trust anchor" condition.
> >         This scenario, in which a rogue CA issues an ARL certifiying that
> > its primary certificate has not been revoked and gets the ARL accepted, is
> > possible under "same trust anchor" but not under "signed by path member".
>
>I agree with the validity of this scenario. I believe this is very
>close to the issue I attempted to bring on the list a short time ago.
>Of course, it assumes the existence of a rogue CA at some point in time.
>
>Note that the CRL could be directly inserted into a "long term"
>signature (according to RFC3126 for example). This does not require
>a repository break-in and makes the "attack" even more realistic.
>
>Regards.
>
>--
>Julien Stern
>
> >
> >                 Tom Gindin
> >
> > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM -----
> >
> >
> > Tom Gindin
> > 05/23/2005 10:46 PM
> >
> >         To:     [email-masked]
> >         cc:     [email-masked], [email-masked], [email-masked],
> > [email-masked]
> >         From:   Tom Gindin/Watson/IBM@IBMUS
> >         Subject:        Re: WG Last Call: AIA CRL extension
> >
> >         Tim:
> >
> >         I should probably have brought this up earlier, but are we certain
> > that "same trust anchor" is a strong enough check that the CRL signer is
> > the one expected by the issuing CA?  While I was not in San Diego when
> > this wording was included in the 3280 series, I do not really think that
> > that check is strong enough.  I would suggest instead that the CRL
> > signer's certificate needs to be directly issued by one of the CA's in the
> > certification path back to the trust anchor used for the certificate's
> > verification, or by that anchor itself, unless people have practical
> > experience with CA structures which that rule would prohibit.  Forcing the
> > CRL to be issued by the CA itself (as I understand Denis to have
> > suggested) prohibits the reasonable case where the CRL is issued by a
> > hierarchical superior, so it is IMHO too strict.
> >         I am personally not sure, FWIW, that a CRL should be permitted to
> > be signed by a second-cousin certificate of the issuer's certificate.  By
> > analogy to the use of the terms in families, "sibling" certificates would
> > have the same issuer, "first-cousin" certificates would be issued by
> > siblings, and "second-cousin" certificates would be issued by first
> > cousins - so they are both three levels down from the same trust anchor,
> > or from the last common CA in their paths.  This issue is not newly caused
> > by CRL AIA, since the same issue can arise with CRL's containing only
> > AKID.  AIA only allows RP's to build a path (whether right or wrong) more
> > quickly.
> >         In any case, nothing more than a note in Security Considerations
> > is appropriate in any of our RFC's other than 3280 and its successor.
> >
> >         Tom Gindin
> > P.S. -  The above views are mine, and not necessarily those of my employer
> >
> >
> >
> >
> >
> > Tim Polk <[email-masked]>
> > Sent by: [email-masked]
> > 05/10/2005 05:27 PM
> >
> >         To:     [email-masked]
> >         cc:     [email-masked], [email-masked], [email-masked]
> >         Subject:        WG Last Call: AIA CRL extension
> >
> >
> >
> >
> > This message initiates working group Last Call for the specification
> > "Internet X.509 Public Key Infrastructure: Authority Information Access
> > CRL
> > Extension".  While some issues raised in the working group are unresolved,
> >
> > the editors believe that rough consensus supports the current
> > specification.
> >
> > The URL for this Internet-Draft is:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> >
> > Last Call will run for (at least) two weeks. That is, Last Call will not
> > close before May 24.
> >
> > Thanks,
> >
> > Tim Polk
> >
> >
> >

Content-class: urn:content-classes:message
Subject: RE: WG Last Call: AIA CRL extension
Date: Tue, 24 May 2005 19:28:11 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Julien Stern" <[email-masked]>, "Tom Gindin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Tom and Julien,

Since this is a repetition of the discussion we had before San Diego and
I don't want to repeat it here. I'm not saying that this discussion is
invalid; it is just directed towards the wrong draft. 

As Tom pointed out:
> this fraudulently issued CRL will probably be validated whether it 
> contains an AIA or not.

This indicates once again that this is not an issue caused by the use of
AIA in CRLs but a generic CRL validation issue that belongs with RFC
3280bis and not with the CRL-AIA draft.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of Julien Stern
> Sent: den 24 maj 2005 09:39
> To: Tom Gindin
> Cc: [email-masked]
> Subject: Re: WG Last Call: AIA CRL extension
> 
> 
> On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> >
> >         There is one scenario permitted by the "same trust anchor"
rule
> > for CRL signers which seems to me to be a serious security hole.
Let us
> > assume a valid CA which is a direct subordinate of one of the RP's
trust
> > anchors.  This CA issues separate CRL's and ARL's, in a quite usual
way,
> > and issues cross certificates.  After months or years of operation,
it
> > revokes one of its cross certificates because the subject's operator
has
> > gone rogue.  That rogue subject then issues a fraudulent CRL Signing
> > certificate with the DN that the superior certificate has been using
to
> > sign ARL's, a public key which it has newly generated, and various
> > extensions including an SKID.  It then issues an updated copy of an
old
> > ARL under the fraudulent CRL signer's certificate and with an AKID
> > matching the fraudulent signer's SKID.  If the rogue can break into
the
> > repository where the CRL is expected, this fraudulently issued CRL
will
> > probably be validated whether it contains an AIA or not.  It will
> > certainly pass the "same trust anchor" condition.
> >         This scenario, in which a rogue CA issues an ARL certifiying
> that
> > its primary certificate has not been revoked and gets the ARL
accepted,
> is
> > possible under "same trust anchor" but not under "signed by path
> member".
> 
> I agree with the validity of this scenario. I believe this is very
> close to the issue I attempted to bring on the list a short time ago.
> Of course, it assumes the existence of a rogue CA at some point in
time.
> 
> Note that the CRL could be directly inserted into a "long term"
> signature (according to RFC3126 for example). This does not require
> a repository break-in and makes the "attack" even more realistic.
> 
> Regards.
> 
> --
> Julien Stern
> 
> >
> >                 Tom Gindin
> >
> > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM
-----
> >
> >
> > Tom Gindin
> > 05/23/2005 10:46 PM
> >
> >         To:     [email-masked]
> >         cc:     [email-masked], [email-masked],
[email-masked],
> > [email-masked]
> >         From:   Tom Gindin/Watson/IBM@IBMUS
> >         Subject:        Re: WG Last Call: AIA CRL extension
> >
> >         Tim:
> >
> >         I should probably have brought this up earlier, but are we
> certain
> > that "same trust anchor" is a strong enough check that the CRL
signer is
> > the one expected by the issuing CA?  While I was not in San Diego
when
> > this wording was included in the 3280 series, I do not really think
that
> > that check is strong enough.  I would suggest instead that the CRL
> > signer's certificate needs to be directly issued by one of the CA's
in
> the
> > certification path back to the trust anchor used for the
certificate's
> > verification, or by that anchor itself, unless people have practical
> > experience with CA structures which that rule would prohibit.
Forcing
> the
> > CRL to be issued by the CA itself (as I understand Denis to have
> > suggested) prohibits the reasonable case where the CRL is issued by
a
> > hierarchical superior, so it is IMHO too strict.
> >         I am personally not sure, FWIW, that a CRL should be
permitted
> to
> > be signed by a second-cousin certificate of the issuer's
certificate.
> By
> > analogy to the use of the terms in families, "sibling" certificates
> would
> > have the same issuer, "first-cousin" certificates would be issued by
> > siblings, and "second-cousin" certificates would be issued by first
> > cousins - so they are both three levels down from the same trust
anchor,
> > or from the last common CA in their paths.  This issue is not newly
> caused
> > by CRL AIA, since the same issue can arise with CRL's containing
only
> > AKID.  AIA only allows RP's to build a path (whether right or wrong)
> more
> > quickly.
> >         In any case, nothing more than a note in Security
Considerations
> > is appropriate in any of our RFC's other than 3280 and its
successor.
> >
> >         Tom Gindin
> > P.S. -  The above views are mine, and not necessarily those of my
> employer
> >
> >
> >
> >
> >
> > Tim Polk <[email-masked]>
> > Sent by: [email-masked]
> > 05/10/2005 05:27 PM
> >
> >         To:     [email-masked]
> >         cc:     [email-masked], [email-masked],
> [email-masked]
> >         Subject:        WG Last Call: AIA CRL extension
> >
> >
> >
> >
> > This message initiates working group Last Call for the specification
> > "Internet X.509 Public Key Infrastructure: Authority Information
Access
> > CRL
> > Extension".  While some issues raised in the working group are
> unresolved,
> >
> > the editors believe that rough consensus supports the current
> > specification.
> >
> > The URL for this Internet-Draft is:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> >
> > Last Call will run for (at least) two weeks. That is, Last Call will
not
> > close before May 24.
> > Thanks,
> > Tim Polk

Date: Tue, 24 May 2005 19:51:38 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: AIA CRL extension
Sender: [email-masked]

Julien Stern wrote:

>Note that the CRL could be directly inserted into a "long term"
>signature (according to RFC3126 for example). This does not require
>a repository break-in and makes the "attack" even more realistic.
>  
>
Or in a CMS messages, together with the certificates that validate it. 
The problem is not restricted to the AIA.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Trying to relate PKCS & IETF standards to encoding rules
Date: Wed, 25 May 2005 05:03:15 +1200
Sender: [email-masked]

Sam Roberts <[email-masked]> writes:

>Maybe an informational I-D would be useful to help bring some consistency to
>the practice.

Given the deployed base, I doubt it'd make much difference to existing
implementations.  What you could do though is document current practice to
help others who're coming along and want to implement something that
interoperates.

Peter.

Content-class: urn:content-classes:message
Subject: FW: Required binding method - Was RE: PKINIT-26 changes: identifying the kdc certificates
Date: Tue, 24 May 2005 17:40:24 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Forwarding this also to the pkix WG for those who don't follow the
Kerberos list.

/Stefan

-----Original Message-----
From: Stefan Santesson 
Sent: den 24 maj 2005 09:37
To: 'Sam Hartman'
Cc: Nicolas Williams; Liqiang(Larry) Zhu; [email-masked]
Subject: RE: Required binding method - Was RE: PKINIT-26 changes:
identifying the kdc certificates

Sam,

Reading your reply actually makes me think that we are in agreement.

I agree that it is impossible to bind to a SRV record unless a symbolic
name has been defined and the security considerations assigned to that
definition should always be followed.

However, I can't see that you need to do more than that.
Once the symbolic name has been defined and it is used according to it's
definition and security considerations to discover services, then I
can't se any negative security effects from binding that SRV RR name to
a public key certificate to enable authentication of the host's
authorization to deliver that service.

In summary I don't think it is reasonable for a standard defining an
otherName for a SRV RR to explicitly define what services it can be used
with. But I would agree to describe the principles in the security
considerations.

/Stefan

> From: Sam Hartman [mailto:[email-masked]]
> Sent: den 23 maj 2005 20:03
> To: Stefan Santesson
> Cc: Nicolas Williams; Liqiang(Larry) Zhu; [email-masked]
> Subject: Re: Required binding method - Was RE: PKINIT-26 changes:
> identifying the kdc certificates
> 
> >>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:
> 
>     Stefan> Sam,
> 
>     >> I hope the PKIX working group does not approve a version of the
>     >> SRV OtherName that would allow it to be used with an
>     >> application without some standard enabling such usage.  So I
>     >> would expect some document to explicitly mention that it can be
>     >> used with pkinit.  But I agree that if PKIX were to approve an
>     >> overly broad standard, the current text would allow it to be
>     >> used.
>     >>
>     >>
> 
>     Stefan> [Stefan] I don't think you can constrain its usage in a
>     Stefan> PKIX RFC or force some RFC to enable it for each service
>     Stefan> type.
> 
>     Stefan> RFC 2782 already makes it possible to bind to a service
>     Stefan> only based on service name, protocol and domain. There are
>     Stefan> no limitations to that.
> 
> 
> Please See the following text  from RFC 2782:
> 
> 
>   Applicability Statement
> 
>      In general, it is expected that SRV records will be used by
clients
>         for applications where the relevant protocol specification
> indicates
>            that clients should use the SRV record. Such specification
MUST
>               define the symbolic name to be used in the Service field
of
> the SRV
>                  record as described below. It also MUST include
security
>                     considerations. Service SRV records SHOULD NOT be
used
> in the absence
>                        of such specification.
> 
> 
> 
> So your proposal clearly should not be used for applications that do
> not use SRV records in the first place.  Some applications that use
> SRV records (most of the IMPP protocols fall into this examlpe)
> already specify how certificates should be bound to these
> applications.  It is undesirable to have two methods of doing the same
> certificate binding without compelling reason to do so.Failing this
> would lead to decreased interoperability.  From this I conclude that
> your name type should only be used when explicitly specified.  Things
> are of course more fuzzy for applications that do not have formal
> published specifications.

From: "Julien Stern" <[email-masked]>
Date: Tue, 24 May 2005 18:38:58 +0200
To: Tom Gindin <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: AIA CRL extension
Mail-Followup-To: Julien Stern <[email-masked]>, Tom Gindin <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote:
> 
>         There is one scenario permitted by the "same trust anchor" rule 
> for CRL signers which seems to me to be a serious security hole.  Let us 
> assume a valid CA which is a direct subordinate of one of the RP's trust 
> anchors.  This CA issues separate CRL's and ARL's, in a quite usual way, 
> and issues cross certificates.  After months or years of operation, it 
> revokes one of its cross certificates because the subject's operator has 
> gone rogue.  That rogue subject then issues a fraudulent CRL Signing 
> certificate with the DN that the superior certificate has been using to 
> sign ARL's, a public key which it has newly generated, and various 
> extensions including an SKID.  It then issues an updated copy of an old 
> ARL under the fraudulent CRL signer's certificate and with an AKID 
> matching the fraudulent signer's SKID.  If the rogue can break into the 
> repository where the CRL is expected, this fraudulently issued CRL will 
> probably be validated whether it contains an AIA or not.  It will 
> certainly pass the "same trust anchor" condition.
>         This scenario, in which a rogue CA issues an ARL certifiying that 
> its primary certificate has not been revoked and gets the ARL accepted, is 
> possible under "same trust anchor" but not under "signed by path member".

I agree with the validity of this scenario. I believe this is very
close to the issue I attempted to bring on the list a short time ago.
Of course, it assumes the existence of a rogue CA at some point in time.

Note that the CRL could be directly inserted into a "long term"
signature (according to RFC3126 for example). This does not require
a repository break-in and makes the "attack" even more realistic.

Regards.

--
Julien Stern

> 
>                 Tom Gindin
> 
> ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM -----
> 
> 
> Tom Gindin
> 05/23/2005 10:46 PM
> 
>         To:     [email-masked]
>         cc:     [email-masked], [email-masked], [email-masked], 
> [email-masked]
>         From:   Tom Gindin/Watson/IBM@IBMUS
>         Subject:        Re: WG Last Call: AIA CRL extension
> 
>         Tim:
> 
>         I should probably have brought this up earlier, but are we certain 
> that "same trust anchor" is a strong enough check that the CRL signer is 
> the one expected by the issuing CA?  While I was not in San Diego when 
> this wording was included in the 3280 series, I do not really think that 
> that check is strong enough.  I would suggest instead that the CRL 
> signer's certificate needs to be directly issued by one of the CA's in the 
> certification path back to the trust anchor used for the certificate's 
> verification, or by that anchor itself, unless people have practical 
> experience with CA structures which that rule would prohibit.  Forcing the 
> CRL to be issued by the CA itself (as I understand Denis to have 
> suggested) prohibits the reasonable case where the CRL is issued by a 
> hierarchical superior, so it is IMHO too strict.
>         I am personally not sure, FWIW, that a CRL should be permitted to 
> be signed by a second-cousin certificate of the issuer's certificate.  By 
> analogy to the use of the terms in families, "sibling" certificates would 
> have the same issuer, "first-cousin" certificates would be issued by 
> siblings, and "second-cousin" certificates would be issued by first 
> cousins - so they are both three levels down from the same trust anchor, 
> or from the last common CA in their paths.  This issue is not newly caused 
> by CRL AIA, since the same issue can arise with CRL's containing only 
> AKID.  AIA only allows RP's to build a path (whether right or wrong) more 
> quickly.
>         In any case, nothing more than a note in Security Considerations 
> is appropriate in any of our RFC's other than 3280 and its successor.
> 
>         Tom Gindin
> P.S. -  The above views are mine, and not necessarily those of my employer
> 
> 
> 
> 
> 
> Tim Polk <[email-masked]>
> Sent by: [email-masked]
> 05/10/2005 05:27 PM
>  
>         To:     [email-masked]
>         cc:     [email-masked], [email-masked], [email-masked]
>         Subject:        WG Last Call: AIA CRL extension
> 
> 
> 
> 
> This message initiates working group Last Call for the specification 
> "Internet X.509 Public Key Infrastructure: Authority Information Access 
> CRL 
> Extension".  While some issues raised in the working group are unresolved, 
> 
> the editors believe that rough consensus supports the current 
> specification.
> 
> The URL for this Internet-Draft is:
>                  
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> 
> Last Call will run for (at least) two weeks. That is, Last Call will not 
> close before May 24.
> 
> Thanks,
> 
> Tim Polk 
> 
> 
> 

Date: Tue, 24 May 2005 12:13:10 -0400
From: Sam Roberts <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Trying to relate PKCS & IETF standards to encoding rules
Mail-Followup-To: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Wrote Goulet Walter-CWG009 <[email-masked]>, on Tue, May 24, 2005 at 09:57:13AM -0500:
> Is there a set of RFCs that describes these standards? Maybe there is
> a standard describing in general how to encode from DER -> PEM and
> describes how the headers/footers are built.

Not that I'm aware of, the names to use in the PEM headers are
"customary", you have to see whats out there (and there is a fair amount
of variation), and do what others do.

Maybe an informational I-D would be useful to help bring some
consistency to the practice.

Cheers,
Sam

-- 
http://www.certicom.com

Date: Tue, 24 May 2005 17:56:58 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Tom Gindin <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: AIA CRL extension
Sender: [email-masked]

Tom,

Thank you for bringing water to my mill. :-)

To respond to your previous e-mail, you said:

"Forcing the CRL to be issued by the CA itself (as I understand
Denis to have suggested) prohibits the reasonable case where the CRL is 
issued by a hierarchical superior, so it is IMHO too strict".

I am saying that this case is secure.

Expending it to the certification tree, would need to demonstrate that it is 
secure, ... and this has not be yet done at the moment (in particular for 
the case of same DN for the CRL issuer name).

Denis

> There is one scenario permitted by the "same trust anchor" rule 
> for CRL signers which seems to me to be a serious security hole.  Let us 
> assume a valid CA which is a direct subordinate of one of the RP's trust 
> anchors.  This CA issues separate CRL's and ARL's, in a quite usual way, 
> and issues cross certificates.  After months or years of operation, it 
> revokes one of its cross certificates because the subject's operator has 
> gone rogue.  That rogue subject then issues a fraudulent CRL Signing 
> certificate with the DN that the superior certificate has been using to 
> sign ARL's, a public key which it has newly generated, and various 
> extensions including an SKID.  It then issues an updated copy of an old 
> ARL under the fraudulent CRL signer's certificate and with an AKID 
> matching the fraudulent signer's SKID.  If the rogue can break into the 
> repository where the CRL is expected, this fraudulently issued CRL will 
> probably be validated whether it contains an AIA or not.  It will 
> certainly pass the "same trust anchor" condition.
>         This scenario, in which a rogue CA issues an ARL certifiying that 
> its primary certificate has not been revoked and gets the ARL accepted, is 
> possible under "same trust anchor" but not under "signed by path member".
> 
>                 Tom Gindin
> 
> ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM -----
> 
> 
> Tom Gindin
> 05/23/2005 10:46 PM
> 
>         To:     [email-masked]
>         cc:     [email-masked], [email-masked], [email-masked], 
> [email-masked]
>         From:   Tom Gindin/Watson/IBM@IBMUS
>         Subject:        Re: WG Last Call: AIA CRL extension
> 
>         Tim:
> 
>         I should probably have brought this up earlier, but are we certain 
> that "same trust anchor" is a strong enough check that the CRL signer is 
> the one expected by the issuing CA?  While I was not in San Diego when 
> this wording was included in the 3280 series, I do not really think that 
> that check is strong enough.  I would suggest instead that the CRL 
> signer's certificate needs to be directly issued by one of the CA's in the 
> certification path back to the trust anchor used for the certificate's 
> verification, or by that anchor itself, unless people have practical 
> experience with CA structures which that rule would prohibit.  Forcing the 
> CRL to be issued by the CA itself (as I understand Denis to have 
> suggested) prohibits the reasonable case where the CRL is issued by a 
> hierarchical superior, so it is IMHO too strict.
>         I am personally not sure, FWIW, that a CRL should be permitted to 
> be signed by a second-cousin certificate of the issuer's certificate.  By 
> analogy to the use of the terms in families, "sibling" certificates would 
> have the same issuer, "first-cousin" certificates would be issued by 
> siblings, and "second-cousin" certificates would be issued by first 
> cousins - so they are both three levels down from the same trust anchor, 
> or from the last common CA in their paths.  This issue is not newly caused 
> by CRL AIA, since the same issue can arise with CRL's containing only 
> AKID.  AIA only allows RP's to build a path (whether right or wrong) more 
> quickly.
>         In any case, nothing more than a note in Security Considerations 
> is appropriate in any of our RFC's other than 3280 and its successor.
> 
>         Tom Gindin
> P.S. -  The above views are mine, and not necessarily those of my employer
> 
> 
> 
> 
> 
> Tim Polk <[email-masked]>
> Sent by: [email-masked]
> 05/10/2005 05:27 PM
>  
>         To:     [email-masked]
>         cc:     [email-masked], [email-masked], [email-masked]
>         Subject:        WG Last Call: AIA CRL extension
> 
> 
> 
> 
> This message initiates working group Last Call for the specification 
> "Internet X.509 Public Key Infrastructure: Authority Information Access 
> CRL 
> Extension".  While some issues raised in the working group are unresolved, 
> 
> the editors believe that rough consensus supports the current 
> specification.
> 
> The URL for this Internet-Draft is:
>                  
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt
> 
> Last Call will run for (at least) two weeks. That is, Last Call will not 
> close before May 24.
> 
> Thanks,
> 
> Tim Polk 
> 
> 
> 
> 
> 

Date: Tue, 24 May 2005 11:35:27 -0400
To: Goulet Walter-CWG009 <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Trying to relate PKCS & IETF standards to encoding rules
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Walter,

The ITU-T X.509 and the IETF PKIX specs call for binary encoding of 
the ASN.1 for certs and CRLs, specifically DER, as you noted.

PEM, which is now historical, also called for binary encoding  (DER) 
of the ASN.1, and then specified the base64 encoding of the binary 
representation for "safe" carriage over SMTP.

So the two sets of specs were not in conflict. It's just that PEM 
specified an additional layer of encoding for content transfer 
purposes, which is what MIME does as well, when necessary.

DER to base64 is an easy encoding, because base64 takes any binary 
sytring and says how to encode it as text.

Steve

Date: Tue, 24 May 2005 11:35:10 -0400
To: Sam Hartman <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: AD Review for draft-ietf-pkix-rfc3770bis
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Sam:

Thanks for the AD review.  It has improved the document.

Here is how I addressed each of your comments.  I have CCed the PKIX mail 
list to stan any WG member can raise the alarm if they do not like the way 
that any comment was resolved.

>The document sites RFC 2284, not RFC 3748 which supersedes 2284.  In
>addition the document's terminology is inconsistent with RFC 3748.
>EAP defines an exchange between a peer and an EAP server.  The term
>client is not typically used.  My preference is that you fix the
>terminology but this is not a requirement.    The reference does need to 
>be updated.  Also, I wonder whether it should be normative.

[EAP] changed to normative, and it references RFC 3748.

The terminology was updated to use "supplicant" when talking about 802.1X 
and "peer" when talking about EAP.  The term "EAP server" is also used.

>section 1:
>There are two places in an EAP protocol where it seems obvious you
>might want to use a certificate: the peer might want a certificate to
>prove its identity to the EAP server and a EAP server might want a
>certificate to prove its identity to the peer.  This document deals
>with the first case but does not make that clear.
>The following change helps.
>
>s/for/by/
>old:
>    Automated selection of certificates for PPP and IEEE 802.1X clients
>       is highly desirable.  By using certificate extensions to identify the
>new:
>    Automated selection of certificates by  PPP and IEEE 802.1X clients
>       is highly desirable.  By using certificate extensions to identify the

The "client" in this sentence causes problems with your earlier comment.
How about: "Automated selection of client certificates for use with PPP
and IEEE 802.1X is highly desirable."

>I'd like to see  text like the following worked into section 1
>though to make things completely clear.
>
>  This document defines key usage values and certificate extensions to
>  be used in certificates issued to clients of PPP and wireless
>  networks.

How about a new paragraph at the end of section 1:
"This document defines extended key usage values and a WLAN-specific
certificate extension for use in certificates issued to clients of
PPP and WLANs."

>section 2:
>
>Do these key purpose IDs apply to EAP server certificates or to client
>certificates or to both?

The intent was peer certificates.  I do not recall any discussion of EAP 
server certificates using them.

Proposed revision:
"Inclusion of the EAP over PPP value indicates that the certified public
key is appropriate for use by a peer with EAP in the PPP environment.  The
inclusion of the EAPOL value indicates that the certified public key is
appropriate for use by a peer with the EAP in the LAN environment.
Inclusion of both values indicates that the certified public key is
appropriate for use by a peer in either of the environments."

>The text quotes the description of extend key usages from RFC 3280 and
>points out that an application can require extended key usage and a
>particular KeyPurposeId.  Is the intent for this to be defined by the
>EAP method, the EAP method implementation, site policy, or something
>else?  How should implementers handle the situation where the EAP
>implementation does not know what environment it is being used in?
>(I'm not sure whether this situation is actually common.)

I do not think there is a problem here.  EAP methods that use certificates 
can require the presence of a particular KeyPurposeId, but I do not think 
that any have done so.

>The extended key usage should presumably be checked both by the EAP peer 
>and the EAP server.  The text should probably make this more clear.

I see it more as a selection criteria when more than one certificate is 
available.

>Section 3:
>
>The following text seems to be trying to imply that the ssid extension
>can only be used with the extended key usage extension.  If that's
>true the requirement needs to be stated more clearly.  However I don't
>understand why you would want that requirement--it seems reasonable to
>use the ssid extension with an application (EAP method) that does not
>require extended key usage.
>
>  When more than one certificate includes an extended key usage
>     extension indicating that the certified public key is appropriate for
>        use with the EAP in the LAN environment, then the list of SSIDs MAY
>           be used to select the correct certificate for authentication in a
>              particular WLAN.

It is not a requirement.  It is trying to say that the KeyPurposeId could 
narrow the certificate selection, and then this extension could provide 
further assistance.  It is perfectly fine for only one of the extensions to 
be used.

I suggest replacing the first paragraph of setcion 3 with:

The Wireless LAN (WLAN) System Service identifiers (SSIDs) public key
certificate extension is always non-critical.  It contains a list of
SSIDs.  The list of SSIDs MAY be used to select the correct certificate
for authentication in a particular WLAN.

If the extended key usage extension appears in the same certificate as
the SSID extension, then the extended key usage extension MUST
indicate that the certified public key is appropriate for use with the EAP
in the LAN environment by including the id-kp-eapOverLAN KeyPurposeId value.

-- Russ

From: Goulet Walter-CWG009 <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Trying to relate PKCS & IETF standards to encoding rules
Date: Tue, 24 May 2005 09:57:13 -0500
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.

------_=_NextPart_001_01C56070.C8FDA77C
Content-Type: text/plain

Hi,

I'm trying to grasp how certificates and associated artifacts of PKI
(private keys, CRLs, CSRs etc) are encoded and how the standards are
related to eachother.

My understanding of the relationships is:

Standards for x.509 (spec. in RFC3280 and ITU-T x.509) as well as the
various PKCS standards developed primarily by RSA labs are specified
as ASN.1.

ASN.1 cannot be directly encoded since it consists of abstract types,
so the standards specify DER (which is a more restrictive BER
encoding; basically it's a binary representation of ASN.1 values).

PEM (defined in RFC 1421 - 1424, but what I care about is in 1421)
defines a way to encode binary cryptographically sensitive data so it
can be transported in text over SMTP.

However, I haven't seen standards, notably for x.509 itself, that
describe how to encode data from DER -> PEM.

I suspect there must be a standard since for x.509 files there is a
standard 'BEGIN CERTIFICATE/END CERTIFICATE' header and footer for
certificates (and similarly, private keys and CSRs).

Is there a set of RFCs that describes these standards? Maybe there is
a standard describing in general how to encode from DER -> PEM and
describes how the headers/footers are built.

Any help would be appreciated.

Thanks,
-
Walter Goulet
[email-masked] Nextel: (847)366-9519 Pvt. ID 9519
Desk: (847)576-7036

------_=_NextPart_001_01C56070.C8FDA77C
Content-Type: text/html
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C56070.C8FDA77C--

To: [email-masked]
Subject: Re: WG Last Call: AIA CRL extension
From: Tom Gindin <[email-masked]>
Date: Tue, 24 May 2005 10:36:16 -0400
Sender: [email-masked]

        There is one scenario permitted by the "same trust anchor" rule 
for CRL signers which seems to me to be a serious security hole.  Let us 
assume a valid CA which is a direct subordinate of one of the RP's trust 
anchors.  This CA issues separate CRL's and ARL's, in a quite usual way, 
and issues cross certificates.  After months or years of operation, it 
revokes one of its cross certificates because the subject's operator has 
gone rogue.  That rogue subject then issues a fraudulent CRL Signing 
certificate with the DN that the superior certificate has been using to 
sign ARL's, a public key which it has newly generated, and various 
extensions including an SKID.  It then issues an updated copy of an old 
ARL under the fraudulent CRL signer's certificate and with an AKID 
matching the fraudulent signer's SKID.  If the rogue can break into the 
repository where the CRL is expected, this fraudulently issued CRL will 
probably be validated whether it contains an AIA or not.  It will 
certainly pass the "same trust anchor" condition.
        This scenario, in which a rogue CA issues an ARL certifiying that 
its primary certificate has not been revoked and gets the ARL accepted, is 
possible under "same trust anchor" but not under "signed by path member".

                Tom Gindin

----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM -----

Tom Gindin
05/23/2005 10:46 PM

        To:     [email-masked]
        cc:     [email-masked], [email-masked], [email-masked], 
[email-masked]
        From:   Tom Gindin/Watson/IBM@IBMUS
        Subject:        Re: WG Last Call: AIA CRL extension

        Tim:

        I should probably have brought this up earlier, but are we certain 
that "same trust anchor" is a strong enough check that the CRL signer is 
the one expected by the issuing CA?  While I was not in San Diego when 
this wording was included in the 3280 series, I do not really think that 
that check is strong enough.  I would suggest instead that the CRL 
signer's certificate needs to be directly issued by one of the CA's in the 
certification path back to the trust anchor used for the certificate's 
verification, or by that anchor itself, unless people have practical 
experience with CA structures which that rule would prohibit.  Forcing the 
CRL to be issued by the CA itself (as I understand Denis to have 
suggested) prohibits the reasonable case where the CRL is issued by a 
hierarchical superior, so it is IMHO too strict.
        I am personally not sure, FWIW, that a CRL should be permitted to 
be signed by a second-cousin certificate of the issuer's certificate.  By 
analogy to the use of the terms in families, "sibling" certificates would 
have the same issuer, "first-cousin" certificates would be issued by 
siblings, and "second-cousin" certificates would be issued by first 
cousins - so they are both three levels down from the same trust anchor, 
or from the last common CA in their paths.  This issue is not newly caused 
by CRL AIA, since the same issue can arise with CRL's containing only 
AKID.  AIA only allows RP's to build a path (whether right or wrong) more 
quickly.
        In any case, nothing more than a note in Security Considerations 
is appropriate in any of our RFC's other than 3280 and its successor.

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

Tim Polk <[email-masked]>
Sent by: [email-masked]
05/10/2005 05:27 PM
 
        To:     [email-masked]
        cc:     [email-masked], [email-masked], [email-masked]
        Subject:        WG Last Call: AIA CRL extension

This message initiates working group Last Call for the specification 
"Internet X.509 Public Key Infrastructure: Authority Information Access 
CRL 
Extension".  While some issues raised in the working group are unresolved, 

the editors believe that rough consensus supports the current 
specification.

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

Last Call will run for (at least) two weeks. That is, Last Call will not 
close before May 24.

Thanks,

Tim Polk 

Content-class: urn:content-classes:message
Subject: RE: Request for new work item - Defining an SRV RR otherName
Date: Tue, 24 May 2005 04:59:54 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Tom Gindin" <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Yes,

The intention was actually primary to include the lookup key.

Yes there are some clarifications needed in this aspect but I waited
with trying to formulate the limitations until we have got a bit further
towards accepting the work item.

Thanks for noticing the issue.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: Tom Gindin [mailto:[email-masked]]
> Sent: den 23 maj 2005 20:11
> To: Stefan Santesson
> Cc: Sam Hartman; [email-masked]
> Subject: RE: Request for new work item - Defining an SRV RR otherName
> 
>         Stefan:
> 
>         Maybe I'm being a bit thick here, but do you really intend to
> include the entire RR contents, including the weight, target and port,
in
> this otherName?  Or do you intend to include only the lookup key
> (_service._protocol.DNSName) instead?  Some of your wording makes IMHO
> more sense in that case, and the assertion you're conveying is "the CA
> issuer has authorized this entity to provide this service for this
> domain".
>         Whatever may be the case for Kerberos, I don't see why this
> feature is problematic for (say) LDAP, except insofar as it's an
argument
> for name constraints.  I do think that you'd need to state that the
use of
> this field in a certificate is governed by DNSName name constraints.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> "Stefan Santesson" <[email-masked]>
> Sent by: [email-masked]
> 05/20/2005 06:44 PM
> 
>         To:     "Sam Hartman" <[email-masked]>,
<[email-masked]>
>         cc:
>         Subject:        RE: Request for new work item - Defining an
SRV RR
> otherName

> Sam,
> 
> My recollection of this issue is a bit different from yours.
> 
> The central need here is to enable the KDC to express in a certificate
> the fact that it is a KDC in a way that male sense to clients.
> 
> In a traditional Kerberos environment the KDC can be known as a KDC
> since it can demonstrate knowledge of the user's key.
> 
> In PKI initiated Kerberos, this property is lost.
> 
> If the client knows the host name, IP address or any other identity of
> the KDC, which can be mapped to information in the KDC certificate,
then
> we are good and appropriate binding is possible.
> 
> However, from what I have learned, we may face situations where a
client
> only know the name of the domain it wants to access and the fact that
it
> looks for a PKINIT enabled KDC. In this case it is assumed that the
> client would do a SRV RR query to the DNS to get the host name of the
> currently available KDC.
> 
> If the SRV RR is NOT the appropriate name to bind to in this case,
then
> my question is what the alternative is.
> 
> 
> Finally, the reason to do this in PKIX is since this in principle is a
> generic way of service discovery that may be useful also for other
> services where the client only know service name, protocol and domain.
I
> have indications that it is becoming more and more interesting to
> dynamically search for services in this manner for other services but
> I'm very interested of other opinions here.
> 
> I don't however understand in what way we need to be careful to limit
> this only to some specific services. Could you clarify this concern?
> 
> /Stefan
> 
> 
> > On Behalf Of Sam Hartman
> > Sent: den 20 maj 2005 12:39
> > To: [email-masked]
> > Subject: Re: Request for new work item - Defining an SRV RR
otherName
> >
> >
> >
> >
> > Hi.  I'm speaking as an individual not as an AD.
> >
> > This proposal was originally introduced as a use of dnsname in the
> > Kerberos working group for pkinit.
> >
> > The authors of the proposal would like to name services as they are
> > identified by users.  For example a user types foo.bar.example.com
> > into some program.  The program looks up a SRV record for some
service
> > and then connects to that service.  If insecure DNS is used then the
> > dns lookup should not be part of the name against which a
certificate
> > is checkde.
> >
> > We're seeing a similar situation in the kitten working group ; see
> > draft-ietf-kitten-gssapi-domain-based-names-00.txt.
> >
> >
> > The idea of this proposal is that the certificate contain the name
> > that the client system would look up in the same form as the client
> > uses to look in DNS.
> >
> > I'm not sure how this proposal has evolved since it was first
> > presented to me.  Originally the goal was so that application
> > libraries could use some sort of automatic mechanism to:
> >
> > * Look up SRV records
> >
> > * Bind to TLS certificates
> >
> > * Find the Kerberos principal name
> >
> > * Bind to pkinit certificates.
> >
> > All the application author would do would be to pass the service
> > protocol and name into some magic function.
> >
> > That bothers me.  There is no guarantee that the SRV record tag will
> > match the GSS/Kerberos principal name.  There is no guarantee that
the
> > service in question doesn't have some better choice for certificate
> > binding like one of the IMPP-specific solutions.
> >
> >
> > I'm also not quite sure that SRV tags are real/really the right
thing
> > to be binding to.
> >
> > If the PKIX working group does adopt this proposal I would recommend
> > being very careful.  Make sure to scope it only to be used for
> > applications/services where it is appropriate.  Make sure to discuss
> > applications that already have a mechanism for binding their
> > certificates.
> >
> > It might also be important to find out if there is actually a use
case
> > for this name type before standardizing it.  There wasn't really
that
> > much support in krb-wg for the earlier version of this.
> >
> > --Sam
> 
> 
> 

To: "Stefan Santesson" <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>, [email-masked]
Subject: RE: Request for new work item - Defining an SRV RR otherName
From: Tom Gindin <[email-masked]>
Date: Mon, 23 May 2005 23:10:38 -0400
Sender: [email-masked]

        Stefan:

        Maybe I'm being a bit thick here, but do you really intend to 
include the entire RR contents, including the weight, target and port, in 
this otherName?  Or do you intend to include only the lookup key 
(_service._protocol.DNSName) instead?  Some of your wording makes IMHO 
more sense in that case, and the assertion you're conveying is "the CA 
issuer has authorized this entity to provide this service for this 
domain".
        Whatever may be the case for Kerberos, I don't see why this 
feature is problematic for (say) LDAP, except insofar as it's an argument 
for name constraints.  I do think that you'd need to state that the use of 
this field in a certificate is governed by DNSName name constraints.

                Tom Gindin

"Stefan Santesson" <[email-masked]>
Sent by: [email-masked]
05/20/2005 06:44 PM
 
        To:     "Sam Hartman" <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: Request for new work item - Defining an SRV RR 
otherName

Sam,

My recollection of this issue is a bit different from yours.

The central need here is to enable the KDC to express in a certificate
the fact that it is a KDC in a way that male sense to clients.

In a traditional Kerberos environment the KDC can be known as a KDC
since it can demonstrate knowledge of the user's key.

In PKI initiated Kerberos, this property is lost.

If the client knows the host name, IP address or any other identity of
the KDC, which can be mapped to information in the KDC certificate, then
we are good and appropriate binding is possible.

However, from what I have learned, we may face situations where a client
only know the name of the domain it wants to access and the fact that it
looks for a PKINIT enabled KDC. In this case it is assumed that the
client would do a SRV RR query to the DNS to get the host name of the
currently available KDC.

If the SRV RR is NOT the appropriate name to bind to in this case, then
my question is what the alternative is.

Finally, the reason to do this in PKIX is since this in principle is a
generic way of service discovery that may be useful also for other
services where the client only know service name, protocol and domain. I
have indications that it is becoming more and more interesting to
dynamically search for services in this manner for other services but
I'm very interested of other opinions here.

I don't however understand in what way we need to be careful to limit
this only to some specific services. Could you clarify this concern? 

/Stefan

> On Behalf Of Sam Hartman
> Sent: den 20 maj 2005 12:39
> To: [email-masked]
> Subject: Re: Request for new work item - Defining an SRV RR otherName
> 
> 
> 
> 
> Hi.  I'm speaking as an individual not as an AD.
> 
> This proposal was originally introduced as a use of dnsname in the
> Kerberos working group for pkinit.
> 
> The authors of the proposal would like to name services as they are
> identified by users.  For example a user types foo.bar.example.com
> into some program.  The program looks up a SRV record for some service
> and then connects to that service.  If insecure DNS is used then the
> dns lookup should not be part of the name against which a certificate
> is checkde.
> 
> We're seeing a similar situation in the kitten working group ; see
> draft-ietf-kitten-gssapi-domain-based-names-00.txt.
> 
> 
> The idea of this proposal is that the certificate contain the name
> that the client system would look up in the same form as the client
> uses to look in DNS.
> 
> I'm not sure how this proposal has evolved since it was first
> presented to me.  Originally the goal was so that application
> libraries could use some sort of automatic mechanism to:
> 
> * Look up SRV records
> 
> * Bind to TLS certificates
> 
> * Find the Kerberos principal name
> 
> * Bind to pkinit certificates.
> 
> All the application author would do would be to pass the service
> protocol and name into some magic function.
> 
> That bothers me.  There is no guarantee that the SRV record tag will
> match the GSS/Kerberos principal name.  There is no guarantee that the
> service in question doesn't have some better choice for certificate
> binding like one of the IMPP-specific solutions.
> 
> 
> I'm also not quite sure that SRV tags are real/really the right thing
> to be binding to.
> 
> If the PKIX working group does adopt this proposal I would recommend
> being very careful.  Make sure to scope it only to be used for
> applications/services where it is appropriate.  Make sure to discuss
> applications that already have a mechanism for binding their
> certificates.
> 
> It might also be important to find out if there is actually a use case
> for this name type before standardizing it.  There wasn't really that
> much support in krb-wg for the earlier version of this.
> 
> --Sam

To: "Stefan Santesson" <[email-masked]>
Cc: "Sam Hartman" <[email-masked]>, [email-masked]
Subject: RE: Request for new work item - Defining an SRV RR otherName
From: Tom Gindin <[email-masked]>
Date: Mon, 23 May 2005 23:10:38 -0400
Sender: [email-masked]

        Stefan:

        Maybe I'm being a bit thick here, but do you really intend to 
include the entire RR contents, including the weight, target and port, in 
this otherName?  Or do you intend to include only the lookup key 
(_service._protocol.DNSName) instead?  Some of your wording makes IMHO 
more sense in that case, and the assertion you're conveying is "the CA 
issuer has authorized this entity to provide this service for this 
domain".
        Whatever may be the case for Kerberos, I don't see why this 
feature is problematic for (say) LDAP, except insofar as it's an argument 
for name constraints.  I do think that you'd need to state that the use of 
this field in a certificate is governed by DNSName name constraints.

                Tom Gindin

"Stefan Santesson" <[email-masked]>
Sent by: [email-masked]
05/20/2005 06:44 PM
 
        To:     "Sam Hartman" <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: Request for new work item - Defining an SRV RR 
otherName

Sam,

My recollection of this issue is a bit different from yours.

The central need here is to enable the KDC to express in a certificate
the fact that it is a KDC in a way that male sense to clients.

In a traditional Kerberos environment the KDC can be known as a KDC
since it can demonstrate knowledge of the user's key.

In PKI initiated Kerberos, this property is lost.

If the client knows the host name, IP address or any other identity of
the KDC, which can be mapped to information in the KDC certificate, then
we are good and appropriate binding is possible.

However, from what I have learned, we may face situations where a client
only know the name of the domain it wants to access and the fact that it
looks for a PKINIT enabled KDC. In this case it is assumed that the
client would do a SRV RR query to the DNS to get the host name of the
currently available KDC.

If the SRV RR is NOT the appropriate name to bind to in this case, then
my question is what the alternative is.

Finally, the reason to do this in PKIX is since this in principle is a
generic way of service discovery that may be useful also for other
services where the client only know service name, protocol and domain. I
have indications that it is becoming more and more interesting to
dynamically search for services in this manner for other services but
I'm very interested of other opinions here.

I don't however understand in what way we need to be careful to limit
this only to some specific services. Could you clarify this concern? 

/Stefan

> On Behalf Of Sam Hartman
> Sent: den 20 maj 2005 12:39
> To: [email-masked]
> Subject: Re: Request for new work item - Defining an SRV RR otherName
> 
> 
> 
> 
> Hi.  I'm speaking as an individual not as an AD.
> 
> This proposal was originally introduced as a use of dnsname in the
> Kerberos working group for pkinit.
> 
> The authors of the proposal would like to name services as they are
> identified by users.  For example a user types foo.bar.example.com
> into some program.  The program looks up a SRV record for some service
> and then connects to that service.  If insecure DNS is used then the
> dns lookup should not be part of the name against which a certificate
> is checkde.
> 
> We're seeing a similar situation in the kitten working group ; see
> draft-ietf-kitten-gssapi-domain-based-names-00.txt.
> 
> 
> The idea of this proposal is that the certificate contain the name
> that the client system would look up in the same form as the client
> uses to look in DNS.
> 
> I'm not sure how this proposal has evolved since it was first
> presented to me.  Originally the goal was so that application
> libraries could use some sort of automatic mechanism to:
> 
> * Look up SRV records
> 
> * Bind to TLS certificates
> 
> * Find the Kerberos principal name
> 
> * Bind to pkinit certificates.
> 
> All the application author would do would be to pass the service
> protocol and name into some magic function.
> 
> That bothers me.  There is no guarantee that the SRV record tag will
> match the GSS/Kerberos principal name.  There is no guarantee that the
> service in question doesn't have some better choice for certificate
> binding like one of the IMPP-specific solutions.
> 
> 
> I'm also not quite sure that SRV tags are real/really the right thing
> to be binding to.
> 
> If the PKIX working group does adopt this proposal I would recommend
> being very careful.  Make sure to scope it only to be used for
> applications/services where it is appropriate.  Make sure to discuss
> applications that already have a mechanism for binding their
> certificates.
> 
> It might also be important to find out if there is actually a use case
> for this name type before standardizing it.  There wasn't really that
> much support in krb-wg for the earlier version of this.
> 
> --Sam

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: WG Last Call: AIA CRL extension
From: Tom Gindin <[email-masked]>
Date: Mon, 23 May 2005 22:46:48 -0400
Sender: [email-masked]

        Tim:

        I should probably have brought this up earlier, but are we certain 
that "same trust anchor" is a strong enough check that the CRL signer is 
the one expected by the issuing CA?  While I was not in San Diego when 
this wording was included in the 3280 series, I do not really think that 
that check is strong enough.  I would suggest instead that the CRL 
signer's certificate needs to be directly issued by one of the CA's in the 
certification path back to the trust anchor used for the certificate's 
verification, or by that anchor itself, unless people have practical 
experience with CA structures which that rule would prohibit.  Forcing the 
CRL to be issued by the CA itself (as I understand Denis to have 
suggested) prohibits the reasonable case where the CRL is issued by a 
hierarchical superior, so it is IMHO too strict.
        I am personally not sure, FWIW, that a CRL should be permitted to 
be signed by a second-cousin certificate of the issuer's certificate.  By 
analogy to the use of the terms in families, "sibling" certificates would 
have the same issuer, "first-cousin" certificates would be issued by 
siblings, and "second-cousin" certificates would be issued by first 
cousins - so they are both three levels down from the same trust anchor, 
or from the last common CA in their paths.  This issue is not newly caused 
by CRL AIA, since the same issue can arise with CRL's containing only 
AKID.  AIA only allows RP's to build a path (whether right or wrong) more 
quickly.
        In any case, nothing more than a note in Security Considerations 
is appropriate in any of our RFC's other than 3280 and its successor.

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

Tim Polk <[email-masked]>
Sent by: [email-masked]
05/10/2005 05:27 PM
 
        To:     [email-masked]
        cc:     [email-masked], [email-masked], [email-masked]
        Subject:        WG Last Call: AIA CRL extension

This message initiates working group Last Call for the specification 
"Internet X.509 Public Key Infrastructure: Authority Information Access 
CRL 
Extension".  While some issues raised in the working group are unresolved, 

the editors believe that rough consensus supports the current 
specification.

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

Last Call will run for (at least) two weeks. That is, Last Call will not 
close before May 24.

Thanks,

Tim Polk 

Date: Mon, 23 May 2005 17:31:44 -0500
To: [email-masked], [email-masked], [email-masked]
Subject: RFC 4043 on Internet X.509 Public Key Infrastructure PermanentIdentifier
From: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

        RFC 4043

        Title:      Internet X.509 Public Key Infrastructure
                    Permanent Identifier
        Author(s):  D. Pinkas, T. Gindin
        Status:     Standards Track
        Date:       May 2005
        Mailbox:    [email-masked], [email-masked]
        Pages:      15
        Characters: 30092
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-pi-11.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4043.txt

This document defines a new form of name, called permanent
identifier, that may be included in the subjectAltName extension
of a public key certificate issued to an entity.

The permanent identifier is an optional feature that may be used
by a CA to indicate that two or more certificates relate to the
same entity, even if they contain different subject name (DNs) or
different names in the subjectAltName extension, or if the name
or the affiliation of that entity stored in the subject or another
name form in the subjectAltName extension has changed.

The subject name, carried in the subject field, is only unique
for each subject entity certified by the one CA as defined by the
issuer name field.  However, the new name form can carry a
name that is unique for each subject entity certified by a CA.

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

This is now a Proposed Standard Protocol.

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 list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body=20
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

=2E..

Below is the data which will enable a MIME compliant Mail Reader=20
implementation to automatically retrieve the ASCII version
of the RFCs.

------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX
Content-Type: application/octet-stream;
	name="2#Part.001"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="2#Part.001"

Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MDUwNTIzMTQxMDIzLlJG
Q0BSRkMtRURJVE9SLk9SRz4NCg0KUkVUUklFVkU6IHJmYw0KRE9DLUlEOiByZmM0MDQzDQo=

------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX
Content-Type: text/plain;
	name="3#rfc4043.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="3#rfc4043.txt"

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

------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX
Content-Type: application/octet-stream;
	name="4#Part.003"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="4#Part.003"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYt
QW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczov
L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlDQo=

------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX
Content-Type: application/octet-stream;
	name="5#Mime.822"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="5#Mime.822"

------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX
Content-Type: text/plain;
	name="GWAVADAT.TXT"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="GWAVADAT.TXT"

AdmID:217BFB629F3CF22BFC888D9128A2CB31

------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX--

To: [email-masked]
Subject: RFC 4043 on Internet X.509 Public Key Infrastructure Permanent Identifier
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Mon, 23 May 2005 14:12:28 -0700
Sender: [email-masked]

--NextPart

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

        RFC 4043

        Title:      Internet X.509 Public Key Infrastructure
                    Permanent Identifier
        Author(s):  D. Pinkas, T. Gindin
        Status:     Standards Track
        Date:       May 2005
        Mailbox:    [email-masked], [email-masked]
        Pages:      15
        Characters: 30092
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-pi-11.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4043.txt

This document defines a new form of name, called permanent
identifier, that may be included in the subjectAltName extension
of a public key certificate issued to an entity.

The permanent identifier is an optional feature that may be used
by a CA to indicate that two or more certificates relate to the
same entity, even if they contain different subject name (DNs) or
different names in the subjectAltName extension, or if the name
or the affiliation of that entity stored in the subject or another
name form in the subjectAltName extension has changed.

The subject name, carried in the subject field, is only unique
for each subject entity certified by the one CA as defined by the
issuer name field.  However, the new name form can carry a
name that is unique for each subject entity certified by a CA.

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

This is now a Proposed Standard Protocol.

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 list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

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

RETRIEVE: rfc
DOC-ID: rfc4043

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc4043.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sim-04.txt
Date: Mon, 23 May 2005 15:46:07 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Subject 
			  Identification Method (SIM)
	Author(s)	: J. Park, et al.
	Filename	: draft-ietf-pkix-sim-04.txt
	Pages		: 16
	Date		: 2005-5-23
	
This document defines Privacy-Enhanced Protected Subject Identifier
   (PEPSI) format for including a privacy sensitive identifier in the
   subjectAltName extension of a certificate.

   The PEPSI is an optional feature that may be used by a relying
   parties to determine whether the subject of a particular certificate
   is also the person corresponding to a particular sensitive
   identifier.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: Request for new work item - Defining an SRV RR otherName
Date: Mon, 23 May 2005 17:21:08 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

FYI

The SRV RR draft is now available from internet-drafts.

http://www.ietf.org/internet-drafts/draft-santesson-pkix-srvrr-00.txt

/Stefan

> On Behalf Of Stefan Santesson
> Sent: den 20 maj 2005 22:07
> To: Sam Hartman
> Cc: [email-masked]
> Subject: RE: Request for new work item - Defining an SRV RR otherName
> 
> 
> Sorry for being a bit unclear.
> Yes, you could use the Kerberos principal name specifically for
Kerberos
> but not for other service types.
> 
> The benefit from the proposed SRV RR other name is that you could
deploy
> a generic approach, which maps 1:1 to service lookup via DNS for a
wider
> range of services and avoid different solutions for each service type.
> 
> Yes, this means that we need to go through the pain to recognize a new
> otherName, but now when we have to go there, the thought is that we
then
> may be better served with a more generic approach for client side
> service validation rather than doing it just for Kerberos.
> 
> /Stefan
> 
> 
> 
> > From: Sam Hartman [mailto:[email-masked]]
> > Sent: den 20 maj 2005 19:10
> > To: Stefan Santesson
> > Cc: [email-masked]
> > Subject: Re: Request for new work item - Defining an SRV RR
otherName
> >
> > >>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:
> >
> >     Stefan> Sam, My recollection of this issue is a bit different
from
> >     Stefan> yours.
> >
> >     Stefan> The central need here is to enable the KDC to express in
a
> >     Stefan> certificate the fact that it is a KDC in a way that male
> >     Stefan> sense to clients.
> >
> >
> > If this is all you want, bind the KDC certificate to the TGS
principal
> > for the realm. That's what Larry's pkinit 26 text does.
> >
> > The original problem with that solution is that it required CAs to
> > implement the kerberos OtherName.  However this approach also
requires
> > the CA to implement a new OtherName.

Content-class: urn:content-classes:message
Subject: RE: Request for new work item - Defining an SRV RR otherName
Date: Sat, 21 May 2005 06:07:16 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Sam Hartman" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Sorry for being a bit unclear.
Yes, you could use the Kerberos principal name specifically for Kerberos
but not for other service types.

The benefit from the proposed SRV RR other name is that you could deploy
a generic approach, which maps 1:1 to service lookup via DNS for a wider
range of services and avoid different solutions for each service type.

Yes, this means that we need to go through the pain to recognize a new
otherName, but now when we have to go there, the thought is that we then
may be better served with a more generic approach for client side
service validation rather than doing it just for Kerberos. 

/Stefan

> From: Sam Hartman [mailto:[email-masked]]
> Sent: den 20 maj 2005 19:10
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: Request for new work item - Defining an SRV RR otherName
> 
> >>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:
> 
>     Stefan> Sam, My recollection of this issue is a bit different from
>     Stefan> yours.
> 
>     Stefan> The central need here is to enable the KDC to express in a
>     Stefan> certificate the fact that it is a KDC in a way that male
>     Stefan> sense to clients.
> 
> 
> If this is all you want, bind the KDC certificate to the TGS principal
> for the realm. That's what Larry's pkinit 26 text does.
> 
> The original problem with that solution is that it required CAs to
> implement the kerberos OtherName.  However this approach also requires
> the CA to implement a new OtherName.

To: "Stefan Santesson" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Request for new work item - Defining an SRV RR otherName
From: Sam Hartman <[email-masked]>
Date: Fri, 20 May 2005 22:09:47 -0400
Sender: [email-masked]

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

    Stefan> Sam, My recollection of this issue is a bit different from
    Stefan> yours.

    Stefan> The central need here is to enable the KDC to express in a
    Stefan> certificate the fact that it is a KDC in a way that male
    Stefan> sense to clients.

If this is all you want, bind the KDC certificate to the TGS principal
for the realm. That's what Larry's pkinit 26 text does.

The original problem with that solution is that it required CAs to
implement the kerberos OtherName.  However this approach also requires
the CA to implement a new OtherName.

Content-class: urn:content-classes:message
Subject: RE: Request for new work item - Defining an SRV RR otherName
Date: Fri, 20 May 2005 23:44:38 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Sam Hartman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Sam,

My recollection of this issue is a bit different from yours.

The central need here is to enable the KDC to express in a certificate
the fact that it is a KDC in a way that male sense to clients.

In a traditional Kerberos environment the KDC can be known as a KDC
since it can demonstrate knowledge of the user's key.

In PKI initiated Kerberos, this property is lost.

If the client knows the host name, IP address or any other identity of
the KDC, which can be mapped to information in the KDC certificate, then
we are good and appropriate binding is possible.

However, from what I have learned, we may face situations where a client
only know the name of the domain it wants to access and the fact that it
looks for a PKINIT enabled KDC. In this case it is assumed that the
client would do a SRV RR query to the DNS to get the host name of the
currently available KDC.

If the SRV RR is NOT the appropriate name to bind to in this case, then
my question is what the alternative is.

Finally, the reason to do this in PKIX is since this in principle is a
generic way of service discovery that may be useful also for other
services where the client only know service name, protocol and domain. I
have indications that it is becoming more and more interesting to
dynamically search for services in this manner for other services but
I'm very interested of other opinions here.

I don't however understand in what way we need to be careful to limit
this only to some specific services. Could you clarify this concern? 

/Stefan

> On Behalf Of Sam Hartman
> Sent: den 20 maj 2005 12:39
> To: [email-masked]
> Subject: Re: Request for new work item - Defining an SRV RR otherName
> 
> 
> 
> 
> Hi.  I'm speaking as an individual not as an AD.
> 
> This proposal was originally introduced as a use of dnsname in the
> Kerberos working group for pkinit.
> 
> The authors of the proposal would like to name services as they are
> identified by users.  For example a user types foo.bar.example.com
> into some program.  The program looks up a SRV record for some service
> and then connects to that service.  If insecure DNS is used then the
> dns lookup should not be part of the name against which a certificate
> is checkde.
> 
> We're seeing a similar situation in the kitten working group ; see
> draft-ietf-kitten-gssapi-domain-based-names-00.txt.
> 
> 
> The idea of this proposal is that the certificate contain the name
> that the client system would look up in the same form as the client
> uses to look in DNS.
> 
> I'm not sure how this proposal has evolved since it was first
> presented to me.  Originally the goal was so that application
> libraries could use some sort of automatic mechanism to:
> 
> * Look up SRV records
> 
> * Bind to TLS certificates
> 
> * Find the Kerberos principal name
> 
> * Bind to pkinit certificates.
> 
> All the application author would do would be to pass the service
> protocol and name into some magic function.
> 
> That bothers me.  There is no guarantee that the SRV record tag will
> match the GSS/Kerberos principal name.  There is no guarantee that the
> service in question doesn't have some better choice for certificate
> binding like one of the IMPP-specific solutions.
> 
> 
> I'm also not quite sure that SRV tags are real/really the right thing
> to be binding to.
> 
> If the PKIX working group does adopt this proposal I would recommend
> being very careful.  Make sure to scope it only to be used for
> applications/services where it is appropriate.  Make sure to discuss
> applications that already have a mechanism for binding their
> certificates.
> 
> It might also be important to find out if there is actually a use case
> for this name type before standardizing it.  There wasn't really that
> much support in krb-wg for the earlier version of this.
> 
> --Sam

To: [email-masked]
Subject: Re: Request for new work item - Defining an SRV RR otherName
From: Sam Hartman <[email-masked]>
Date: Fri, 20 May 2005 15:39:14 -0400
Sender: [email-masked]

Hi.  I'm speaking as an individual not as an AD.

This proposal was originally introduced as a use of dnsname in the
Kerberos working group for pkinit.

The authors of the proposal would like to name services as they are
identified by users.  For example a user types foo.bar.example.com
into some program.  The program looks up a SRV record for some service
and then connects to that service.  If insecure DNS is used then the
dns lookup should not be part of the name against which a certificate
is checkde.

We're seeing a similar situation in the kitten working group ; see
draft-ietf-kitten-gssapi-domain-based-names-00.txt.

The idea of this proposal is that the certificate contain the name
that the client system would look up in the same form as the client
uses to look in DNS.

I'm not sure how this proposal has evolved since it was first
presented to me.  Originally the goal was so that application
libraries could use some sort of automatic mechanism to:

* Look up SRV records

* Bind to TLS certificates

* Find the Kerberos principal name

* Bind to pkinit certificates.

All the application author would do would be to pass the service
protocol and name into some magic function.

That bothers me.  There is no guarantee that the SRV record tag will
match the GSS/Kerberos principal name.  There is no guarantee that the
service in question doesn't have some better choice for certificate
binding like one of the IMPP-specific solutions.

I'm also not quite sure that SRV tags are real/really the right thing
to be binding to.

If the PKIX working group does adopt this proposal I would recommend
being very careful.  Make sure to scope it only to be used for
applications/services where it is appropriate.  Make sure to discuss
applications that already have a mechanism for binding their
certificates.

It might also be important to find out if there is actually a use case
for this name type before standardizing it.  There wasn't really that
much support in krb-wg for the earlier version of this.

--Sam

Content-class: urn:content-classes:message
Subject: RE: Request for new work item - Defining an SRV RR otherName
Date: Fri, 20 May 2005 18:28:08 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Yes,

The initial background thought was that more demanding encodings would
be more of an issue for host labels rather than service resource records
and thus IA5String would be sufficient, but I agree at this point to the
suggestions to specify UTF8String instead.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of Jean-Marc Desperrier
> Sent: den 20 maj 2005 01:42
> To: [email-masked]
> Subject: Re: Request for new work item - Defining an SRV RR otherName
> 
> 
> Manger, James H wrote:
> 
> >How about using UTF8String, instead of IA5String?  The latter does
not
> gain much (it can still include chars such as 0x00, newline, bell that
are
> presumably not valid in SRV RR names), while the former should be more
> future-proof.
> >
> >      SRVRRName ::= UTF8String
> >
> >
> 
> >Could you post the suggestion to the pkix list to see if there are
any
> >other reactions?
> >
> >
> It's already really a pity that dNSName forces us to store SAN in ACE
> encoding, instead of being able to put the real unicode value, so I'm
> all for not doing the mistake again.

Date: Fri, 20 May 2005 10:19:51 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

Wrote Simon McMahon <[email-masked]>, on Fri, May 20, 2005 at 07:50:03AM +1000:
> The example should match typical usage and doesn't have to cover every
> possibility.

It probably isn't "typical", but the TCG uses RSA private keys encrypted
with RSA public keys of the same strength.

IIRC, instead of encrypting d,p-1,q-1,... (which would be too large),
they only encrypt p. The decryptor can recreate the rest of the private
key from the public key and knowledge of p.

Cheers,
Sam

> 
> Simon.
> 
> 
> Simon McMahon
> 
> Work: (07) 31311420
> Mobile: (043) 2294180
> 
> 
> >>> <[email-masked]> 05/18/05 12:15am >>>
> But, if the asymmetric private key is based on elliptic curves?
> 
> Diego
> 
> ----- Mensaje Original -----
> Remitente: "Simon McMahon" [email-masked] 
> Destinatario: [email-masked], [email-masked] 
> Fecha: Martes, Mayo 17, 2005  1:03am
> Asunto: Re: key usage - key encipherment or data encipherment
> 
> >
> >The example for 'keyEncipherment' should not include an "RSA public 
> >key encrypting an asymmetric private key", which, if it is also RSA 
> >is too big to encrypt with the public key. Surely, an RFC shouldn't 
> >list impossible cases as examples.
> >
> >Simon.
> >
> 
> 
> 
> 
> 
> ***********************************************************************************
> This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.
> 
> Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.
> 
> If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
> ***********************************************************************************
> 

-- 
http://www.certicom.com

Date: Fri, 20 May 2005 10:42:28 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Request for new work item - Defining an SRV RR otherName
Sender: [email-masked]

Manger, James H wrote:

>How about using UTF8String, instead of IA5String?  The latter does not gain much (it can still include chars such as 0x00, newline, bell that are presumably not valid in SRV RR names), while the former should be more future-proof.
>
>      SRVRRName ::= UTF8String
>  
>

>Could you post the suggestion to the pkix list to see if there are any
>other reactions?
>  
>
It's already really a pity that dNSName forces us to store SAN in ACE 
encoding, instead of being able to put the real unicode value, so I'm 
all for not doing the mistake again.

content-class: urn:content-classes:message
Subject: RE: Request for new work item - Defining an SRV RR otherName
Date: Fri, 20 May 2005 11:26:23 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

RE: draft-santesson-pkix-srvrr-00

How about using UTF8String, instead of IA5String?  The latter does not gain much (it can still include chars such as 0x00, newline, bell that are presumably not valid in SRV RR names), while the former should be more future-proof.

      SRVRRName ::= UTF8String

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, 19 May 2005 11:53 PM
To: Manger, James H

When I talked to Russ we thought that IA5String would be sufficient so I
did put that in as a start, but I'm completely open to a change to
UTF8String.

Could you post the suggestion to the pkix list to see if there are any
other reactions?

Date: Fri, 20 May 2005 11:13:24 +1000
From: "Simon McMahon" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

Eric,

> The user doesn't really care or even want to know whether an intermediate symmetric key in involved or not.

I agree. The increased complexity of the rewording for 'keyEncipherment' is even more information that the user, or implementer, doesn't need to know.

Having two bits for encryption just makes room for interoperability problems like those already mentioned. Where exactly is the benefit? Earlier remarks that it should be preserved until people are "smart enough" to make good use of it dont help much.

If the use of 'dataEncipherment' is deprecated, but not reused for another purpose, we would have only 1 bit 'keyEncipherment' that could be renamed 'encipherment'. The proposed rewording discourages use of 'dataEncipherment' anyway. This would have little impact on implementations that use 'keyEncipherment' already, or implementations that set both bits because the distinction is so unclear and irrelevant.

Simon.

Simon McMahon

Work: (07) 31311420
Mobile: (043) 2294180

>>> Eric Norman <[email-masked]> 05/20/05 07:16am >>>

On May 19, 2005, at 1:33 PM, Hallam-Baker, Phillip wrote:

> I have been following the thread, I think the cures proposed may be
> worse than the problem.
>
> I think that the sentences can be adequately clarified by stating that
> dataEncipherment is to be set if the key is to be used to directly
> encipher data, i.e. without the use of an intermediate session key.

I might as well chime in with my take, which is different yet.  And 
since
those two bits have already appeared in standards documents, probably
not worth anything.

I think that from a user's point of view, all the user cares about is 
that
the data is protected in transit and perhaps at rest.  The user doesn't
really care or even want to know whether an intermediate symmetric key
in involved or not.  From that point of view, the distinction seems 
rather silly.

Now, if someone came up with a key escrow scheme that would escrow
the symmetric key, then that might be interesting.  But that's yet 
another
thread.

Eric Norman
University of WIsconsin

***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************

Date: Fri, 20 May 2005 07:50:03 +1000
From: "Simon McMahon" <[email-masked]>
To: <[email-masked]>
Cc: "<"<[email-masked]>
Subject: RE: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

Sure, but the rewording mentions "RSA" for the public key and doesn't specify anything for the private.

Do asymmetric ciphers often get combined this way in practice? A device would need full implementations of both RSA and elliptic curve to support this.

The example should match typical usage and doesn't have to cover every possibility. The current wording implies RSA.

Simon.

Simon McMahon

Work: (07) 31311420
Mobile: (043) 2294180

>>> <[email-masked]> 05/18/05 12:15am >>>
But, if the asymmetric private key is based on elliptic curves?

Diego

----- Mensaje Original -----
Remitente: "Simon McMahon" [email-masked] 
Destinatario: [email-masked], [email-masked] 
Fecha: Martes, Mayo 17, 2005  1:03am
Asunto: Re: key usage - key encipherment or data encipherment

>
>The example for 'keyEncipherment' should not include an "RSA public 
>key encrypting an asymmetric private key", which, if it is also RSA 
>is too big to encrypt with the public key. Surely, an RFC shouldn't 
>list impossible cases as examples.
>
>Simon.
>

***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************

Date: Thu, 19 May 2005 16:16:28 -0500
From: Eric Norman <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
To: [email-masked]
Sender: [email-masked]

On May 19, 2005, at 1:33 PM, Hallam-Baker, Phillip wrote:

> I have been following the thread, I think the cures proposed may be
> worse than the problem.
>
> I think that the sentences can be adequately clarified by stating that
> dataEncipherment is to be set if the key is to be used to directly
> encipher data, i.e. without the use of an intermediate session key.

I might as well chime in with my take, which is different yet.  And 
since
those two bits have already appeared in standards documents, probably
not worth anything.

I think that from a user's point of view, all the user cares about is 
that
the data is protected in transit and perhaps at rest.  The user doesn't
really care or even want to know whether an intermediate symmetric key
in involved or not.  From that point of view, the distinction seems 
rather silly.

Now, if someone came up with a key escrow scheme that would escrow
the symmetric key, then that might be interesting.  But that's yet 
another
thread.

Eric Norman
University of WIsconsin

Content-class: urn:content-classes:message
Subject: RE: key usage - key encipherment or data encipherment
Date: Thu, 19 May 2005 11:33:04 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I have been following the thread, I think the cures proposed may be
worse than the problem.

I think that the sentences can be adequately clarified by stating that
dataEncipherment is to be set if the key is to be used to directly
encipher data, i.e. without the use of an intermediate session key.

I accept that this is not a particularly interesting use of
dataEncipherment, the only protocols I can think of in which data is
directly enciphered with a public key is Chaumian cash schemes and
similar where blinding is used. Everywhere else you want to use a
packaging scheme because the strength of bit 0 in RSA is pretty good but
the strength of bit 1024 with a 1024 bit key is pretty bad.

Date: Thu, 19 May 2005 18:34:31 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: Improving PKCS#11
Sender: [email-masked]

Peter,

See my comment at the bottom of this e-mail.

>>The purpose is to make impossible, whatever the user application asks, to
>>extract the private key in the clear.

> Since the flags are ultimately controlled by the user app (no matter what you
> call them or where you put them), the user app is *always* going to get the
> key if it really wants it.  The only thing that'll stop it is if the hardware
> prevents this (see below).

>>>If the hardware makes
>>>it unextractable (e.g. in Fortezza cards), it'll implicitly set
>>>CKA_EXTRACTABLE for you.

>>The hardware cannot do anything since currently the setting of the flag
>>CKA_EXTRACTABLE is left to the application.

> That's merely a request from the software side.  A Fortezza card isn't going
> to give you the key, no matter what you set CKA_EXTRACTABLE to.  Conversely, a
> Cryptoflex (at least the older ones) will always give you the key because it
> only contains a private-key engine (you can't even do public-key encryption
> with it).  So if you try and set the flag in a way that isn't supported by the
> hardware, you'll get a template-inconsistent error (or you may get the object
> created but with the template modified according to the hardware capabilities,
> depending on the implementation).  Ultimately, the crypto hardware gets the
> last word, not an application-set flag.  Unlike PKIX, the PKCS #11 folks are
> somewhat reluctant to set standards requirements that violate the laws of
> physics.

>>I do not think so: the purpose is not to modify any existing command, but to
>>add only ONE new one which might be called something like:

>>C_UnwrapKeyCkaExtractableFalse

>>where the certificate used to perform the operation would have a key usage
>>like: keyEnciphermentNoExtract. This means that the "cryptographic material",
>>once decrypted, cannot be extracted.

> But again, this depends *entirely* on the calling software.  It doesn't matter
> how you dress this up, if the calling app wants the key, all it has to do is
> call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse, or set
> CKA_EXTRACTABLE to true in the template for C_UnwrapKey, or whatever.  

I did not made my explanations clear enough.

A private key, when generated within the token, would be marked to be usable 
only with C_UnwrapKeyCkaExtractableFalse. So if the application attempts to 
use it with C_UnwrapKey this will fail. This would mean that the certificate 
corresponding to that private key would then be marked with 
keyEncipherment-no-extract.

Denis

> If the
> calling app wants to it can look at the cert, see that keyEncipherment is set
> to true and dataEncipherment false, and then go ahead and set CKA_EXTRACTABLE
> to true or call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse.  There
> is therefore no difference between C_UnwrapKeyCkaExtractableFalse and
> C_UnwrapKey with CKA_EXTRACTABLE set to false.
> 
> Peter.

Subject: Re: EuroPKI 2005 - Call for Participation
To: "Anders Rundgren" <[email-masked]>
Cc: "David Chadwick" <[email-masked]>, PKIX <[email-masked]>
From: [email-masked]
Date: Thu, 19 May 2005 10:19:09 -0600
Sender: [email-masked]

at 3:25pm 5/18/05, anders rundgen wrote:
> The problem is that none these systems are supported by PCs as this
industry
> have shown to be incapable of defining a mobile, secure container.
> Esoteric explanations may be more fun to talk about but they have little
> validity as ID TTP liability etc.has not been put to test in any major
way yet.
> "non-repudiation", has probably not happened once!
>
> BTW, maybe you guys should begin to look on the next ID "revolution"
> Microsoft's InfoCard stuff?

slightly related thread in
http://www.garlic.com/~lynn/2005h.html#36 Security via hardware?

includes some reference to patent activity on authentication token
integrity.

and a press release from today
http://www.gamesindustry.biz/press_release.php?aid=9008

an aads offering
http://www.garlic.com/~lynn/index.html#aads

a couple minor other postings in somewhat related threads:
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL
being used
http://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on
interbank xfers due to phishing boom

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Content-class: urn:content-classes:message
Subject: RE: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Thu, 19 May 2005 17:01:19 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

I do want to understand!

Yes, let's talk in Sophia Antipolis and save some bandwidth on this
list.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 19 maj 2005 08:57
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Structuring Denis issues RE: Comments on
<draft-ietf-pkix-
> crlaia-00.txt>
> 
> Stefan,
> 
> I'm afraid that you do not want to understand. Since you and me will
be in
> Sophia Antipolis in about one week from now, I propose that we stop to
> discuss on this list now and have a face to face discussion there.
> 
> Denis
> 
> > Denis,
> >
> > I'm afraid that this e-mail from you doesn't help me understand your
> > answer to my question (how your raised issues are related
specifically
> > to the use of the AIA extension in CRLs).
> >
> > The only argument I find in this context is that you fear that the
CRL
> > user would simply accept and trust the certificate they obtain
through
> > this extension.
> >
> > But this would be in violation to RFC 3280 path validation which
> > specifies what you need to do to validate a certificate. These rules
> > apply also to the certificate you obtained through the CRL AIA
extension
> > (It applies to all certificates you want to validate). Thus, an
> > implementation that follows RFC 3280 when validating the certificate
> > they obtained through CRL-AIA will not be subject to
man-in-the-middle
> > attacks and will not "simply use what they got from the pointer".
> >
> > Validation of the CRL Issuer certificate (and its path) is nothing
new.
> > The only difference introduced in this draft is an alternative way
to
> > discover/locate a certificate that can validate the CRL you already
> > picked as a candidate CRL.
> >
> > To incorporate any of your proposed amendments we still need you to
> > explain how each of your issues and proposed resolutions
specifically
> > ties to THAT particular feature introduced by this draft.
> >
> >
> >
> > Stefan Santesson
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> >>From: Denis Pinkas [mailto:[email-masked]]
> >>Sent: den 19 maj 2005 08:18
> >>To: Stefan Santesson
> >>Cc: pkix
> >>Subject: Re: Structuring Denis issues RE: Comments on
> >
> > <draft-ietf-pkix-
> >
> >>crlaia-00.txt>
> >>
> >>Stefan,
> >>
> >>
> >>>Denis,
> >>
> >>>Thanks for the clarification.
> >>>Yes, we agree on issue number 1 (remove SHOULD and MUST)
> >>
> >>We also agree on a typo. :-|
> >>
> >>
> >>>So the remaining issue is:
> >>>
> >>>Problem: The security considerations talk about "mitigation" of the
> >>
> > name
> >
> >>>collision problem but gives inadequate advice.
> >>>
> >>>Your proposed resolution
> >>>
> >>> a) warn the user that the CRL where this extension was found may
> >>
> > not be
> >
> >>>    the right one.
> >>
> >>The AIA extension in found in a CRL that is not yet checked to be
the
> >>right one.
> >>
> >>
> >>> b) warn the user that the CRL issuer certificate he might obtain
> >>
> > using
> >
> >>>    this extension may not be the right one.
> >>
> >>The AIA extension does not provide enough information so that the
CRL
> >>issuer
> >>  certificate that is found there is indeed the right one, since at
> >
> > this
> >
> >>time the certification path is not yet formed. There may be a
> >>man-in-the-middle attack.
> >>
> >>
> >>> c) provide guidance on how to GUARANTEE that the CRL Issuer is
> >>
> > indeed
> >
> >>>    the one nominated by the CA that has issued the target
> >>
> > certificate
> >
> >>>    (i.e. when the CRL Issuer certification path and the target
> >>>    certificate certification path are identical).
> >>
> >>This would indeed be a useful guidance given the two above
statements.
> >>
> >>
> >>> d) say that other possibilities exists, but need additional trust
> >>>    conditions (there are zillions of such possible trust
> >>
> > conditions).
> >
> >>This would indeed be a useful guidance given the previous statement.
> >>
> >>I am spending a *considerable* time on this issue and I believe that
> >
> > you
> >
> >>have now perfectly understood what the problem is.
> >>
> >>You know that I do not consider the AIA extension useful in the
> >
> > "basic"
> >
> >>case.
> >>
> >>Since the other cases (the "zillions" of other cases) rely anyway on
> >>additional local trust conditions, some local configuration values
may
> >
> > be
> >
> >>used to know where to fetch the missing CRL issuer certificates,
hence
> >
> > why
> >
> >>this extension is not really useful and may even be dangerous to be
> >
> > used
> >
> >>if
> >>people simply use what they get from the pointer.
> >>
> >>Denis
> >>
> >>
> >>>To complete the picture it would now be very helpful if you, for
> >>
> > each of
> >
> >>>these statements, could confirm or explain how these issues are a
> >>
> > result
> >
> >>>of using the AIA extension in CRLs. Or in other words, which of
> >>
> > these
> >
> >>>security considerations could you ignore (would go away) if you
were
> >>
> > NOT
> >
> >>>using the AIA extension in a CRL to locate the CRL Issuer
> >>
> > certificate.
> >
> >>>
> >>>
> >>>Stefan Santesson
> >>>Program Manager, Standards Liaison
> >>>Windows Security
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> 

Date: Thu, 19 May 2005 17:56:52 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Stefan,

I'm afraid that you do not want to understand. Since you and me will be in 
Sophia Antipolis in about one week from now, I propose that we stop to 
discuss on this list now and have a face to face discussion there.

Denis

> Denis,
> 
> I'm afraid that this e-mail from you doesn't help me understand your
> answer to my question (how your raised issues are related specifically
> to the use of the AIA extension in CRLs).
> 
> The only argument I find in this context is that you fear that the CRL
> user would simply accept and trust the certificate they obtain through
> this extension.
> 
> But this would be in violation to RFC 3280 path validation which
> specifies what you need to do to validate a certificate. These rules
> apply also to the certificate you obtained through the CRL AIA extension
> (It applies to all certificates you want to validate). Thus, an
> implementation that follows RFC 3280 when validating the certificate
> they obtained through CRL-AIA will not be subject to man-in-the-middle
> attacks and will not "simply use what they got from the pointer".
> 
> Validation of the CRL Issuer certificate (and its path) is nothing new.
> The only difference introduced in this draft is an alternative way to
> discover/locate a certificate that can validate the CRL you already
> picked as a candidate CRL.
> 
> To incorporate any of your proposed amendments we still need you to
> explain how each of your issues and proposed resolutions specifically
> ties to THAT particular feature introduced by this draft.
> 
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>  
> 
>>From: Denis Pinkas [mailto:[email-masked]]
>>Sent: den 19 maj 2005 08:18
>>To: Stefan Santesson
>>Cc: pkix
>>Subject: Re: Structuring Denis issues RE: Comments on
> 
> <draft-ietf-pkix-
> 
>>crlaia-00.txt>
>>
>>Stefan,
>>
>>
>>>Denis,
>>
>>>Thanks for the clarification.
>>>Yes, we agree on issue number 1 (remove SHOULD and MUST)
>>
>>We also agree on a typo. :-|
>>
>>
>>>So the remaining issue is:
>>>
>>>Problem: The security considerations talk about "mitigation" of the
>>
> name
> 
>>>collision problem but gives inadequate advice.
>>>
>>>Your proposed resolution
>>>
>>> a) warn the user that the CRL where this extension was found may
>>
> not be
> 
>>>    the right one.
>>
>>The AIA extension in found in a CRL that is not yet checked to be the
>>right one.
>>
>>
>>> b) warn the user that the CRL issuer certificate he might obtain
>>
> using
> 
>>>    this extension may not be the right one.
>>
>>The AIA extension does not provide enough information so that the CRL
>>issuer
>>  certificate that is found there is indeed the right one, since at
> 
> this
> 
>>time the certification path is not yet formed. There may be a
>>man-in-the-middle attack.
>>
>>
>>> c) provide guidance on how to GUARANTEE that the CRL Issuer is
>>
> indeed
> 
>>>    the one nominated by the CA that has issued the target
>>
> certificate
> 
>>>    (i.e. when the CRL Issuer certification path and the target
>>>    certificate certification path are identical).
>>
>>This would indeed be a useful guidance given the two above statements.
>>
>>
>>> d) say that other possibilities exists, but need additional trust
>>>    conditions (there are zillions of such possible trust
>>
> conditions).
> 
>>This would indeed be a useful guidance given the previous statement.
>>
>>I am spending a *considerable* time on this issue and I believe that
> 
> you
> 
>>have now perfectly understood what the problem is.
>>
>>You know that I do not consider the AIA extension useful in the
> 
> "basic"
> 
>>case.
>>
>>Since the other cases (the "zillions" of other cases) rely anyway on
>>additional local trust conditions, some local configuration values may
> 
> be
> 
>>used to know where to fetch the missing CRL issuer certificates, hence
> 
> why
> 
>>this extension is not really useful and may even be dangerous to be
> 
> used
> 
>>if
>>people simply use what they get from the pointer.
>>
>>Denis
>>
>>
>>>To complete the picture it would now be very helpful if you, for
>>
> each of
> 
>>>these statements, could confirm or explain how these issues are a
>>
> result
> 
>>>of using the AIA extension in CRLs. Or in other words, which of
>>
> these
> 
>>>security considerations could you ignore (would go away) if you were
>>
> NOT
> 
>>>using the AIA extension in a CRL to locate the CRL Issuer
>>
> certificate.
> 
>>>
>>>
>>>Stefan Santesson
>>>Program Manager, Standards Liaison
>>>Windows Security
>>>
>>>
>>>
>>>
>>
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Thu, 19 May 2005 16:46:40 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

Denis,

I'm afraid that this e-mail from you doesn't help me understand your
answer to my question (how your raised issues are related specifically
to the use of the AIA extension in CRLs).

The only argument I find in this context is that you fear that the CRL
user would simply accept and trust the certificate they obtain through
this extension.

But this would be in violation to RFC 3280 path validation which
specifies what you need to do to validate a certificate. These rules
apply also to the certificate you obtained through the CRL AIA extension
(It applies to all certificates you want to validate). Thus, an
implementation that follows RFC 3280 when validating the certificate
they obtained through CRL-AIA will not be subject to man-in-the-middle
attacks and will not "simply use what they got from the pointer".

Validation of the CRL Issuer certificate (and its path) is nothing new.
The only difference introduced in this draft is an alternative way to
discover/locate a certificate that can validate the CRL you already
picked as a candidate CRL.

To incorporate any of your proposed amendments we still need you to
explain how each of your issues and proposed resolutions specifically
ties to THAT particular feature introduced by this draft.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 19 maj 2005 08:18
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Structuring Denis issues RE: Comments on
<draft-ietf-pkix-
> crlaia-00.txt>
> 
> Stefan,
> 
> > Denis,
> 
> > Thanks for the clarification.
> > Yes, we agree on issue number 1 (remove SHOULD and MUST)
> 
> We also agree on a typo. :-|
> 
> > So the remaining issue is:
> >
> > Problem: The security considerations talk about "mitigation" of the
name
> > collision problem but gives inadequate advice.
> >
> > Your proposed resolution
> >
> >  a) warn the user that the CRL where this extension was found may
not be
> >     the right one.
> 
> The AIA extension in found in a CRL that is not yet checked to be the
> right one.
> 
> >  b) warn the user that the CRL issuer certificate he might obtain
using
> >     this extension may not be the right one.
> 
> The AIA extension does not provide enough information so that the CRL
> issuer
>   certificate that is found there is indeed the right one, since at
this
> time the certification path is not yet formed. There may be a
> man-in-the-middle attack.
> 
> >  c) provide guidance on how to GUARANTEE that the CRL Issuer is
indeed
> >     the one nominated by the CA that has issued the target
certificate
> >     (i.e. when the CRL Issuer certification path and the target
> >     certificate certification path are identical).
> 
> This would indeed be a useful guidance given the two above statements.
> 
> >  d) say that other possibilities exists, but need additional trust
> >     conditions (there are zillions of such possible trust
conditions).
> 
> This would indeed be a useful guidance given the previous statement.
> 
> I am spending a *considerable* time on this issue and I believe that
you
> have now perfectly understood what the problem is.
> 
> You know that I do not consider the AIA extension useful in the
"basic"
> case.
> 
> Since the other cases (the "zillions" of other cases) rely anyway on
> additional local trust conditions, some local configuration values may
be
> used to know where to fetch the missing CRL issuer certificates, hence
why
> this extension is not really useful and may even be dangerous to be
used
> if
> people simply use what they get from the pointer.
> 
> Denis
> 
> > To complete the picture it would now be very helpful if you, for
each of
> > these statements, could confirm or explain how these issues are a
result
> > of using the AIA extension in CRLs. Or in other words, which of
these
> > security considerations could you ignore (would go away) if you were
NOT
> > using the AIA extension in a CRL to locate the CRL Issuer
certificate.
> >
> >
> >
> > Stefan Santesson
> > Program Manager, Standards Liaison
> > Windows Security
> >
> >
> >
> >
> 

Date: Thu, 19 May 2005 17:17:34 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Stefan,

> Denis,

> Thanks for the clarification.
> Yes, we agree on issue number 1 (remove SHOULD and MUST)

We also agree on a typo. :-|

> So the remaining issue is:
> 
> Problem: The security considerations talk about "mitigation" of the name
> collision problem but gives inadequate advice.
> 
> Your proposed resolution
> 
>  a) warn the user that the CRL where this extension was found may not be
>     the right one.

The AIA extension in found in a CRL that is not yet checked to be the right one.

>  b) warn the user that the CRL issuer certificate he might obtain using
>     this extension may not be the right one.

The AIA extension does not provide enough information so that the CRL issuer 
  certificate that is found there is indeed the right one, since at this 
time the certification path is not yet formed. There may be a 
man-in-the-middle attack.

>  c) provide guidance on how to GUARANTEE that the CRL Issuer is indeed
>     the one nominated by the CA that has issued the target certificate
>     (i.e. when the CRL Issuer certification path and the target
>     certificate certification path are identical).

This would indeed be a useful guidance given the two above statements.

>  d) say that other possibilities exists, but need additional trust
>     conditions (there are zillions of such possible trust conditions).

This would indeed be a useful guidance given the previous statement.

I am spending a *considerable* time on this issue and I believe that you 
have now perfectly understood what the problem is.

You know that I do not consider the AIA extension useful in the "basic" case.

Since the other cases (the "zillions" of other cases) rely anyway on 
additional local trust conditions, some local configuration values may be 
used to know where to fetch the missing CRL issuer certificates, hence why 
this extension is not really useful and may even be dangerous to be used if 
people simply use what they get from the pointer.

Denis

> To complete the picture it would now be very helpful if you, for each of
> these statements, could confirm or explain how these issues are a result
> of using the AIA extension in CRLs. Or in other words, which of these
> security considerations could you ignore (would go away) if you were NOT
> using the AIA extension in a CRL to locate the CRL Issuer certificate.
> 
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>  
> 
> 
> 

From: <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 17 May 2005 14:15:59 GMT
Subject: RE: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

But, if the asymmetric private key is based on elliptic curves?

Diego

----- Mensaje Original -----
Remitente: "Simon McMahon" [email-masked]
Destinatario: [email-masked], [email-masked]
Fecha: Martes, Mayo 17, 2005  1:03am
Asunto: Re: key usage - key encipherment or data encipherment

>
>The example for 'keyEncipherment' should not include an "RSA public 
>key encrypting an asymmetric private key", which, if it is also RSA 
>is too big to encrypt with the public key. Surely, an RFC shouldn't 
>list impossible cases as examples.
>
>Simon.
>

Content-class: urn:content-classes:message
Subject: Request for new work item - Defining an SRV RR otherName
Date: Wed, 18 May 2005 22:49:32 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

All,

I have just submitted a new personal draft under the name:
draft-santesson-pkix-srvrr-00 and I hope this draft will be available
from the IETF server soon.

With this mail, I request this WG to consider acceptance of this draft
as a PKIX work item.

The purpose of this draft is to facilitate inclusion of a service name
to a X.509 certificate subject in the form of a DNS Service Resource
Record (SRV RR).

The primary immediate need for this draft is to resolve some of the last
hard issues with Kerberos PKINIT which still lack a way to express that
a certificate is issued to a host which act as a kdc server.

The PKINIT draft suggested recently that a SRV RR (_kdc._tcp.realm)
could be placed in a dNSName in SubjectAltName extension, but this would
be incompatible with RFC 3280 definition of dNSName and would cause
issues with name constraints. To fill this void, implementation of
PKINIT will strongly benefit from the definition of a new otherName to
express SRV RR in X.509 certificates.

Since the use of SRV RR is a generic feature, not only relevant to
Kerberos, the proposal is to define this otherName in PKIX.

Below is the introduction and otherName definition pasted from the
submitted draft.

1.  Introduction

   RFC 2782 [N3] Defines a DNS RR (Resource Record) for specifying the
   location of services (SRV RR) which allows clients to ask for a
   specific service/protocol for a specific domain and get back the
   names of any available servers.

   Current defined dNSName GeneralName name forms only provide for DNS
   host names to be expressed in "preferred name syntax," as specified
   by RFC 1034 [N4]. This definition is not broad enough to allow
   expression of a SRV RR. To accommodate expression of a SRV RR in
   X.509 certificates this document therefore defines an otherName for
   SRV RR.

   As DNS query based on an SRV RR returns the name of the host
   currently available for the requested service, reasonable subsequent
   authentication of that host as the appropriate host for the service
   will require the host to demonstrate that it is an authorized to
   provide the requested service.

   The ability to associate a host with a SRV RR in an X.509 certificate
   therefore facilitates the binding of the host to the originally
   requested SRV RR in order to protect against DNS spoofing attacks
   where an altered DNS could return the host name of a rouge or hacked
   host.

   One example where expression of a SRV RR can be very useful is to
   identify a host as a legitimate Kerberos KDC server.

2.  SRV RR otherName

   This section defines the SRVRRName as a form of otherName from the
   GeneralName structure in SubjectAltName.

   The SRVRRName if present MUST contain a Service Resource Record (SRV
   RR) formed according to RFC 2782 [N3].

   The use of a SRVRRName is OPTIONAL. The SRVRRName is defined as
   follows:

      id-on-sRVRRName   OBJECT IDENTIFIER ::= { id-on ? }

      SRVRRName ::= IA5String

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

Subject: Re: EuroPKI 2005 - Call for Participation
To: David Chadwick <[email-masked]>
Cc: PKIX <[email-masked]>
From: [email-masked]
Date: Wed, 18 May 2005 12:40:23 -0600
Sender: [email-masked]

at 8:14 am 5/18/05, [email-masked] wrote:
>
> CALL FOR PARTICIPATION
>
> The EuroPKI 2005 Conference will be held in Canterbury, England, 30 June
> - 1 July 2005.
>
> Registration is now open. See
>
> http://sec.cs.kent.ac.uk/europki2005/registration.shtml
>
> Early registration closes on 1 June, so book now to secure your place.
>
> The Keynote Speech will be given by Dr Carlise Adams, and is entitled
> "PKI: Views from the Dispassionate "I", in which he will present his
> thoughts on why PKI has been available as an authentication technology
> for many years now, but has only enjoyed large-scale success in fairly
> limited contexts to date. He will also present his thoughts on the
> possible future(s) of this technology, with emphasis on the major
> factors hindering adoption and some potential directions for future
> research in these areas.

from 3-factor authentication paradigm
http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* something you know
* something you are

that verification of a digital signature with a public key is a form of
"something you have" authentication ... i.e. the subject has access and use
of the corresponding private key.

note, however, it has seemed that the majority of certification authorities
(mainstay of most formal PKIs) are embroiled in identification issues, not
authentication ... aka the certification binding of some information to a
public key (and the production of the resulting certificate).

i've frequently claimed that this paradigm was disigned to address the
offline email scenario from the early 80s ... where the recipient had
absolutely no recourse to information about an otherwise anomomous sender
that the recipient never had any previous communication with (aka the
letters of credit model from the sailing ship days).

the recipient, dialed their local electronic postoffice, exchanged email,
and then hungup. the recipient then found themself with an email from a
total stranger, there had never been any prior communication, and the
recipient lack any means for discoverying any information about the
stanger.

the early 90s saw x.509 identification certificates. however, there was
some tendency by certification authorities looking at significantly
overload such certificates with enormous amounts of personal information
(not really being able to predict the future about what relying parties
and/or what business processes might be targets for such certificates, and
therefor not reliably being able to predict what relying parties might
expect in the way of identification information).

in the mid-90s some of the institutions (like financial) industry) ...
looking at such identity certificates realized that they represented
enormous privacy and liability issues and you saw some retrenchment to
relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

these certificates frequently contained little more certified information
than some form of account number bound to a public key. however, it was
trivial to show that such reply-party-only certificates not only violated
the original certiicate design point (total stranger communicating for the
first time with a offline relying-party that had no other recourse to
information about the originator), but also were redundant and superfluous
(aka the relying-party having registered the public key and issued the
relying-party-only certificate ... would have a superset of every bit of
information contained in a certificate ... including the public key).

in the financial industry situation ... where the redundant and superfluous
certificates were being targeted at payment transactions ... aka a consumer
would create a payment transaction, digitally signed it and transmit the
transaction, the digital signature, and the reply-party-only certificate
back to the issuing institution. Not only did the relying-party
(destination of the payment transaction) alerady have access to a superset
of the information contained in a redundant and superfluous digital
certificate ... but it turns out that the nominal payment transaction size
is on the order of 60-80 bytes. The typical redundant and superfluous
relying-party-only certificate from the period could be on the order of
4k-12k bytes. So not only were the relying-party-only certificates
redundant and superfluous, but in such situations they also represented a
factor of 100 times payload bloat.

It is actually possible to deploy authentication infrastructures that use
digital signature verification
http://www.garlic.com/~lynn/subpubkey.html#certless

that avoid getting embroiled in the identification issues that seem to
accompany many PKI deployments.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Date: Wed, 18 May 2005 15:14:38 +0100
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: PKIX <[email-masked]>
Subject: EuroPKI 2005 - Call for Participation
Sender: [email-masked]

CALL FOR PARTICIPATION

The EuroPKI 2005 Conference will be held in Canterbury, England, 30 June
- 1 July 2005.

Registration is now open. See

http://sec.cs.kent.ac.uk/europki2005/registration.shtml

Early registration closes on 1 June, so book now to secure your place.

The Keynote Speech will be given by Dr Carlise Adams, and is entitled
"PKI: Views from the Dispassionate "I", in which he will present his
thoughts on why PKI has been available as an authentication technology
for many years now, but has only enjoyed large-scale success in fairly
limited contexts to date. He will also present his thoughts on the
possible future(s) of this technology, with emphasis on the major
factors hindering adoption and some potential directions for future
research in these areas.

The Programme will have sessions on: authorization, risks/attacks to PKI
systems, interoperability between systems, evaluating a CA, ID ring
based signatures, new protocols, practical implementations and long term
archiving.

The full programme can be seen at

http://sec.cs.kent.ac.uk/europki2005/programme.shtml

The Conference Banquet will take place in the historic Dover Castle and
will be preceeded by a trip around the labyrinth of tunnels holding
World War Two archives where Winston Churchill did must of his war time
planning

http://www.plus44.com/heritage/dover/dovercast.htm

I look forward to meeting you there

David Chadwick

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 1484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Improving PKCS#11
Cc: [email-masked], [email-masked]
Date: Wed, 18 May 2005 18:12:51 +1200
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>The purpose is to make impossible, whatever the user application asks, to
>extract the private key in the clear.

Since the flags are ultimately controlled by the user app (no matter what you
call them or where you put them), the user app is *always* going to get the
key if it really wants it.  The only thing that'll stop it is if the hardware
prevents this (see below).

>> If the hardware makes
>> it unextractable (e.g. in Fortezza cards), it'll implicitly set
>> CKA_EXTRACTABLE for you.
>
>The hardware cannot do anything since currently the setting of the flag
>CKA_EXTRACTABLE is left to the application.

That's merely a request from the software side.  A Fortezza card isn't going
to give you the key, no matter what you set CKA_EXTRACTABLE to.  Conversely, a
Cryptoflex (at least the older ones) will always give you the key because it
only contains a private-key engine (you can't even do public-key encryption
with it).  So if you try and set the flag in a way that isn't supported by the
hardware, you'll get a template-inconsistent error (or you may get the object
created but with the template modified according to the hardware capabilities,
depending on the implementation).  Ultimately, the crypto hardware gets the
last word, not an application-set flag.  Unlike PKIX, the PKCS #11 folks are
somewhat reluctant to set standards requirements that violate the laws of
physics.

>I do not think so: the purpose is not to modify any existing command, but to
>add only ONE new one which might be called something like:
>
>C_UnwrapKeyCkaExtractableFalse
>
>where the certificate used to perform the operation would have a key usage
>like: keyEnciphermentNoExtract. This means that the "cryptographic material",
>once decrypted, cannot be extracted.

But again, this depends *entirely* on the calling software.  It doesn't matter
how you dress this up, if the calling app wants the key, all it has to do is
call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse, or set
CKA_EXTRACTABLE to true in the template for C_UnwrapKey, or whatever.  If the
calling app wants to it can look at the cert, see that keyEncipherment is set
to true and dataEncipherment false, and then go ahead and set CKA_EXTRACTABLE
to true or call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse.  There
is therefore no difference between C_UnwrapKeyCkaExtractableFalse and
C_UnwrapKey with CKA_EXTRACTABLE set to false.

Peter.

Date: Wed, 18 May 2005 09:56:46 +1000
From: "Simon McMahon" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Improving PKCS#11
Sender: [email-masked]

Denis,

This discussion belongs on the PKCS11 list.

> C_UnwrapKeyCkaExtractableFalse

This adds nothing that isn't already in PKCS11 since the app still has to choose to call this function. Having spent many years in that working group I also know that adding top level functions is usually a last resort for any new feature.

The intent appears to be to map certificate key-usage attributes, for the public key, into PKCS11 key attributes of the private key and make the PKCS11 library do it. Regardless of whether it is appropriate to do that, this is just a new C_Unwrap mechanism and they can be defined in the 'vendor defined' space so this problem already has a solution - or at least a way to do it. If no-one has written such a mechanism then they probably already solved this problem another way. If they have then that mechanism can be promoted to one of the standard mechanisms.

Simon.

Simon McMahon

Work: (07) 31311420
Mobile: (043) 2294180

>>> Denis Pinkas <[email-masked]> 05/17/05 10:26pm >>>

Peter,

>>If PKCS#11 gets improved, then we could distinguish between:

>>  keyEncipherment-no-extract      :  CKA_UNWRAP_CKA_EXTRACTABLE_FALSE
>>  keyEncipherment-extract-allowed :  CKA_UNWRAP_CKA_EXTRACTABLE_TRUE

> I can't see that ever being added.  If you want to make it unextractable in
> the user app, 

No. The purpose is to make impossible, whatever the user application asks, to extract the private key in the clear.

> set the CKA_EXTRACTABLE flag in the key template to false (this
> is the same as using CKA_UNWRAP_CKA_EXTRACTABLE_FALSE).  If the hardware makes
> it unextractable (e.g. in Fortezza cards), it'll implicitly set
> CKA_EXTRACTABLE for you.

The hardware cannot do anything since currently the setting of the flag 
CKA_EXTRACTABLE is left to the application.

> There are also practical considerations.  The reason for the common use of
> DECRYPT/UNWRAP duality is for compatibility with existing drivers and usage,
> what'd you'd be asking there is for app developers to break compatibility with
> all existing drivers in exchange for a gain so abstruse that most of them
> won't even understand why it's there.  

I do not think so: the purpose is not to modify any existing command, but to 
add only ONE new one which might be called something like:

C_UnwrapKeyCkaExtractableFalse

where the certificate used to perform the operation would have a key usage like: keyEnciphermentNoExtract. This means that the "cryptographic 
material", once decrypted, cannot be extracted.

So there would be no backward compatibility problem.

> An addition, given the longevity of
> crypto hardware devices, even if vendors (for some reason) decided to do this,
> it'd take years for everything to implement it.  

Yes, this may take years, but since this is fairly simple, it might only 
take only a couple of years.  :-)

> Finally, some hardware (e.g.
> many smart cards) can't support this, since all the card can usefully do is
> the private-key op.  

This would apply to new smart cards only.

> As a result the unwrapped key is always extractable from the card, 

Yes, this is the current situation, and hence why we should change it.

Denis

> either because it doesn't do symmetric crypto at all, because it
> does it in a crippled manner that makes it useless (e.g. it zeroes all but 40
> bits of a 56-bit DES key, it only allows the use of a fixed key, etc etc), or
> even if it does do symmetric crypto, it's so slow that it's unusable.  So
> CKA_EXTRACTABLE is at best advisory from the user's point of view, and can be
> overridden by the hardware.
> 
> Peter.
> 
> 

***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************

Date: Tue, 17 May 2005 18:22:46 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

Russ Housley wrote:
> 
> There has been a whole lot of discussion about these paragraphs.  Since
> some of the discussion has not been CCed to the PKIX mail list, I am
> posting the resulting words.

Since this discussions started by providing examples how about adding a
short example section for demonstrating the appropriate usage of these bits?

Ciao, Michael.

Date: Tue, 17 May 2005 13:06:17 -0400
To: Sam Hartman <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: Progressing 3770bis
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Sam,

The PKIX WG has achieved rough consensus on 3770bis, "Certificate 
Extensions and Attributes Supporting Authentication in Point-to-Point 
Protocol (PPP) and Wireless Local Area Networks (WLAN)".  This document is 
ready for progression, and upon approval will obsolete RFC 3770.  As with 
its predecessor, we are recommending progression as standards track 
document.  (The document should cycle at Proposed Standard.)

The current draft is available at

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

Thanks,

Tim Polk

Date: Tue, 17 May 2005 14:26:56 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Improving PKCS#11
Sender: [email-masked]

Peter,

>>If PKCS#11 gets improved, then we could distinguish between:

>>  keyEncipherment-no-extract      :  CKA_UNWRAP_CKA_EXTRACTABLE_FALSE
>>  keyEncipherment-extract-allowed :  CKA_UNWRAP_CKA_EXTRACTABLE_TRUE

> I can't see that ever being added.  If you want to make it unextractable in
> the user app, 

No. The purpose is to make impossible, whatever the user application asks, 
to extract the private key in the clear.

> set the CKA_EXTRACTABLE flag in the key template to false (this
> is the same as using CKA_UNWRAP_CKA_EXTRACTABLE_FALSE).  If the hardware makes
> it unextractable (e.g. in Fortezza cards), it'll implicitly set
> CKA_EXTRACTABLE for you.

The hardware cannot do anything since currently the setting of the flag 
CKA_EXTRACTABLE is left to the application.

> There are also practical considerations.  The reason for the common use of
> DECRYPT/UNWRAP duality is for compatibility with existing drivers and usage,
> what'd you'd be asking there is for app developers to break compatibility with
> all existing drivers in exchange for a gain so abstruse that most of them
> won't even understand why it's there.  

I do not think so: the purpose is not to modify any existing command, but to 
add only ONE new one which might be called something like:

C_UnwrapKeyCkaExtractableFalse

where the certificate used to perform the operation would have a key usage 
like: keyEnciphermentNoExtract. This means that the "cryptographic 
material", once decrypted, cannot be extracted.

So there would be no backward compatibility problem.

> An addition, given the longevity of
> crypto hardware devices, even if vendors (for some reason) decided to do this,
> it'd take years for everything to implement it.  

Yes, this may take years, but since this is fairly simple, it might only 
take only a couple of years.  :-)

> Finally, some hardware (e.g.
> many smart cards) can't support this, since all the card can usefully do is
> the private-key op.  

This would apply to new smart cards only.

> As a result the unwrapped key is always extractable from the card, 

Yes, this is the current situation, and hence why we should change it.

Denis

> either because it doesn't do symmetric crypto at all, because it
> does it in a crippled manner that makes it useless (e.g. it zeroes all but 40
> bits of a 56-bit DES key, it only allows the use of a fixed key, etc etc), or
> even if it does do symmetric crypto, it's so slow that it's unusable.  So
> CKA_EXTRACTABLE is at best advisory from the user's point of view, and can be
> overridden by the hardware.
> 
> Peter.
> 
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Improving PKCS#11
Cc: [email-masked], [email-masked]
Date: Tue, 17 May 2005 21:32:06 +1200
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>If PKCS#11 gets improved, then we could distinguish between:
>
>   keyEncipherment-no-extract      :  CKA_UNWRAP_CKA_EXTRACTABLE_FALSE
>   keyEncipherment-extract-allowed :  CKA_UNWRAP_CKA_EXTRACTABLE_TRUE

I can't see that ever being added.  If you want to make it unextractable in
the user app, set the CKA_EXTRACTABLE flag in the key template to false (this
is the same as using CKA_UNWRAP_CKA_EXTRACTABLE_FALSE).  If the hardware makes
it unextractable (e.g. in Fortezza cards), it'll implicitly set
CKA_EXTRACTABLE for you.

There are also practical considerations.  The reason for the common use of
DECRYPT/UNWRAP duality is for compatibility with existing drivers and usage,
what'd you'd be asking there is for app developers to break compatibility with
all existing drivers in exchange for a gain so abstruse that most of them
won't even understand why it's there.  An addition, given the longevity of
crypto hardware devices, even if vendors (for some reason) decided to do this,
it'd take years for everything to implement it.  Finally, some hardware (e.g.
many smart cards) can't support this, since all the card can usefully do is
the private-key op.  As a result the unwrapped key is always extractable from
the card, either because it doesn't do symmetric crypto at all, because it
does it in a crippled manner that makes it useless (e.g. it zeroes all but 40
bits of a 56-bit DES key, it only allows the use of a fixed key, etc etc), or
even if it does do symmetric crypto, it's so slow that it's unusable.  So
CKA_EXTRACTABLE is at best advisory from the user's point of view, and can be
overridden by the hardware.

Peter.

Date: Tue, 17 May 2005 10:46:17 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stephen Kent <[email-masked]>
CC: [email-masked], Burt Kaliski <[email-masked]>
Subject: Improving PKCS#11
Sender: [email-masked]

Steve (and Burt),

I concur with you and Peter that PKCS#11 is not currently enforcing an 
appropriate key protection against key extraction, but this could be easily 
improved.

Maybe RSA Security would like to improve PKCS#11 ?

If PKCS#11 gets improved, then we could distinguish between:

   keyEncipherment-no-extract      :  CKA_UNWRAP_CKA_EXTRACTABLE_FALSE
   keyEncipherment-extract-allowed :  CKA_UNWRAP_CKA_EXTRACTABLE_TRUE

Denis

> At 6:21 PM +0200 5/13/05, Denis Pinkas wrote:
> 
>> Steve,
>>
>> I wished that what you say would be true, however it isn't. See below.
>>
>>> At 8:41 AM -0600 5/13/05, Bob Bell wrote:
>>
>>
>>>> Stephen -
>>>
>>
>>>> Just a question for clarification. Since these bits are located in the
>>>> certificate. How does that translate into knowing without knowledge 
>>>> based on
>>>> the actual data structure itself that the data encrypted is keying 
>>>> material
>>>> or data. It would seem to me that the contextual information based 
>>>> on the
>>>> information exchange is more the determiner of what is intended. The 
>>>> bits in
>>>> the certificate are to indicate if it is acceptable to use the 
>>>> public key
>>>> for the stated purpose. At least that is my understanding. If I am 
>>>> wrong,
>>>> please educate me.
>>>
>>
>>>> Bob Bell
>>>
>>
>>> Bob,
>>
>>
>>> I can implement crypto software that never releases the bytes 
>>> decrypted with a private key that appears in a cert which has enabled 
>>> the "keyEncipherment" but not "dataEncipherment" key usage bits. The 
>>> intent is that a peer should never have used the public key to 
>>> encrypt anything but key (or key and associated control info) bits, 
>>> given the marking. In contrast, if the bytes I receive and decrypt 
>>> were encrypted using a public key from a cert that has enabled the 
>>> "dataEncipherment" key usage bit but not the "keyEncipherment" bit, 
>>> then I would expect to hand these bits to an app, and that would be 
>>> bad if they were really key bits.
>>
>>
>> At this time someone who uses a certificate that has the key usage 
>> keyEncipherment set cannot know whether the "keying material" can be 
>> released or not by the receiving application (that owns the private key).
> 
> 
> that's true.
> 
>> Let us look what PKCS#11 states about the mapping of X.509 key usage
>> flags to cryptoki attributes for private keys for CKA_DECRYPT and 
>> CKA_UNWRAP:
>>
>> Table 35, Mapping of X.509 key usage flags to cryptoki attributes
>> for private keys
>>
>> Key usage flags for public keys    Corresponding cryptoki attributes
>> in X.509 public key certificates   for private keys
>>
>> dataEncipherment                           CKA_DECRYPT
>> keyAgreement                               CKA_DERIVE
>> keyEncipherment                            CKA_UNWRAP
>>
>> C_UnwrapKey unwraps (i.e. decrypts) a wrapped key, creating a new private
>> key or secret key object.
>>
>> The CKA_UNWRAP attribute of the unwrapping key, which indicates whether
>> the key supports unwrapping, must be TRUE. The new key will have the
>> CKA_ALWAYS_SENSITIVE attribute set to FALSE, and the 
>> CKA_NEVER_EXTRACTABLE
>> attribute set to FALSE. The CKA_EXTRACTABLE attribute is by default 
>> set to
>> TRUE.
>>
>>   It would be "nice" to be able to distinguish between C_UnwrapKey where
>>   the secret cannot be extractable and where it can be.
>>
>>   We would then be able to distinguish between:
>>
>>   keyEncipherment-no-extract      :  CKA_UNWRAP_CKA_EXTRACTABLE_FALSE
>>   keyEncipherment-extract-allowed :  CKA_UNWRAP_CKA_EXTRACTABLE_TRUE
>>
>>   I would thus propose to be able to support that distinction.
> 
> 
> yes, this distinction would be nice, but Peter's messages suggests that 
> PKCS #11 code does not really pay much attention to the key usage bits 
> anyway. so, it does not seem worht pursuing.
> 
> Steve
> 
> 
> 

From: <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 17 May 2005 07:42:24 GMT
Subject: RE: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

----- Mensaje Original -----
Remitente: "Simon McMahon" [email-masked]
Destinatario: [email-masked], [email-masked]
Fecha: Martes, Mayo 17, 2005  1:03am
Asunto: Re: key usage - key encipherment or data encipherment

>
>The example for 'keyEncipherment' should not include an "RSA public 
>key encrypting an asymmetric private key", which, if it is also RSA 
>is too big to encrypt with the public key. Surely, an RFC shouldn't 
>list impossible cases as examples.
>

Date: Tue, 17 May 2005 09:03:05 +1000
From: "Simon McMahon" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

The example for 'keyEncipherment' should not include an "RSA public key encrypting an asymmetric private key", which, if it is also RSA is too big to encrypt with the public key. Surely, an RFC shouldn't list impossible cases as examples.

Simon.

Simon McMahon

Work: (07) 31311420
Mobile: (043) 2294180

>>> Russ Housley <[email-masked]> 05/13/05 05:21am >>>

There has been a whole lot of discussion about these paragraphs.  Since 
some of the discussion has not been CCed to the PKIX mail list, I am 
posting the resulting words.

      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering private or secret keys, i.e., for key transport.
      For example, this bit shall be set when a RSA public key is to be
      used for encrypting a symmetric content-decryption key or an
      asymmetric private key.

     The dataEncipherment bit is asserted when the subject public key
     is used for directly enciphering raw user data without the use of
     an intermediate symmetric cipher. Note that the use of this
     bit is extremely uncommon; almost all applications use
     key transport or key agreement to establish a symmetric key.

I hope we a re close to closure on this one....

Russ

***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************

Date: Mon, 16 May 2005 17:58:00 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Cc: [email-masked]
Sender: [email-masked]

At 6:21 PM +0200 5/13/05, Denis Pinkas wrote:
>Steve,
>
>I wished that what you say would be true, however it isn't. See below.
>
>>At 8:41 AM -0600 5/13/05, Bob Bell wrote:
>
>>>Stephen -
>
>>>Just a question for clarification. Since these bits are located in the
>>>certificate. How does that translate into knowing without knowledge based on
>>>the actual data structure itself that the data encrypted is keying material
>>>or data. It would seem to me that the contextual information based on the
>>>information exchange is more the determiner of what is intended. The bits in
>>>the certificate are to indicate if it is acceptable to use the public key
>>>for the stated purpose. At least that is my understanding. If I am wrong,
>>>please educate me.
>
>>>Bob Bell
>
>>Bob,
>
>>I can implement crypto software that never releases the bytes 
>>decrypted with a private key that appears in a cert which has 
>>enabled the "keyEncipherment" but not "dataEncipherment" key usage 
>>bits. The intent is that a peer should never have used the public 
>>key to encrypt anything but key (or key and associated control 
>>info) bits, given the marking. In contrast, if the bytes I receive 
>>and decrypt were encrypted using a public key from a cert that has 
>>enabled the "dataEncipherment" key usage bit but not the 
>>"keyEncipherment" bit, then I would expect to hand these bits to an 
>>app, and that would be bad if they were really key bits.
>
>At this time someone who uses a certificate that has the key usage 
>keyEncipherment set cannot know whether the "keying material" can be 
>released or not by the receiving application (that owns the private 
>key).

that's true.

>Let us look what PKCS#11 states about the mapping of X.509 key usage
>flags to cryptoki attributes for private keys for CKA_DECRYPT and CKA_UNWRAP:
>
>Table 35, Mapping of X.509 key usage flags to cryptoki attributes
>for private keys
>
>Key usage flags for public keys    Corresponding cryptoki attributes
>in X.509 public key certificates   for private keys
>
>dataEncipherment                           CKA_DECRYPT
>keyAgreement                               CKA_DERIVE
>keyEncipherment                            CKA_UNWRAP
>
>C_UnwrapKey unwraps (i.e. decrypts) a wrapped key, creating a new private
>key or secret key object.
>
>The CKA_UNWRAP attribute of the unwrapping key, which indicates whether
>the key supports unwrapping, must be TRUE. The new key will have the
>CKA_ALWAYS_SENSITIVE attribute set to FALSE, and the CKA_NEVER_EXTRACTABLE
>attribute set to FALSE. The CKA_EXTRACTABLE attribute is by default set to
>TRUE.
>
>   It would be "nice" to be able to distinguish between C_UnwrapKey where
>   the secret cannot be extractable and where it can be.
>
>   We would then be able to distinguish between:
>
>   keyEncipherment-no-extract      :  CKA_UNWRAP_CKA_EXTRACTABLE_FALSE
>   keyEncipherment-extract-allowed :  CKA_UNWRAP_CKA_EXTRACTABLE_TRUE
>
>   I would thus propose to be able to support that distinction.

yes, this distinction would be nice, but Peter's messages suggests 
that PKCS #11 code does not really pay much attention to the key 
usage bits anyway. so, it does not seem worht pursuing.

Steve

To: "Santosh Chokhani" <[email-masked]>
Cc: "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: key usage - key encipherment or data encipherment
From: Tom Gindin <[email-masked]>
Date: Mon, 16 May 2005 13:26:26 -0400
Sender: [email-masked]

        It should probably just be "without the use of any symmetric 
cipher", instead of wondering whether it's intermediate or not.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
05/16/2005 11:13 AM
 
        To:     "'Russ Housley'" <[email-masked]>, 
<[email-masked]>
        cc: 
        Subject:        RE: key usage - key encipherment or data 
encipherment

Russ,

Looks good except the "intermediate symmetric cipher" in the last 
paragraph
should be "symmetric cipher" since the symmetric cipher in most cases in 
not
"intermediate".  Another alternative is to use the term "intermediate
asymmetric cipher", but that might be confusing.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Russ Housley
Sent: Thursday, May 12, 2005 3:21 PM
To: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment

There has been a whole lot of discussion about these paragraphs.  Since 
some of the discussion has not been CCed to the PKIX mail list, I am 
posting the resulting words.

      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering private or secret keys, i.e., for key 
transport.
      For example, this bit shall be set when a RSA public key is to be
      used for encrypting a symmetric content-decryption key or an
      asymmetric private key.

     The dataEncipherment bit is asserted when the subject public key
     is used for directly enciphering raw user data without the use of
     an intermediate symmetric cipher. Note that the use of this
     bit is extremely uncommon; almost all applications use
     key transport or key agreement to establish a symmetric key.

I hope we a re close to closure on this one....

Russ

From: "Santosh Chokhani" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: RE: key usage - key encipherment or data encipherment
Date: Mon, 16 May 2005 11:13:41 -0400
Importance: Normal
Sender: [email-masked]

Russ,

Looks good except the "intermediate symmetric cipher" in the last paragraph
should be "symmetric cipher" since the symmetric cipher in most cases in not
"intermediate".  Another alternative is to use the term "intermediate
asymmetric cipher", but that might be confusing.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ Housley
Sent: Thursday, May 12, 2005 3:21 PM
To: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment

There has been a whole lot of discussion about these paragraphs.  Since 
some of the discussion has not been CCed to the PKIX mail list, I am 
posting the resulting words.

      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering private or secret keys, i.e., for key transport.
      For example, this bit shall be set when a RSA public key is to be
      used for encrypting a symmetric content-decryption key or an
      asymmetric private key.

     The dataEncipherment bit is asserted when the subject public key
     is used for directly enciphering raw user data without the use of
     an intermediate symmetric cipher. Note that the use of this
     bit is extremely uncommon; almost all applications use
     key transport or key agreement to establish a symmetric key.

I hope we a re close to closure on this one....

Russ

Date: Thu, 12 May 2005 15:21:02 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

There has been a whole lot of discussion about these paragraphs.  Since 
some of the discussion has not been CCed to the PKIX mail list, I am 
posting the resulting words.

      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering private or secret keys, i.e., for key transport.
      For example, this bit shall be set when a RSA public key is to be
      used for encrypting a symmetric content-decryption key or an
      asymmetric private key.

     The dataEncipherment bit is asserted when the subject public key
     is used for directly enciphering raw user data without the use of
     an intermediate symmetric cipher. Note that the use of this
     bit is extremely uncommon; almost all applications use
     key transport or key agreement to establish a symmetric key.

I hope we a re close to closure on this one....

Russ

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Cc: [email-masked]
Date: Mon, 16 May 2005 18:55:16 +1200
Sender: [email-masked]

Russ Housley <[email-masked]> writes:

>This would be quite a change from the current meaning of the bits, not a
>clarification.

Well, it would change the current text describing the bits, but not the way
the bits are being used in practice.  In other words the changed text would
then match the way the bits are actually being used.  It'd resolve the
ambiguity and fix the current problem in a single step.

Peter.

Date: Mon, 16 May 2005 10:25:01 +1000
From: "Simon McMahon" <[email-masked]>
To: "<\"Wen-Cheng Wang\""<[email-masked]>
Cc: "<"<[email-masked]>
Subject: RE: key usage - key encipherment or data encipherment
Sender: [email-masked]

Wen-Cheng Wang's last post looks OK to me but I would drop "RSA" and "content-decryption" from the example. I still don't see how an RSA public key can directly encrypt a private key, unless its heaps smaller, so I dropped that from the example too. 'Private' keys are also 'secret' keys anyway. I didn't change 'dataEncipherment' from Wang's post.

proposed text:
      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering cryptographic keys or keying materials.
      For example, this bit shall be set when a RSA public key is to be
      used for key transport that involves encrypting a secret key.
 
     The dataEncipherment bit is asserted when the subject public key
     is used for directly enciphering raw user data, other than cryptographic
     keys or keying materials, without the use of an intermediate symmetric
     cipher. Note that the use of this bit is extremely uncommon; almost all
     applications use key transport or key agreement to establish shared
     cryptographic keys.

The 'note' at the end of dataEncipherment effectively deprecates this bit but I'm sure it will continue to see many more interoperability issues in the future.

I think that Peter's observation:
  keyEncipherment = ephemeral session key establishment (e.g. SSL).
  dataEncipherment = content-encryption key establishment (e.g. S/MIME).
Is what industry will continue to do regardless of the RFC text since a bit that is there with no obvious use may as well get used for something.

The 'PIN' reference from another post was another good grey area that can justify the use of either bit however the RFC gets worded.

The overloading of the bits to imply security policy for the private key's decryption op is the riskiest use of these bits but will obviously continue too.

The bits, as defined by the RFC, obviously don't matter very much to PKI security which is why no-one could nail down what they actually mean and industry usage varies so widely. They are just an interoperability issue waiting to happen (again).

Simon McMahon.

Simon McMahon

Work: (07) 31311420
Mobile: (043) 2294180

***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************

Date: Sun, 15 May 2005 15:16:12 -0400
To: [email-masked] (Peter Gutmann), [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Cc: [email-masked]
Sender: [email-masked]

Peter:

This would be quite a change from the current meaning of the bits, not a 
clarification.  I do not support such a change.

Russ

At 04:05 AM 5/15/2005, Peter Gutmann wrote:
>"Simon McMahon" <[email-masked]> writes:
>
> >They were calling an 'encrypt' function to encrypt XML data and they gave it
> >an RSA key (the cert actually) to do it. Of course it internally made an AES
> >key but they never saw it until the interoperability issue made them look.
> >From what they saw at the level they were looking the interpretation was
> >reasonable.
>
>When I originally saw your posting I thought that what they were doing was a
>typical clueless-user action, but on thinking about it a bit more it's
>actually quite logical.  Unless you're intimately familiar with the crypto
>involved, it's quite sensible to use dataEncryption to mean, well, data
>encryption (in the way you describe above).
>
> >In my opinion there are 3 cases presented as 2 in the RFC.
> >
> >1. RSA encrypts data - hardly ever used.
> >2. RSA implicitly encrypts keys so it can really encrypt bulk data - common
> >   usage.
> >3. RSA explicitly encrypts keys for explicit key management functions -
> >   common usage.
> >
> >The current bits separate 1 from 2/3 yet people make the interpretation that
> >they split the more common 2 from 3 assuming 1 and 2 are the same thing.
>
>Yup.  It's like the old digitalSignature vs. nonRepudiation bits, no-one could
>actually clearly define what nonRepudiation did, which is why it was changed
>to the current contentCommitment.  So now we have:
>
>   digitalSignature = ephemeral signatures (e.g. for authentication to an
>                      online server).
>
>   nonRepudiation = long-term signature (e.g. for document signatures).
>
>The logical corollary from this is to set:
>
>   keyEncipherment = ephemeral session key establishment (e.g. SSL).
>
>   dataEncipherment = content-encryption key establishment (e.g. S/MIME).
>
>Since everyone that's using dataEncipherment is using it for that anyway, it
>clarifies the situation and requires no change in existing apps.
>
>(As for real raw data-encipherment, if anyone is actually using that, give
>  them a new flag contentEncapsulation or something with a name that can't be
>  confused with anything else).
>
> >In my opinion this problem will not entirely go away by clarifying the
> >standard because most people dont read it before they implement something.
> >The two bits are there and as long as they are both there then the mistake
> >will be made by busy developers. Unenforceable key-usage policy, to "public"
> >keys, will also continue to be implemented. People will come looking for
> >clarification once they have an interoperability issue but by then it is
> >often too late - the issue usually gets decided by who has the biggest
> >corporate balls. In this case it wasn't too late so thanks for the
> >assistance.
>
>Yup, that's a perfect summary of the current situation.  I don't know if I'm
>too happy with combining the bits, the crypto-purist in me wants to keep a
>distinction between SSL vs. S/MIME-type keys for access control purposes, but
>the practical part of me says this will never work, because there's no way for
>a user (even if they do know the difference in key types, which very few do)
>to be able to manage this in any way via a crypto API.
>
>The standard crypto API has some form of "gimme a key" function that returns a
>key for a particular user.  Some of the more sophisticated ones extend this to
>"gimme a key usable for encryption" (although the best known, CryptoAPI,
>allows you to use an encryption-only key for signatures because so many users
>can't understand anything other than a one-size-fits-all key).  None that I'm
>aware of (and I've used quite a few) allow you to specify the usage of a key
>for short-term but not long-term signatures, or session vs. data-encryption
>key management.  The only thing they understand is "sign" and "encrypt".  So
>even if you clarify keyEncipherment and dataEncipherment, there's no way to
>manage the usage in any known CryptoAPI.
>
>The best the crypto software vendor can do at that point is to leave it to the
>end user to check that when they call "encrypt" to encrypt an ephemeral key,
>the associated cert isn't set up to only encrypt a content-encryption key.
>I'll leave readers to decide what the chances are of that ever working.
>
>Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Cc: [email-masked]
Date: Sun, 15 May 2005 20:27:53 +1200
Sender: [email-masked]

Denis Pinkas <[email-masked]> writes:

>Let us look what PKCS#11 states about the mapping of X.509 key usage flags to
>cryptoki attributes for private keys for CKA_DECRYPT and CKA_UNWRAP:

Note that this usage is entirely dependent on the user.  PKCS #11 sets no
constraints based on the cert contents.  Experience has shown that the PKCS
#11 flags set by the user often bear no relation to the key flags in the cert,
with keys with signature-only certs being usable for encryption and vice
versa.  It's not small-scale stuff either, this sort of thing goes all the way
up to the European national-CA level (this isn't a purely European disease,
but smart cards seem to be a lot more widely used over there, so it's more
noticeable).

>Key usage flags for public keys    Corresponding cryptoki attributes in X.509
>public key certificates for private keys
>
>dataEncipherment                           CKA_DECRYPT
>keyAgreement                               CKA_DERIVE
>keyEncipherment                            CKA_UNWRAP

Even that is merely theoretical guidance, since there's a lot of confusion
between decryption and unwrapping keys - some apps mark keys as being for
decryption and some for unwrapping.  What you do is you try a decrypt first,
and if that fails you try an unwrap with a CKO_SECRET_KEY of type
CKK_GENERIC_SECRET, which returns the entire decrypted value, making the
unwrap equivalent to a straight decrypt.

So even here where you've got provision for key-wrap vs. data-encrypt, (a)
it's frequently not mapped from the certificate to the PKCS #11 level and (b)
even if it were, it's common practice to apply both operations in a manner
that makes them equivalent, in order to handle with the way existing apps do
things.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Cc: [email-masked]
Date: Sun, 15 May 2005 20:06:30 +1200
Sender: [email-masked]

"Wen-Cheng Wang" <[email-masked]> writes:

>However, I worried that the statement "This (dataEncipherment) bit MUST NOT
>be set when the intention is to encipher intermediate cryptographic keys
>rather than raw user data" might mislead the reader to believe that the
>keyEncipherment bit and the dataEncipherment bit are mutually exclusive.
>Therefore, I suggest to revise the statement as "The dataEncipherment bit
>should not be use to represent the intention of allowing enciphering
>intermediate cryptographic keys. In that case, the keyEncipherment bit should
>be set."

Thanks, that change helps clarify the text.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Cc: [email-masked]
Date: Sun, 15 May 2005 20:05:20 +1200
Sender: [email-masked]

"Simon McMahon" <[email-masked]> writes:

>They were calling an 'encrypt' function to encrypt XML data and they gave it
>an RSA key (the cert actually) to do it. Of course it internally made an AES
>key but they never saw it until the interoperability issue made them look.
>From what they saw at the level they were looking the interpretation was
>reasonable.

When I originally saw your posting I thought that what they were doing was a
typical clueless-user action, but on thinking about it a bit more it's
actually quite logical.  Unless you're intimately familiar with the crypto
involved, it's quite sensible to use dataEncryption to mean, well, data
encryption (in the way you describe above).

>In my opinion there are 3 cases presented as 2 in the RFC.
>
>1. RSA encrypts data - hardly ever used.
>2. RSA implicitly encrypts keys so it can really encrypt bulk data - common
>   usage.
>3. RSA explicitly encrypts keys for explicit key management functions -
>   common usage.
>
>The current bits separate 1 from 2/3 yet people make the interpretation that
>they split the more common 2 from 3 assuming 1 and 2 are the same thing.

Yup.  It's like the old digitalSignature vs. nonRepudiation bits, no-one could
actually clearly define what nonRepudiation did, which is why it was changed
to the current contentCommitment.  So now we have:

  digitalSignature = ephemeral signatures (e.g. for authentication to an
                     online server).

  nonRepudiation = long-term signature (e.g. for document signatures).

The logical corollary from this is to set:

  keyEncipherment = ephemeral session key establishment (e.g. SSL).

  dataEncipherment = content-encryption key establishment (e.g. S/MIME).

Since everyone that's using dataEncipherment is using it for that anyway, it
clarifies the situation and requires no change in existing apps.

(As for real raw data-encipherment, if anyone is actually using that, give
 them a new flag contentEncapsulation or something with a name that can't be
 confused with anything else).

>In my opinion this problem will not entirely go away by clarifying the
>standard because most people dont read it before they implement something.
>The two bits are there and as long as they are both there then the mistake
>will be made by busy developers. Unenforceable key-usage policy, to "public"
>keys, will also continue to be implemented. People will come looking for
>clarification once they have an interoperability issue but by then it is
>often too late - the issue usually gets decided by who has the biggest
>corporate balls. In this case it wasn't too late so thanks for the
>assistance.

Yup, that's a perfect summary of the current situation.  I don't know if I'm
too happy with combining the bits, the crypto-purist in me wants to keep a
distinction between SSL vs. S/MIME-type keys for access control purposes, but
the practical part of me says this will never work, because there's no way for
a user (even if they do know the difference in key types, which very few do)
to be able to manage this in any way via a crypto API.

The standard crypto API has some form of "gimme a key" function that returns a
key for a particular user.  Some of the more sophisticated ones extend this to
"gimme a key usable for encryption" (although the best known, CryptoAPI,
allows you to use an encryption-only key for signatures because so many users
can't understand anything other than a one-size-fits-all key).  None that I'm
aware of (and I've used quite a few) allow you to specify the usage of a key
for short-term but not long-term signatures, or session vs. data-encryption
key management.  The only thing they understand is "sign" and "encrypt".  So
even if you clarify keyEncipherment and dataEncipherment, there's no way to
manage the usage in any known CryptoAPI.

The best the crypto software vendor can do at that point is to leave it to the
end user to check that when they call "encrypt" to encrypt an ephemeral key,
the associated cert isn't set up to only encrypt a content-encryption key.
I'll leave readers to decide what the chances are of that ever working.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: key usage - key encipherment or data encipherment
Date: Sun, 15 May 2005 17:39:03 +1200
Sender: [email-masked]

"Miguel A Rodriguez" <[email-masked]> writes:

>Does anyone use dataEncipherment?

That depends on which question you're asking.  Lots of people use
dataEncipherment, but I've never found anyone who uses dataEncipherment the
way it's meant to be used (whenever I see it used I try and find out from the
original user what they're doing with it.  It's never for the X.509 definition
of dataEncipherment).  So the answer is both yes and no.

Peter.

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: key usage - key encipherment or data encipherment
Date: Fri, 13 May 2005 18:49:17 -0700
Importance: Normal
Sender: [email-masked]

I concur with Steve's observation.  The potential utility outweighs
current deficiencies.

Mike

-----Original Message-----
From: Stephen Kent
Sent: Friday, May 13, 2005 6:33 AM
>
> . . .
>
> I am hesitant to have us remove this potentially
> useful distinction merely because folks have not
> been smart enough to make good use of it so far.
>
> Steve

Date: Fri, 13 May 2005 15:34:56 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Cc: [email-masked]
Sender: [email-masked]

Denis:

>The distinction between "the CRL" and "a CRL" is pretty important.

So we have identified another are where we disagree.  The CRL AIA extension 
applies to a CRL that the certificate user has already selected.

Russ 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: key usage - key encipherment or data encipherment
Date: Fri, 13 May 2005 13:38:08 -0400
Importance: Normal
Sender: [email-masked]

To add to what Steve Kent has said in this e-mail, there is a separate bit
for D-H type protocols.  It is called keyAgreement.

I also agree with Steve's other posting of maintaining the distinction
between key encihperment and data encipherment.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Friday, May 13, 2005 10:15 AM
To: Wen-Cheng Wang
Cc: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment

At 5:48 PM +0800 5/13/05, Wen-Cheng Wang wrote:
>I also hesitate to accept the term "key transport", which will result
>in over-narrowing down the usage scope of the keyEncipherment bit. As 
>Arshad pointed out, sometimes the intention is not to transport the 
>encrypted symmetric key to anywhere. Besides, it is often that the 
>handshake protocol is not simply a "key transport" process; it is more 
>often be a more complex "key exchange" process. For example,
>the SSL handshake protocol names it as "key exchange"
>instead of "key transport". Would it be valid for a SSL server
>cert to be asserted with that keyEncipherment bit?
>To avoid the possible dispute on the definition of
>similar terms, I would like to suggest to drop the term "key
>transport" from the definition of the key usage bit. (However,
>I think it is OK to use "key transport" as an example to
>explain the the definition of the key usage bit.

As commonly employed, a client uses an RSA public key associated with 
a server to encrypt and transport key bits that will later be used to 
create encryption and integrity keys for protecting the session. That 
is an example of key transport. If one used the Diffie-Hellman key 
agreement option for SSL, that would be accurately be described as a 
key exchange, but that is rarely the case, in practice.  So I am 
puzzled by the characterization above.

Steve

Date: Fri, 13 May 2005 18:21:56 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

Steve,

I wished that what you say would be true, however it isn't. See below.

> At 8:41 AM -0600 5/13/05, Bob Bell wrote:

>> Stephen -

>> Just a question for clarification. Since these bits are located in the
>> certificate. How does that translate into knowing without knowledge 
>> based on
>> the actual data structure itself that the data encrypted is keying 
>> material
>> or data. It would seem to me that the contextual information based on the
>> information exchange is more the determiner of what is intended. The 
>> bits in
>> the certificate are to indicate if it is acceptable to use the public key
>> for the stated purpose. At least that is my understanding. If I am wrong,
>> please educate me.

>> Bob Bell

> Bob,

> I can implement crypto software that never releases the bytes decrypted 
> with a private key that appears in a cert which has enabled the 
> "keyEncipherment" but not "dataEncipherment" key usage bits. The intent 
> is that a peer should never have used the public key to encrypt anything 
> but key (or key and associated control info) bits, given the marking. In 
> contrast, if the bytes I receive and decrypt were encrypted using a 
> public key from a cert that has enabled the "dataEncipherment" key usage 
> bit but not the "keyEncipherment" bit, then I would expect to hand these 
> bits to an app, and that would be bad if they were really key bits.

At this time someone who uses a certificate that has the key usage 
keyEncipherment set cannot know whether the "keying material" can be 
released or not by the receiving application (that owns the private key).

Let us look what PKCS#11 states about the mapping of X.509 key usage
flags to cryptoki attributes for private keys for CKA_DECRYPT and CKA_UNWRAP:

Table 35, Mapping of X.509 key usage flags to cryptoki attributes
for private keys

Key usage flags for public keys    Corresponding cryptoki attributes
in X.509 public key certificates   for private keys

dataEncipherment                           CKA_DECRYPT
keyAgreement                               CKA_DERIVE
keyEncipherment                            CKA_UNWRAP

C_UnwrapKey unwraps (i.e. decrypts) a wrapped key, creating a new private
key or secret key object.

The CKA_UNWRAP attribute of the unwrapping key, which indicates whether
the key supports unwrapping, must be TRUE. The new key will have the
CKA_ALWAYS_SENSITIVE attribute set to FALSE, and the CKA_NEVER_EXTRACTABLE
attribute set to FALSE. The CKA_EXTRACTABLE attribute is by default set to
TRUE.

   It would be "nice" to be able to distinguish between C_UnwrapKey where
   the secret cannot be extractable and where it can be.

   We would then be able to distinguish between:

   keyEncipherment-no-extract      :  CKA_UNWRAP_CKA_EXTRACTABLE_FALSE
   keyEncipherment-extract-allowed :  CKA_UNWRAP_CKA_EXTRACTABLE_TRUE

   I would thus propose to be able to support that distinction.

Denis

> Steve

Content-class: urn:content-classes:message
Subject: RE: key usage - key encipherment or data encipherment
Date: Fri, 13 May 2005 16:43:27 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: "Simon McMahon" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Steve,

Even though I'm not really convinced about the benefits, maybe I should
clarify that I don't want to change the bits either for legacy reasons
and in order to stay in sync with X.509.

I'm fine with the earlier provided wordings.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: Stephen Kent [mailto:[email-masked]]
> Sent: den 13 maj 2005 15:33
> To: Stefan Santesson
> Cc: Simon McMahon; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: key usage - key encipherment or data encipherment
> 
> At 11:52 AM +0100 5/13/05, Stefan Santesson wrote:
> >How about calling the bits "The encryption bit" and "The other
> >encryption bit" :-)
> >
> >Jokes aside, can anyone recall the justification for having 2
different
> >bits for key and data encryption?
> 
> Despite the observation that many folks setting these bits, or
> applications using these bits, don't really know the difference,
> there is a difference. From a security perspective, it can be
> important to know whether the bits being decrypted are data to be
> handed to a user or app, or keys to be kept within the key management
> subsystem. Hence there is a legitimate, security benefit that could
> be obtained IF people set the bits properly.
> 
> I am hesitant to have us remove this potentially useful distinction
> merely because folks have not been smart enough to make good use of
> it so far.
> 
> Steve

Date: Fri, 13 May 2005 11:20:46 -0400
To: "Bob Bell" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: key usage - key encipherment or data encipherment
Cc: "'Stefan Santesson'" <[email-masked]>, "'Simon McMahon'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 8:41 AM -0600 5/13/05, Bob Bell wrote:
>Stephen -
>
>Just a question for clarification. Since these bits are located in the
>certificate. How does that translate into knowing without knowledge based on
>the actual data structure itself that the data encrypted is keying material
>or data. It would seem to me that the contextual information based on the
>information exchange is more the determiner of what is intended. The bits in
>the certificate are to indicate if it is acceptable to use the public key
>for the stated purpose. At least that is my understanding. If I am wrong,
>please educate me.
>
>Bob Bell
>
Bob,

I can implement crypto software that never releases the bytes 
decrypted with a private key that appears in a cert which has enabled 
the "keyEncipherment" but not "dataEncipherment" key usage bits. The 
intent is that a peer should never have used the public key to 
encrypt anything but key (or key and associated control info) bits, 
given the marking. In contrast, if the bytes I receive and decrypt 
were encrypted using a public key from a cert that has enabled the 
"dataEncipherment" key usage bit but not the "keyEncipherment" bit, 
then I would expect to hand these bits to an app, and that would be 
bad if they were really key bits.

Steve

From: "Bob Bell" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
Cc: "'Simon McMahon'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: key usage - key encipherment or data encipherment
Date: Fri, 13 May 2005 08:41:59 -0600
Sender: [email-masked]

Stephen - 

Just a question for clarification. Since these bits are located in the
certificate. How does that translate into knowing without knowledge based on
the actual data structure itself that the data encrypted is keying material
or data. It would seem to me that the contextual information based on the
information exchange is more the determiner of what is intended. The bits in
the certificate are to indicate if it is acceptable to use the public key
for the stated purpose. At least that is my understanding. If I am wrong,
please educate me.

Bob Bell

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Friday, May 13, 2005 07:33
> To: Stefan Santesson
> Cc: Simon McMahon; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: key usage - key encipherment or data encipherment
> 
> 
> At 11:52 AM +0100 5/13/05, Stefan Santesson wrote:
> >How about calling the bits "The encryption bit" and "The other 
> >encryption bit" :-)
> >
> >Jokes aside, can anyone recall the justification for having 
> 2 different 
> >bits for key and data encryption?
> 
> Despite the observation that many folks setting these bits, 
> or applications using these bits, don't really know the 
> difference, there is a difference. From a security 
> perspective, it can be important to know whether the bits 
> being decrypted are data to be handed to a user or app, or 
> keys to be kept within the key management subsystem. Hence 
> there is a legitimate, security benefit that could be 
> obtained IF people set the bits properly.
> 
> I am hesitant to have us remove this potentially useful 
> distinction merely because folks have not been smart enough 
> to make good use of it so far.
> 
> Steve
> 

Date: Fri, 13 May 2005 09:33:16 -0400
To: "Stefan Santesson" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: key usage - key encipherment or data encipherment
Cc: "Simon McMahon" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 11:52 AM +0100 5/13/05, Stefan Santesson wrote:
>How about calling the bits "The encryption bit" and "The other
>encryption bit" :-) 
>
>Jokes aside, can anyone recall the justification for having 2 different
>bits for key and data encryption?

Despite the observation that many folks setting these bits, or 
applications using these bits, don't really know the difference, 
there is a difference. From a security perspective, it can be 
important to know whether the bits being decrypted are data to be 
handed to a user or app, or keys to be kept within the key management 
subsystem. Hence there is a legitimate, security benefit that could 
be obtained IF people set the bits properly.

I am hesitant to have us remove this potentially useful distinction 
merely because folks have not been smart enough to make good use of 
it so far.

Steve

Date: Fri, 13 May 2005 10:15:07 -0400
To: "Wen-Cheng Wang" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Cc: <[email-masked]>
Sender: [email-masked]

At 5:48 PM +0800 5/13/05, Wen-Cheng Wang wrote:
>I also hesitate to accept the term "key transport", which will
>result in over-narrowing down the usage scope of the
>keyEncipherment bit. As Arshad pointed out, sometimes
>the intention is not to transport the encrypted symmetric key
>to anywhere. Besides, it is often that the handshake protocol
>is not simply a "key transport" process; it is more often be
>a more complex "key exchange" process. For example,
>the SSL handshake protocol names it as "key exchange"
>instead of "key transport". Would it be valid for a SSL server
>cert to be asserted with that keyEncipherment bit?
>To avoid the possible dispute on the definition of
>similar terms, I would like to suggest to drop the term "key
>transport" from the definition of the key usage bit. (However,
>I think it is OK to use "key transport" as an example to
>explain the the definition of the key usage bit.

As commonly employed, a client uses an RSA public key associated with 
a server to encrypt and transport key bits that will later be used to 
create encryption and integrity keys for protecting the session. That 
is an example of key transport. If one used the Diffie-Hellman key 
agreement option for SSL, that would be accurately be described as a 
key exchange, but that is rarely the case, in practice.  So I am 
puzzled by the characterization above.

Steve

Content-class: urn:content-classes:message
Subject: RE: key usage - key encipherment or data encipherment
Date: Fri, 13 May 2005 11:52:02 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Simon McMahon" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

How about calling the bits "The encryption bit" and "The other
encryption bit" :-)  

Jokes aside, can anyone recall the justification for having 2 different
bits for key and data encryption?

Is there any realistic security threat involved with allowing both
purposes for the same bit?

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of Simon McMahon
> Sent: den 13 maj 2005 03:19
> To: [email-masked]; [email-masked];
[email-masked]
> Cc: [email-masked]
> Subject: RE: key usage - key encipherment or data encipherment
> 
> 
> Sorry but I think this new text is just more jargon and does not
address
> the problem. The problem is that there are 2 bits for encryption
instead
> of 1 so people can make a choice and need direction in that choice,
but
> will still get it wrong anyway, just because they can (Murphy). The
> misunderstanding is that "keyEncipherment" is nearly always the
correct
> choice but sometimes people use "dataEncipherment" because the
transport
> keys are not explicit.
> 
> Note that a new definition of a public key cipher RSA' that internally
> used "RSA+AES" but didn't publish that fact could have RSA' public
keys
> (not RSA keys but internally identical to them) that directly encrypt
> large amounts of data. The transport key just blends into the cipher
text.
> "dataEncipherment" is then the correct bit for the RSA' key but I'll
bet
> people who know its really RSA+AES will use "keyEncipherment" because
that
> is what is really happening.
> 
> The bottom line is that this problem will never go away as long as you
> have two bits whose meanings overlap like these ones do. The bits
should
> be merged because CA's that know about interoperability issues just
set
> both anyway. I would prefer a consolidation these flags and to
deprecate
> "dataEncipherment". That would leave "keyEncipherment" that could be
> renamed to "encipherment". Then there is no confusion because there is
no
> choice anymore.
> 
> Anyway, back to the text...
> 
> Why did the "private" key creep into this description? "Private" keys
are
> also "secret". By the way, how does a public key encrypt a private
key? It
> is impossible, at least with RSA without a symmetric key in there,
unless
> the private key is a lot smaller. The latest proposed text example
> specifies "content-decryption" now but symmetric keys exchanged this
way
> can also be for encryption too. Also, the symmetric key encrypted by
the
> public key was in fact an encryption key when the originator used it.
> 
> Proposed rewording preserving both bits:
> "
> The keyEncipherment bit is asserted when the subject public key is
used
> for transport of a secret key or data encryption using an intermediate
> secret key. For example, when a public key is to be used to encrypt a
> secret cipher key that will encrypt some data or key, then this bit
shall
> asserted.
> 
> The dataEncipherment bit is asserted when the subject public key is
used
> for directly enciphering user data other than cryptographic keys.
> "
> 
> Proposed rewording with only one bit:
> "
> The dataEncipherment bit is deprecated. If asserted then this bit now
has
> the same meaning as keyEncipherment. The keyEncipherment bit is
renamed to
> "encipherment" and is asserted when either of the previous bits were
> asserted. Whenever a public key is used to encrypt data or keys then
this
> bit shall be asserted.
> "
> 
> Regards,
> 
> Simon McMahon.
> 
> 
> 
> Simon McMahon
> 
> Work: (07) 31311420
> Mobile: (043) 2294180
> 
> 
> >>> Sharon Boeyen <[email-masked]> 05/13/05 05:44am >>>
> I like the proposed text also. My only suggestion is could we add
> "symmetric" in the sentence for dataEncipherment, so it would read
"...
> without the use of an intermediate symmetric key." I don't feel
strongly
> about this but do think it helps with the clarity.
> 
> Cheers,
> Sharon
> 
> On
> Behalf Of Russ Housley
> Sent: Thursday, May 12, 2005 11:22 AM
> To: Denis Pinkas
> Cc: [email-masked]
> Subject: Re: key usage - key encipherment or data encipherment
> 
> 
> 
> Denis:
> 
> Thanks.  I think you suggestion improves the text.
> 
> Russ
> 
> At 10:44 AM 5/12/2005, Denis Pinkas wrote:
> >Russ,
> >
> >>Since we are working on an update to RFC 3280, I propose the
following
> >>revisions to these descritions.
> >
> >>      The keyEncipherment bit is asserted when the subject public
key is
> >>      used for key transport.  For example, when an RSA key is to be
> >>      used for key management by encrypting a symmetric content-
> encryption
> >>      key, then this bit shall asserted.
> >>      The dataEncipherment bit is asserted when the subject public
key
> >>      is used for directly enciphering raw user data without the use
of
> >>      an intermediate symmetric cipher.
> >
> >Thank you for this strawman proposal. I would rather propose:
> >
> >       The keyEncipherment bit is asserted when the subject public
key is
> >       used for enciphering private or secret keys, i.e. for key
> transport.
> >       For example, this bit shall be set when a public RSA key is to
be
> >       used for encrypting a symmetric content-decryption key or an
> >       asymmetric private key.
> >
> >       The dataEncipherment bit is asserted when the subject public
key
> >       is used for directly enciphering raw user data without the use
of
> >       an intermediate key.
> >
> >Reasons:
> >
> >a) "Key transport" is not explicit enough. The purpose is to encipher
> >either a private key or a secret key.
> >
> >b) The example is not clear enough: "RSA key" can be a private key or
a
> >public key, hence why "public" has been added.
> >
> >c) The key that is communicated is a decryption key rather than an
> >encryption key, hence why "content-encryption" has been changed into
> >"content-decryption".
> >
> >d) The example has been extended to cover the case of an asymmetric
> >cipher
> >as well.
> >
> >e) In the last statement, the intermediate key would not necessarily
be
> >a
> >symmetric cipher, hence why "symmetric" has been deleted. Also
"cipher"
> >has been replaced by "key'.
> >
> >Note that the current text from X.509 is:
> >
> >   c) keyEncipherment: for enciphering keys or other security
> information,
> >      e.g. for key transport;
> >
> >   d) dataEncipherment: for enciphering user data, but not keys or
other
> >      security information as in c) above;
> >
> >Denis
> 
> 
>
************************************************************************
**
> *********
> This email, including any attachments sent with it, is confidential
and
> for the sole use of the intended recipient(s).  This confidentiality
is
> not waived or lost, if you receive it and you are not the intended
> recipient(s), or if it is transmitted/received in error.
> 
> Any unauthorised use, alteration, disclosure, distribution or review
of
> this email is prohibited.  It may be subject to a statutory duty of
> confidentiality if it relates to health service matters.
> 
> If you are not the intended recipient(s), or if you have received this
> email in error, you are asked to immediately notify the sender by
> telephone or by return email.  You should also delete this email and
> destroy any hard copies produced.
>
************************************************************************
**
> *********

Content-class: urn:content-classes:message
Subject: RE: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Fri, 13 May 2005 11:28:44 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

Denis,

Thanks for the clarification.
Yes, we agree on issue number 1 (remove SHOULD and MUST)

So the remaining issue is:

Problem: The security considerations talk about "mitigation" of the name
collision problem but gives inadequate advice.

Your proposed resolution

 a) warn the user that the CRL where this extension was found may not be
    the right one.
 
 b) warn the user that the CRL issuer certificate he might obtain using
    this extension may not be the right one.
 
 c) provide guidance on how to GUARANTEE that the CRL Issuer is indeed
    the one nominated by the CA that has issued the target certificate
    (i.e. when the CRL Issuer certification path and the target
    certificate certification path are identical).
 
 d) say that other possibilities exists, but need additional trust
    conditions (there are zillions of such possible trust conditions).

To complete the picture it would now be very helpful if you, for each of
these statements, could confirm or explain how these issues are a result
of using the AIA extension in CRLs. Or in other words, which of these
security considerations could you ignore (would go away) if you were NOT
using the AIA extension in a CRL to locate the CRL Issuer certificate.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

From: "Wen-Cheng Wang" <[email-masked]>
To: <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Date: Fri, 13 May 2005 17:48:30 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

I also hesitate to accept the term "key transport", which will
result in over-narrowing down the usage scope of the
keyEncipherment bit. As Arshad pointed out, sometimes
the intention is not to transport the encrypted symmetric key
to anywhere. Besides, it is often that the handshake protocol
is not simply a "key transport" process; it is more often be
a more complex "key exchange" process. For example,
the SSL handshake protocol names it as "key exchange"
instead of "key transport". Would it be valid for a SSL server
cert to be asserted with that keyEncipherment bit?
To avoid the possible dispute on the definition of
similar terms, I would like to suggest to drop the term "key
transport" from the definition of the key usage bit. (However,
I think it is OK to use "key transport" as an example to
explain the the definition of the key usage bit.

I also think it is strange to positively list "private keys" and
"secret keys" as the only two possible types of keys that can
be encrypted by the subject public key? What if someday
another type of keys is invented and need to be encrypted by
the subject public key? Why not simply use the term
"cryptographic keys"? I believe the term  "cryptographic keys"
is general enough to cover any types of keys.

My other concern is that the current definition of the key
usage bit seems to only allow the subject public key be
used for enciphering "keys". However, we must note that
it is more often that modern handshake protocols actually
use the subject public key for enciphering "keying materials"
instead of the "real keys". For example,  the
pre-master-secret in the SSL hadnshake protocol is not
yet a "real key"; it is actually be a "keying material" that
can be used to derive "real shared secret keys" between
the client and the server. Therefore, I suggest that we
should take the possibility of enciphering "keying materials"
instead of the "real keys" into account.

Here I propose to revise the definitions of this two key usage
bits as follows:

      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering cryptographic keys or keying materials.
      For example, this bit shall be set when a RSA public key is to be
      used for key transport that involves encrypting a symmetric
      content-decryption key or an asymmetric private key.
 
     The dataEncipherment bit is asserted when the subject public key
     is used for directly enciphering raw user data, other than cryptographic
     keys or keying materials, without the use of an intermediate symmetric
     cipher. Note that the use of this bit is extremely uncommon; almost all
     applications use key transport or key agreement to establish shared
     cryptographic keys.

Wen-Cheng Wang

Arshad Noor wrote:
> 
> I am afraid, this still does not provide sufficient clarity.
> 
> Some questions that I cannot answer, based on reading the text
> below (although I know the answers from practice) are:
> 
> 1) Whose private key am I encrypting with the public key?  Mine?
>    Hopefully not, because if this were the only copy of my private
>    key, what am I going to use to decrypt the cipher-text with?
>    While this may appear as a ridiculous notion, the point is that
>    the text does not clarify this question.
> 
> 2) What if I'm not using the certificate for key transport?  I may
>    have issued a certificate to a database that generates symmetric
>    keys to encrypt database content, and then stores the encrypted
>    symmetric key within the same database with the cipher-text. I'm
>    not transporting the symmetric key anywhere, so should I be using
>    the keyEncipherment bit or the dataEncirpherment bit?
> 
> In my opinion, the confusion arises because the two bits perform
> the same function: encipherment (as Simon McMahon pointed out in
> an earlier posting), but for different purposes.
> 
> There is a certain simplicity to having just one encipherment bit,
> letting applications decide what they want to encrypt with the
> certificate's public-key and letting them codify it in *their*
> protocols - as S/MIME does - or through EKU's.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> 
> Russ Housley wrote:
>> 
>> There has been a whole lot of discussion about these paragraphs.  Since 
>> some of the discussion has not been CCed to the PKIX mail list, I am 
>> posting the resulting words.
>> 
>>      The keyEncipherment bit is asserted when the subject public key is
>>      used for enciphering private or secret keys, i.e., for key transport.
>>      For example, this bit shall be set when a RSA public key is to be
>>      used for encrypting a symmetric content-decryption key or an
>>      asymmetric private key.
>> 
>>     The dataEncipherment bit is asserted when the subject public key
>>     is used for directly enciphering raw user data without the use of
>>     an intermediate symmetric cipher. Note that the use of this
>>     bit is extremely uncommon; almost all applications use
>>     key transport or key agreement to establish a symmetric key.
>> 
>> I hope we a re close to closure on this one....
>> 
>> Russ
>> 
>

From: <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 13 May 2005 09:09:50 GMT
Subject: RE: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

IMO password or PIN is also considered as a secret key,
then which applications or protocols are demanding the dataEncipherment 
bit?

Thanks

Diego

----- Mensaje Original -----
Remitente: Russ Housley [email-masked]
Destinatario: [email-masked]
Fecha: Jueves, Mayo 12, 2005 9:21pm
Asunto: Re: key usage - key encipherment or data encipherment

>
>     The keyEncipherment bit is asserted when the subject public 
>key is
>     used for enciphering private or secret keys, i.e., for key 
>transport.      For example, this bit shall be set when a RSA public 
>key is to be
>     used for encrypting a symmetric content-decryption key or an
>     asymmetric private key.
>
>    The dataEncipherment bit is asserted when the subject public key
>    is used for directly enciphering raw user data without the use of
>    an intermediate symmetric cipher. Note that the use of this
>    bit is extremely uncommon; almost all applications use
>    key transport or key agreement to establish a symmetric key.
>

Date: Fri, 13 May 2005 10:38:59 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Denis Pinkas wrote:

> > When policies, procedures, and practices are followed, I do not believe
> > that two different CRL issuers that are subordinate to the same trust
> > anchor can legitimately have the same name.
>
> You have certainly heard of the name "Eurostar". That name was originally
> used by a French truck company, and the French-British railways anyway
> made accidentally a name collision with it.

Isn't the source of this problem the fact that as long as nothing 
cryptographically binds to it, it's very hard to be completely sure we 
got the right certificate ?

So why not solve that and expand the way we link to the CRL issuer to 
allow the use a ESSCertID ?

Date: Fri, 13 May 2005 09:59:20 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Russ,

 > Denis:

 >> >>> You say that it is not clear what validation policy needs to be used,
 >> >>> but this is completely irrelevant to the discussion of the CRL AIA
 >> >>> extension.  This extension aid in certification path construction,
 >> >>> not the validation of the path once it is constructed.

 >> >> Not exactly, it could "help" finding a wrong path !

 >> > Not likely.  The signer of the CRL is providing a pointer to their own
 >> > certificate.  Path construction to locate a parent of that certificate
 >> > through a complex PKI might include paths that are acceptable and paths
 >> > that are unacceptable, but the certificate that contains the public key
 >> > needed to validate the signature on the CRL is clearly needed.

 >> The problem is to know if a CRL that has been fetched "somewhere" is
 >> adequate for the target certificate. It is not to validate a CRL that
 >> has been fetched "somewhere".

 > You continue to miss the whole point of this document.

I do not think so.

 > The certificate user has already obtained the CRL, but needs the
                                              ^^^^
it is not "the" CRL since it is only "a" CRL. If you got a network attack
when fetching the CRL from the CRL DP you may get something wrong. So at
this time you still do not know what is *the* right CRL.

 > certificate of the CRL issuer in order to validate the signature on the
 > CRL.  That is the scope of this document.

Not exacly. You are not sure to get "the" CA certificate of the CRL issuer,
but only "a" certificate that bears the appropriate DN in the subject DN.
but collisions in subject DNs may happen accidently or deliberately.

 > You keep trying to make it something else.

The distinction between "the" and "a" is pretty important.

Denis

 > Russ

Date: Fri, 13 May 2005 09:57:40 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Russ,

 > Denis:
 >
 > Finally!  We now uncover the actual point of disagreement.

I would hope, but I am still unsure.

 > You say:

  >> The same trust anchor is not a *sufficient* condition. The same node
  >> in the certification tree is the necessary condition. This implies, of
  >> course, the same trust anchor, but since two CRL issuers located at
  >> different nodes (i.e. certified by different CAS) might have the
  >> same CRL issuer name, this condition is insufficient to solve the
  >> issue.

 > When policies, procedures, and practices are followed, I do not believe
 > that two different CRL issuers that are subordinate to the same trust
 > anchor can legitimately have the same name.

You have certainly heard of the name "Eurostar". That name was originally
used by a French truck company, and the French-British railways anyway
made accidentally a name collision with it.

We can hope that this does not happen again, but we cannot make sure it
already happened. We need to build a secure PKI, not a "nearly secure"
PKI and there ARE solutions to make it fully secure.

I also know there are current solutions which are NOT fully secure.
The goal of our group is to say how to make it secure.

 > As I said yesterday, I am
 > willing to add text to the Security Considerations section to state
 > this.

As mentioned above, this is untrue in general.

 > I am even willing to state that certificate users should not
 > include trust anchors that do not have policies, procedures, and
 > practices that would prevent such name collisions.

This is impossible to state since the certification tree may be growing
and thus you cannot make sure that you have explored all the tree.

See my detailed response to Stefan from a few minutes ago on what needs to 
be covered in the security considerations section.

Denis

 > Russ

Date: Fri, 13 May 2005 09:53:36 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Stefan,

> Denis,
> 
> My main comment to this is that there is no exact definition of what is
> "sufficient" in this case.
> 
> What is sufficient to you may not be sufficient to me or vice versa.
> This issue is as many times when security is the issue a tradeoff. In IT
> security you always have the 3 goals:
> 
> - Cheep
> - Easy to use
> - Secure

No. There is not such a trade-off in security.
Either it is secure or not.

> The sad truth is that we often discover that we can have any 2 of those
> but never all 3.

I do know some implementations that have this problem, and I won't
nominate any. I will simply quote some recent good words from Peter Gutmann:

  " 1. Vendor does something silly.

    2. Vendor uses ambiguous wording of spec to justify their silliness
       because they don't want to fix their code.

    3. User has the option of breaking their code to match the vendor
       silliness, or going somewhere else (learning to flip burgers, for
       example)".

I do not want cases 1 and 2 to happen, and this is exactly what is going
to happen in the present case.

Denis

> The fact about name uniqueness you provide in the referenced text is a
> true facts but it still does not tell me what is sufficient or not in my
> environment or how I can achieve reasonable security when the trust
> paths differ (in case they have to).
> 
> My basic assessment is that there is neither a single truth nor a single
> solution to the problem. The chaining to a common root was the
> reasonable recommendation agreed at the San Diego PKIX meeting. This is
> in my mind not intended to be advertised as a "sufficient" solution,
> just good practice to reduce the risk of problems.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>  
> 
> 
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 12 maj 2005 11:27
>>To: Russ Housley
>>Cc: pkix
>>Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
>>
>>
>>Russ,
>>
>>Since Tim has now made the call at the WG level, please consider this
>>message as an answer to the call: the current security considerations
>>section is not acceptable.
>>
>>  > The document already says that the CA and the CRL issuer need to
>>  > terminate at the same trust anchor.  This is the important point.
>>  > I disagree that there is anything else that ought to be said in
> 
> the
> 
>>  > security considerations.
>>
>>This statement still does not answer to the point I raised, but
>>I will nevertheless answer to your statement.
>>
>>The same trust anchor is not a *sufficient* condition. The same node
> 
> in
> 
>>the
>>certification tree is the necessary condition. This implies, of
> 
> course,
> 
>>the
>>same trust anchor, but since two CRL issuers located at different
> 
> nodes
> 
>>(i.e. certified by different CAS) might have the same CRL issuer name,
>>this
>>condition is insufficient to solve the issue.
>>
>>May I recall an extract from the security considerations section of an
>>approved draft that will be published soon as RFC 4043 ? (this is the
>>permanent-identifier document):
>>
>>      Subject names in certificates are chosen by the issuing CA and
> 
> are
> 
>>      mandated to be unique for each CA; so there can be no name
> 
> collision
> 
>>      between subject names from the same CA.  Such a name may be an
> 
> end-
> 
>>      entity name when the certificate is a leaf certificate, or a CA
>>name,
>>      when it is a CA certificate.
>>
>>      Since a name is only unique towards its superior CA, unless some
>>      naming constraints are being used, a name would only be
> 
> guaranteed
> 
>>to
>>      be globally unique when considered to include a sequence of all
> 
> the
> 
>>      names of the superior CAs. (...)
>>
>>      Additional checks need to be done, e.g., to check if the public
> 
> key
> 
>>      values of the two CAs which have issued the certificates to be
>>      compared are identical or if the sequence of CA names in the
>>      certification path from the trust anchor to the CA are
> 
> identical.
> 
>>      (...)
>>
>>      The certification of different CAs with the same DN by different
> 
> CAs
> 
>>      has other negative consequences in various parts of the PKI,
> 
> notably
> 
>>      rendering the IssuerAndSerialNumber structure in [RFC3852]
> 
> section
> 
>>      10.2.4 ambiguous.
>>
>>It speaks for itself, as it applies to CRL Issuers as well. Some parts
> 
> of
> 
>>it should indeed be copied and pasted in the security considerations
>>section
>>of the current proposed draft.
>>
>>When the certification path used to validate the target certificate is
>>also used to validate the CRL Issuer certificate, then there is no
>>security
>>issue: this should be said in the security considerations section.
>>
>>What about the other cases ? The other cases belong to the category of
>>indirect CRLs. Depending on the local validation policy checks done or
> 
> not
> 
>>done there may be security issues.
>>
>>Denis
>>
>>  > Russ
>>  >
>>  > At 02:59 AM 5/10/2005, Denis Pinkas wrote:
>>  >
>>  >> Russ,
>>  >>
>>  >> Your statement below is correct, but does not answer to any of my
>>  >> questions/issues. In particular, the last one. I am still
> 
> awaiting
> 
>>  >> your responses.
>>  >>
>>  >> Denis
>>  >>
>>  >>> Denis:
>>  >>> RFC 3280 does not tell an implementor how for locate
> 
> certificates
> 
>>for
>>  >>> any certification path construction.  There are several
> 
> extensions
> 
>>  >>> that provide pointers that may help an implementation, but other
>>  >>> approaches to obtaining the same certificates are always
> 
> permitted.
> 
>>  >>> I would fully expect an implementation to check any local cache
>>  >>> before accessing a repository.
>>  >>> The CRL AIA extension fits this pattern.  A method for locating
> 
> a
> 
>>  >>> certificate is provided, but any other mechanism for locating
> 
> the
> 
>>  >>> same certificate is acceptable.
>>  >>> Russ
>>  >>>
>>  >>>> Stefan,
>>  >>>>
>>  >>>> I made the e-mail shorter. Your main arguments are the
> 
> following:
> 
>>  >>>>
>>  >>>>
>>
> ========================================================================
> ==
> 
>>  >>>>
>>  >>>>
>>  >>>> [Stefan] But it has to provide a warning to something that is
>>  >>>> introduced
>>  >>>> by the standard. This standard does not introduce the concept
> 
> of
> 
>>CRL
>>  >>>> signature checking or CRL issuer certificate validation, so
> 
> that is
> 
>>  >>>> clearly out of scope. More about that below;
>>  >>>>
>>  >>>> [Denis] See below the last answer and also my arguments in the
>>  >>>> soon-to-be-posted answer to Russ.
>>  >>>>
>>  >>>>
>>
> ========================================================================
> ==
> 
>>  >>>>
>>  >>>>
>>  >>>>
>>  >>>> > > RFC 3280 [PKIX1] specifies the validation of certification
>>paths.
>>  >>>> > > One aspect involves the determination that a certificate
> 
> has
> 
>>not
>>  >>>> been
>>  >>>> > > revoked, and one revocation checking mechanism is the
>>Certificate
>>  >>>> > > Revocation List (CRL).  CRL validation is also specified in
> 
> RFC
> 
>>  >>>> 3280,
>>  >>>>
>>  >>>> > I would love this last sentence to be true but the reality is
>>that:
>>  >>>> > "CRL validation is NOT specified in RFC 3280". :-(
>>  >>>>
>>  >>>> [Stefan] In fact it is.
>>  >>>>
>>  >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85:
>>  >>>>
>>  >>>>    (f)  Obtain and validate the certification path for the
> 
> complete
> 
>>CRL
>>  >>>>    issuer.  If a key usage extension is present in the CRL
> 
> issuer's
> 
>>  >>>>    certificate, verify that the cRLSign bit is set.
>>  >>>>
>>  >>>>    (g)  Validate the signature on the complete CRL using the
> 
> public
> 
>>key
>>  >>>>    validated in step (f).
>>  >>>>
>>  >>>> [Denis] The text does not say how to obtain and validate the
>>  >>>> certification path for the complete (???) CRL issuer. The text
> 
> is
> 
>>  >>>> not clear enough so that two implementors only looking at this
>>  >>>> sentence will provide interoperable implementations.
>>  >>>>
>>  >>>>
>>
> ========================================================================
> ==
> 
>>  >>>>
>>  >>>>
>>  >>>> [Stefan] It is my hope that the provided responses here can
> 
> help
> 
>>  >>>> convince you to change your mind about that. If it doesn't I
> 
> still
> 
>>  >>>> argue
>>  >>>> that the place to specify requirements and security
> 
> considerations
> 
>>for
>>  >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL
>>draft.
>>  >>>>
>>  >>>> [Denis] I can agree with your last sentence, ... which means
> 
> that
> 
>>it
>>  >>>> should not be in the main body of the document. In the security
>>  >>>> considerations section, text is free and we shall at the very
>>  >>>> minimum warn implementers and we should provide some guidance.
> 
> When
> 
>>  >>>> the same certification path (i.e. the path used to validate the
>>  >>>> target certificate) is used, then there is no security issue:
> 
> this
> 
>>  >>>> should be said. For all other cases, there MAY be problems:
> 
> this
> 
>>  >>>> should also be said. It is as simple as that.
>>  >>>>
>>  >>>> Denis
>>  >>>
>>  >>
>>  >>
>>  >
>>  >
>>
>>
>>
> 
> 

Date: Fri, 13 May 2005 09:51:03 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Stefan,

> Denis,
> 
> The core of your comments are spread over many emails and opinions may
> have changed on details so I'm not sure I have got the latest picture of
> your recorded problems and what you propose as resolution.
> 
> I'm thus trying to summarize the current complete picture of the last
> call comments below. Please correct me if something is wrong or missing.
> Note that I'm not arguing here, just trying to structure the issues (I
> will argue in separate mails). Also note that agreed typos are omitted
> from the list:

> 1)
> Problem: There are SHOULD and MUST requirements in the security
> considerations section.

> Proposed resolution: Reword to make sure we don't use SHOULD or MUST in
> this section.

I believe they we all agree on this.

> -----
> 2)
> Problem: The security considerations talk about "mitigation" of the name
> collision problem but gives inadequate advice.

> Proposed resolution: Either delete all text talking about how to
> mitigate this problem or provide full guidance on what it takes to
> guarantee that a CRL Issuer with a matching name actually is the
> intended CRL Issuer. Also explain that this is not an issue when the CRL
> Issuer certification path and the target certificate certification path
> are identical.

Not exactly. I would say :

a) warn the user that the CRL where this extension was found may not be
    the right one.

b) warn the user that the CRL issuer certificate he might obtain using
    this extension may not be the right one.

c) provide guidance on how to GUARANTEE that the CRL Issuer is indeed
    the one nominated by the CA that has issued the target certificate
    (i.e. when the CRL Issuer certification path and the target
    certificate certification path are identical).

d) say that other possibilities exists, but need additional trust
    conditions (there are zillions of such possible trust conditions).

Denis

> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>  
> 
> 
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 12 maj 2005 11:27
>>To: Russ Housley
>>Cc: pkix
>>Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
>>
>>
>>Russ,
>>
>>Since Tim has now made the call at the WG level, please consider this
>>message as an answer to the call: the current security considerations
>>section is not acceptable.
>>
>>  > The document already says that the CA and the CRL issuer need to
>>  > terminate at the same trust anchor.  This is the important point.
>>  > I disagree that there is anything else that ought to be said in
> 
> the
> 
>>  > security considerations.
>>
>>This statement still does not answer to the point I raised, but
>>I will nevertheless answer to your statement.
>>
>>The same trust anchor is not a *sufficient* condition. The same node
> 
> in
> 
>>the
>>certification tree is the necessary condition. This implies, of
> 
> course,
> 
>>the
>>same trust anchor, but since two CRL issuers located at different
> 
> nodes
> 
>>(i.e. certified by different CAS) might have the same CRL issuer name,
>>this
>>condition is insufficient to solve the issue.
>>
>>May I recall an extract from the security considerations section of an
>>approved draft that will be published soon as RFC 4043 ? (this is the
>>permanent-identifier document):
>>
>>      Subject names in certificates are chosen by the issuing CA and
> 
> are
> 
>>      mandated to be unique for each CA; so there can be no name
> 
> collision
> 
>>      between subject names from the same CA.  Such a name may be an
> 
> end-
> 
>>      entity name when the certificate is a leaf certificate, or a CA
>>name,
>>      when it is a CA certificate.
>>
>>      Since a name is only unique towards its superior CA, unless some
>>      naming constraints are being used, a name would only be
> 
> guaranteed
> 
>>to
>>      be globally unique when considered to include a sequence of all
> 
> the
> 
>>      names of the superior CAs. (...)
>>
>>      Additional checks need to be done, e.g., to check if the public
> 
> key
> 
>>      values of the two CAs which have issued the certificates to be
>>      compared are identical or if the sequence of CA names in the
>>      certification path from the trust anchor to the CA are
> 
> identical.
> 
>>      (...)
>>
>>      The certification of different CAs with the same DN by different
> 
> CAs
> 
>>      has other negative consequences in various parts of the PKI,
> 
> notably
> 
>>      rendering the IssuerAndSerialNumber structure in [RFC3852]
> 
> section
> 
>>      10.2.4 ambiguous.
>>
>>It speaks for itself, as it applies to CRL Issuers as well. Some parts
> 
> of
> 
>>it should indeed be copied and pasted in the security considerations
>>section
>>of the current proposed draft.
>>
>>When the certification path used to validate the target certificate is
>>also used to validate the CRL Issuer certificate, then there is no
>>security
>>issue: this should be said in the security considerations section.
>>
>>What about the other cases ? The other cases belong to the category of
>>indirect CRLs. Depending on the local validation policy checks done or
> 
> not
> 
>>done there may be security issues.
>>
>>Denis
>>
>>  > Russ
>>  >
>>  > At 02:59 AM 5/10/2005, Denis Pinkas wrote:
>>  >
>>  >> Russ,
>>  >>
>>  >> Your statement below is correct, but does not answer to any of my
>>  >> questions/issues. In particular, the last one. I am still
> 
> awaiting
> 
>>  >> your responses.
>>  >>
>>  >> Denis
>>  >>
>>  >>> Denis:
>>  >>> RFC 3280 does not tell an implementor how for locate
> 
> certificates
> 
>>for
>>  >>> any certification path construction.  There are several
> 
> extensions
> 
>>  >>> that provide pointers that may help an implementation, but other
>>  >>> approaches to obtaining the same certificates are always
> 
> permitted.
> 
>>  >>> I would fully expect an implementation to check any local cache
>>  >>> before accessing a repository.
>>  >>> The CRL AIA extension fits this pattern.  A method for locating
> 
> a
> 
>>  >>> certificate is provided, but any other mechanism for locating
> 
> the
> 
>>  >>> same certificate is acceptable.
>>  >>> Russ
>>  >>>
>>  >>>> Stefan,
>>  >>>>
>>  >>>> I made the e-mail shorter. Your main arguments are the
> 
> following:
> 
>>  >>>>
>>  >>>>
>>
> ========================================================================
> ==
> 
>>  >>>>
>>  >>>>
>>  >>>> [Stefan] But it has to provide a warning to something that is
>>  >>>> introduced
>>  >>>> by the standard. This standard does not introduce the concept
> 
> of
> 
>>CRL
>>  >>>> signature checking or CRL issuer certificate validation, so
> 
> that is
> 
>>  >>>> clearly out of scope. More about that below;
>>  >>>>
>>  >>>> [Denis] See below the last answer and also my arguments in the
>>  >>>> soon-to-be-posted answer to Russ.
>>  >>>>
>>  >>>>
>>
> ========================================================================
> ==
> 
>>  >>>>
>>  >>>>
>>  >>>>
>>  >>>> > > RFC 3280 [PKIX1] specifies the validation of certification
>>paths.
>>  >>>> > > One aspect involves the determination that a certificate
> 
> has
> 
>>not
>>  >>>> been
>>  >>>> > > revoked, and one revocation checking mechanism is the
>>Certificate
>>  >>>> > > Revocation List (CRL).  CRL validation is also specified in
> 
> RFC
> 
>>  >>>> 3280,
>>  >>>>
>>  >>>> > I would love this last sentence to be true but the reality is
>>that:
>>  >>>> > "CRL validation is NOT specified in RFC 3280". :-(
>>  >>>>
>>  >>>> [Stefan] In fact it is.
>>  >>>>
>>  >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85:
>>  >>>>
>>  >>>>    (f)  Obtain and validate the certification path for the
> 
> complete
> 
>>CRL
>>  >>>>    issuer.  If a key usage extension is present in the CRL
> 
> issuer's
> 
>>  >>>>    certificate, verify that the cRLSign bit is set.
>>  >>>>
>>  >>>>    (g)  Validate the signature on the complete CRL using the
> 
> public
> 
>>key
>>  >>>>    validated in step (f).
>>  >>>>
>>  >>>> [Denis] The text does not say how to obtain and validate the
>>  >>>> certification path for the complete (???) CRL issuer. The text
> 
> is
> 
>>  >>>> not clear enough so that two implementors only looking at this
>>  >>>> sentence will provide interoperable implementations.
>>  >>>>
>>  >>>>
>>
> ========================================================================
> ==
> 
>>  >>>>
>>  >>>>
>>  >>>> [Stefan] It is my hope that the provided responses here can
> 
> help
> 
>>  >>>> convince you to change your mind about that. If it doesn't I
> 
> still
> 
>>  >>>> argue
>>  >>>> that the place to specify requirements and security
> 
> considerations
> 
>>for
>>  >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL
>>draft.
>>  >>>>
>>  >>>> [Denis] I can agree with your last sentence, ... which means
> 
> that
> 
>>it
>>  >>>> should not be in the main body of the document. In the security
>>  >>>> considerations section, text is free and we shall at the very
>>  >>>> minimum warn implementers and we should provide some guidance.
> 
> When
> 
>>  >>>> the same certification path (i.e. the path used to validate the
>>  >>>> target certificate) is used, then there is no security issue:
> 
> this
> 
>>  >>>> should be said. For all other cases, there MAY be problems:
> 
> this
> 
>>  >>>> should also be said. It is as simple as that.
>>  >>>>
>>  >>>> Denis
>>  >>>
>>  >>
>>  >>
>>  >
>>  >
>>
>>
>>
> 
> 

Importance: normal
Content-Class: urn:content-classes:message
Subject: R: key usage - key encipherment or data encipherment
Date: Fri, 13 May 2005 08:42:54 +0200
From: "Santoni Adriano" <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

I'd suggest to modify the first part like follows (or equivalently):

      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering private or secret keys, i.e., for key transport.
      For example, this bit shall be set when a RSA public key is to be
      used for encrypting a symmetric content-decryption key or an
      asymmetric private key (e.g. as it occurs in the TLS protocol with
      the server's public key).

This would add another bit of clarity to the prescription.

My 2 cents (of Euro :-)

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Russ Housley
Inviato: gioved� 12 maggio 2005 21.21
A: [email-masked]
Oggetto: Re: key usage - key encipherment or data encipherment

There has been a whole lot of discussion about these paragraphs.  Since 
some of the discussion has not been CCed to the PKIX mail list, I am 
posting the resulting words.

      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering private or secret keys, i.e., for key transport.
      For example, this bit shall be set when a RSA public key is to be
      used for encrypting a symmetric content-decryption key or an
      asymmetric private key.

     The dataEncipherment bit is asserted when the subject public key
     is used for directly enciphering raw user data without the use of
     an intermediate symmetric cipher. Note that the use of this
     bit is extremely uncommon; almost all applications use
     key transport or key agreement to establish a symmetric key.

I hope we a re close to closure on this one....

Russ

*******************Internet Email Confidentiality Footer*******************

Qualsiasi utilizzo non autorizzato del presente messaggio nonch� dei suoi allegati � vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati.
Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of ACTALIS S.p.A. Besides, The contents of this message shall be understood as neither given nor endorsed by ACTALIS S.p.A.. 
ACTALIS S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.

Date: Thu, 12 May 2005 20:38:36 -0700
From: Arshad Noor <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
To: [email-masked]
Organization: StrongAuth, Inc.
Sender: [email-masked]

I am afraid, this still does not provide sufficient clarity.

Some questions that I cannot answer, based on reading the text
below (although I know the answers from practice) are:

1) Whose private key am I encrypting with the public key?  Mine?
    Hopefully not, because if this were the only copy of my private
    key, what am I going to use to decrypt the cipher-text with?
    While this may appear as a ridiculous notion, the point is that
    the text does not clarify this question.

2) What if I'm not using the certificate for key transport?  I may
    have issued a certificate to a database that generates symmetric
    keys to encrypt database content, and then stores the encrypted
    symmetric key within the same database with the cipher-text. I'm
    not transporting the symmetric key anywhere, so should I be using
    the keyEncipherment bit or the dataEncirpherment bit?

In my opinion, the confusion arises because the two bits perform
the same function: encipherment (as Simon McMahon pointed out in
an earlier posting), but for different purposes.

There is a certain simplicity to having just one encipherment bit,
letting applications decide what they want to encrypt with the
certificate's public-key and letting them codify it in *their*
protocols - as S/MIME does - or through EKU's.

Arshad Noor
StrongAuth, Inc.

Russ Housley wrote:
> 
> There has been a whole lot of discussion about these paragraphs.  Since 
> some of the discussion has not been CCed to the PKIX mail list, I am 
> posting the resulting words.
> 
>      The keyEncipherment bit is asserted when the subject public key is
>      used for enciphering private or secret keys, i.e., for key transport.
>      For example, this bit shall be set when a RSA public key is to be
>      used for encrypting a symmetric content-decryption key or an
>      asymmetric private key.
> 
>     The dataEncipherment bit is asserted when the subject public key
>     is used for directly enciphering raw user data without the use of
>     an intermediate symmetric cipher. Note that the use of this
>     bit is extremely uncommon; almost all applications use
>     key transport or key agreement to establish a symmetric key.
> 
> I hope we a re close to closure on this one....
> 
> Russ
> 

From: "Laudon Williams" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: RE: key usage - key encipherment or data encipherment
Date: Thu, 12 May 2005 20:26:54 -0700
Sender: [email-masked]

Simply an observation, not a disagreement.

Unfortunately, the keyEncipherment bit has grown to be used for both key
encipherment and data encipherment. I see this a lot, especially with
field-level encryption in databases, and encryption of small data files.

I guess what I'm getting at is that I never see certificates with the
dataEncipherment bit set in it in actual use, but I come across lots of
places when data is encrypted with the private key.

With that said, I like the text below.

-Laudon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ Housley
Sent: Thursday, May 12, 2005 12:21 PM
To: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment

There has been a whole lot of discussion about these paragraphs.  Since 
some of the discussion has not been CCed to the PKIX mail list, I am 
posting the resulting words.

      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering private or secret keys, i.e., for key transport.
      For example, this bit shall be set when a RSA public key is to be
      used for encrypting a symmetric content-decryption key or an
      asymmetric private key.

     The dataEncipherment bit is asserted when the subject public key
     is used for directly enciphering raw user data without the use of
     an intermediate symmetric cipher. Note that the use of this
     bit is extremely uncommon; almost all applications use
     key transport or key agreement to establish a symmetric key.

I hope we a re close to closure on this one....

Russ

Date: Fri, 13 May 2005 11:19:20 +1000
From: "Simon McMahon" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: key usage - key encipherment or data encipherment
Sender: [email-masked]

Sorry but I think this new text is just more jargon and does not address the problem. The problem is that there are 2 bits for encryption instead of 1 so people can make a choice and need direction in that choice, but will still get it wrong anyway, just because they can (Murphy). The misunderstanding is that "keyEncipherment" is nearly always the correct choice but sometimes people use "dataEncipherment" because the transport keys are not explicit.

Note that a new definition of a public key cipher RSA' that internally used "RSA+AES" but didn't publish that fact could have RSA' public keys (not RSA keys but internally identical to them) that directly encrypt large amounts of data. The transport key just blends into the cipher text. "dataEncipherment" is then the correct bit for the RSA' key but I'll bet people who know its really RSA+AES will use "keyEncipherment" because that is what is really happening.

The bottom line is that this problem will never go away as long as you have two bits whose meanings overlap like these ones do. The bits should be merged because CA's that know about interoperability issues just set both anyway. I would prefer a consolidation these flags and to deprecate "dataEncipherment". That would leave "keyEncipherment" that could be renamed to "encipherment". Then there is no confusion because there is no choice anymore.

Anyway, back to the text...

Why did the "private" key creep into this description? "Private" keys are also "secret". By the way, how does a public key encrypt a private key? It is impossible, at least with RSA without a symmetric key in there, unless the private key is a lot smaller. The latest proposed text example specifies "content-decryption" now but symmetric keys exchanged this way can also be for encryption too. Also, the symmetric key encrypted by the public key was in fact an encryption key when the originator used it.

Proposed rewording preserving both bits:
"
The keyEncipherment bit is asserted when the subject public key is used for transport of a secret key or data encryption using an intermediate secret key. For example, when a public key is to be used to encrypt a secret cipher key that will encrypt some data or key, then this bit shall asserted.

The dataEncipherment bit is asserted when the subject public key is used for directly enciphering user data other than cryptographic keys.
"

Proposed rewording with only one bit:
"
The dataEncipherment bit is deprecated. If asserted then this bit now has the same meaning as keyEncipherment. The keyEncipherment bit is renamed to "encipherment" and is asserted when either of the previous bits were asserted. Whenever a public key is used to encrypt data or keys then this bit shall be asserted.
"

Regards,

Simon McMahon.

Simon McMahon

Work: (07) 31311420
Mobile: (043) 2294180

>>> Sharon Boeyen <[email-masked]> 05/13/05 05:44am >>>
I like the proposed text also. My only suggestion is could we add
"symmetric" in the sentence for dataEncipherment, so it would read "...
without the use of an intermediate symmetric key." I don't feel strongly
about this but do think it helps with the clarity.

Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ Housley
Sent: Thursday, May 12, 2005 11:22 AM
To: Denis Pinkas
Cc: [email-masked] 
Subject: Re: key usage - key encipherment or data encipherment

Denis:

Thanks.  I think you suggestion improves the text.

Russ

At 10:44 AM 5/12/2005, Denis Pinkas wrote:
>Russ,
>
>>Since we are working on an update to RFC 3280, I propose the following
>>revisions to these descritions.
>
>>      The keyEncipherment bit is asserted when the subject public key is
>>      used for key transport.  For example, when an RSA key is to be
>>      used for key management by encrypting a symmetric content-encryption
>>      key, then this bit shall asserted.
>>      The dataEncipherment bit is asserted when the subject public key
>>      is used for directly enciphering raw user data without the use of
>>      an intermediate symmetric cipher.
>
>Thank you for this strawman proposal. I would rather propose:
>
>       The keyEncipherment bit is asserted when the subject public key is
>       used for enciphering private or secret keys, i.e. for key transport.
>       For example, this bit shall be set when a public RSA key is to be
>       used for encrypting a symmetric content-decryption key or an
>       asymmetric private key.
>
>       The dataEncipherment bit is asserted when the subject public key
>       is used for directly enciphering raw user data without the use of
>       an intermediate key.
>
>Reasons:
>
>a) "Key transport" is not explicit enough. The purpose is to encipher
>either a private key or a secret key.
>
>b) The example is not clear enough: "RSA key" can be a private key or a
>public key, hence why "public" has been added.
>
>c) The key that is communicated is a decryption key rather than an
>encryption key, hence why "content-encryption" has been changed into 
>"content-decryption".
>
>d) The example has been extended to cover the case of an asymmetric 
>cipher
>as well.
>
>e) In the last statement, the intermediate key would not necessarily be 
>a
>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" 
>has been replaced by "key'.
>
>Note that the current text from X.509 is:
>
>   c) keyEncipherment: for enciphering keys or other security information,
>      e.g. for key transport;
>
>   d) dataEncipherment: for enciphering user data, but not keys or other
>      security information as in c) above;
>
>Denis

***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************

From: Sharon Boeyen <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: RE: key usage - key encipherment or data encipherment
Date: Thu, 12 May 2005 15:44:53 -0400
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.

------_=_NextPart_001_01C5572A.CD40DDF9
Content-Type: text/plain

I like the proposed text also. My only suggestion is could we add
"symmetric" in the sentence for dataEncipherment, so it would read "...
without the use of an intermediate symmetric key." I don't feel strongly
about this but do think it helps with the clarity.

Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ Housley
Sent: Thursday, May 12, 2005 11:22 AM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment

Denis:

Thanks.  I think you suggestion improves the text.

Russ

At 10:44 AM 5/12/2005, Denis Pinkas wrote:
>Russ,
>
>>Since we are working on an update to RFC 3280, I propose the following
>>revisions to these descritions.
>
>>      The keyEncipherment bit is asserted when the subject public key is
>>      used for key transport.  For example, when an RSA key is to be
>>      used for key management by encrypting a symmetric content-encryption
>>      key, then this bit shall asserted.
>>      The dataEncipherment bit is asserted when the subject public key
>>      is used for directly enciphering raw user data without the use of
>>      an intermediate symmetric cipher.
>
>Thank you for this strawman proposal. I would rather propose:
>
>       The keyEncipherment bit is asserted when the subject public key is
>       used for enciphering private or secret keys, i.e. for key transport.
>       For example, this bit shall be set when a public RSA key is to be
>       used for encrypting a symmetric content-decryption key or an
>       asymmetric private key.
>
>       The dataEncipherment bit is asserted when the subject public key
>       is used for directly enciphering raw user data without the use of
>       an intermediate key.
>
>Reasons:
>
>a) "Key transport" is not explicit enough. The purpose is to encipher
>either a private key or a secret key.
>
>b) The example is not clear enough: "RSA key" can be a private key or a
>public key, hence why "public" has been added.
>
>c) The key that is communicated is a decryption key rather than an
>encryption key, hence why "content-encryption" has been changed into 
>"content-decryption".
>
>d) The example has been extended to cover the case of an asymmetric 
>cipher
>as well.
>
>e) In the last statement, the intermediate key would not necessarily be 
>a
>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" 
>has been replaced by "key'.
>
>Note that the current text from X.509 is:
>
>   c) keyEncipherment: for enciphering keys or other security information,
>      e.g. for key transport;
>
>   d) dataEncipherment: for enciphering user data, but not keys or other
>      security information as in c) above;
>
>Denis

------_=_NextPart_001_01C5572A.CD40DDF9
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: key usage - key encipherment or data encipherment</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I like the proposed text also. My only suggestion is =
could we add &quot;symmetric&quot; in the sentence for =
dataEncipherment, so it would read &quot;... without the use of an =
intermediate symmetric key.&quot; I don't feel strongly about this but =
do think it helps with the clarity.</FONT></P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Sharon</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail=
.imc.org</A>] On Behalf Of Russ Housley</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 12, 2005 11:22 AM</FONT>
<BR><FONT SIZE=3D2>To: Denis Pinkas</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: key usage - key encipherment or data =
encipherment</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Denis:</FONT>
</P>

<P><FONT SIZE=3D2>Thanks.&nbsp; I think you suggestion improves the =
text.</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>

<P><FONT SIZE=3D2>At 10:44 AM 5/12/2005, Denis Pinkas wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;Russ,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;Since we are working on an update to RFC =
3280, I propose the following</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;revisions to these descritions.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
keyEncipherment bit is asserted when the subject public key is</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for key =
transport.&nbsp; For example, when an RSA key is to be</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for key =
management by encrypting a symmetric content-encryption</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; key, then =
this bit shall asserted.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
dataEncipherment bit is asserted when the subject public key</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is used for =
directly enciphering raw user data without the use of</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an =
intermediate symmetric cipher.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Thank you for this strawman proposal. I would =
rather propose:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
keyEncipherment bit is asserted when the subject public key is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for =
enciphering private or secret keys, i.e. for key transport.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For =
example, this bit shall be set when a public RSA key is to be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for =
encrypting a symmetric content-decryption key or an</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; asymmetric =
private key.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The =
dataEncipherment bit is asserted when the subject public key</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is used for =
directly enciphering raw user data without the use of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; an =
intermediate key.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Reasons:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;a) &quot;Key transport&quot; is not explicit =
enough. The purpose is to encipher</FONT>
<BR><FONT SIZE=3D2>&gt;either a private key or a secret key.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;b) The example is not clear enough: &quot;RSA =
key&quot; can be a private key or a</FONT>
<BR><FONT SIZE=3D2>&gt;public key, hence why &quot;public&quot; has =
been added.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;c) The key that is communicated is a decryption =
key rather than an</FONT>
<BR><FONT SIZE=3D2>&gt;encryption key, hence why =
&quot;content-encryption&quot; has been changed into </FONT>
<BR><FONT SIZE=3D2>&gt;&quot;content-decryption&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;d) The example has been extended to cover the =
case of an asymmetric </FONT>
<BR><FONT SIZE=3D2>&gt;cipher</FONT>
<BR><FONT SIZE=3D2>&gt;as well.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;e) In the last statement, the intermediate key =
would not necessarily be </FONT>
<BR><FONT SIZE=3D2>&gt;a</FONT>
<BR><FONT SIZE=3D2>&gt;symmetric cipher, hence why =
&quot;symmetric&quot; has been deleted. Also &quot;cipher&quot; </FONT>
<BR><FONT SIZE=3D2>&gt;has been replaced by &quot;key'.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Note that the current text from X.509 is:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; c) keyEncipherment: for enciphering =
keys or other security information,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; e.g. for key =
transport;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; d) dataEncipherment: for =
enciphering user data, but not keys or other</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; security =
information as in c) above;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Denis</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5572A.CD40DDF9--

Date: Thu, 12 May 2005 15:21:02 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

There has been a whole lot of discussion about these paragraphs.  Since 
some of the discussion has not been CCed to the PKIX mail list, I am 
posting the resulting words.

      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering private or secret keys, i.e., for key transport.
      For example, this bit shall be set when a RSA public key is to be
      used for encrypting a symmetric content-decryption key or an
      asymmetric private key.

     The dataEncipherment bit is asserted when the subject public key
     is used for directly enciphering raw user data without the use of
     an intermediate symmetric cipher. Note that the use of this
     bit is extremely uncommon; almost all applications use
     key transport or key agreement to establish a symmetric key.

I hope we a re close to closure on this one....

Russ

Reply-To: "todd glassey" <[email-masked]>
From: "todd glassey" <[email-masked]>
To: <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Date: Thu, 12 May 2005 11:04:39 -0700
Sender: [email-masked]

Hmmm - The person you are writing for is an IT Auditor because there is NO
PKI system that is ever going to be deployed commercially from say 9/11
onward and especially after SOX that is going not have an Auditor's
Approval. That means something I tried to get this WG to think about several
years ago and that was Practice or Use Models for the IP's themselves.

Todd Glassey, CISM, CIFI

----- Original Message ----- 
From: "Dino Esposito" <[email-masked]>
To: "Sam Roberts" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 12, 2005 9:25 AM
Subject: Re: key usage - key encipherment or data encipherment

>
> IMO, the typical reader of a RFC is a technician. Especially for a RFC
> full of PKI jargon.
> If we wanted to write for a layman reader, we should write an encyclopedia
> I think the Pinkas' proposal is quite clear.
>
> Dino Esposito
>
> Sam Roberts wrote:
>
> >Wrote Denis Pinkas <[email-masked]>, on Thu, May 12, 2005 at
04:44:28PM +0200:
> >
> >
> >>Russ,
> >>
> >>
> >>
> >>>Since we are working on an update to RFC 3280, I propose the following
> >>>revisions to these descritions.
> >>>
> >>>
> >>>    The keyEncipherment bit is asserted when the subject public key is
> >>>    used for key transport.  For example, when an RSA key is to be
> >>>    used for key management by encrypting a symmetric
content-encryption
> >>>    key, then this bit shall asserted.
> >>>
> >>>    The dataEncipherment bit is asserted when the subject public key
> >>>    is used for directly enciphering raw user data without the use of
> >>>    an intermediate symmetric cipher.
> >>>
> >>>
> >>Thank you for this strawman proposal. I would rather propose:
> >>
> >>      The keyEncipherment bit is asserted when the subject public key is
> >>      used for enciphering private or secret keys, i.e. for key
transport.
> >>      For example, this bit shall be set when a public RSA key is to be
> >>      used for encrypting a symmetric content-decryption key or an
> >>      asymmetric private key.
> >>
> >>
> >
> >Hi Denis,
> >
> >I think this text has the same problem as the current. In other words,
> >somebody might read it and think "I'm not encrypting a key, I'm
> >encrypting email, and I'm "transporting" a word document, not a key, so
> >this isn't the bit I should look for". This is what happens now.
> >
> >I can't think of appropriate wording, but if the goal is to make it
> >clear to non-security experts so the bit is used consistently, a little
> >bit more explanation is needed.
> >
> >
> >
> >>      The dataEncipherment bit is asserted when the subject public key
> >>      is used for directly enciphering raw user data without the use of
> >>      an intermediate key.
> >>
> >>
> >
> >This is clear, I think.
> >
> >Cheers,
> >Sam
> >
> >
> >
> >>Reasons:
> >>
> >>a) "Key transport" is not explicit enough. The purpose is to encipher
> >>either a private key or a secret key.
> >>
> >>b) The example is not clear enough: "RSA key" can be a private key or a
> >>public key, hence why "public" has been added.
> >>
> >>c) The key that is communicated is a decryption key rather than an
> >>encryption key, hence why "content-encryption" has been changed into
> >>"content-decryption".
> >>
> >>d) The example has been extended to cover the case of an asymmetric
cipher
> >>as well.
> >>
> >>e) In the last statement, the intermediate key would not necessarily be
a
> >>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher"
has
> >>been replaced by "key'.
> >>
> >>Note that the current text from X.509 is:
> >>
> >>  c) keyEncipherment: for enciphering keys or other security
information,
> >>     e.g. for key transport;
> >>
> >>  d) dataEncipherment: for enciphering user data, but not keys or other
> >>     security information as in c) above;
> >>
> >>Denis
> >>
> >>
> >>
> >>>Russ
> >>>
> >>>At 10:14 PM 5/11/2005, Simon McMahon wrote:
> >>>
> >>>
> >>>
> >>>>Russ,
> >>>>
> >>>>They were calling an 'encrypt' function to encrypt XML data and they
> >>>>gave it an RSA key (the cert actually) to do it. Of course it
> >>>>internally made an AES key but they never saw it until the
> >>>>interoperability issue made them look. From what they saw at the level
> >>>>they were looking the interpretation was reasonable. When the
> >>>>transport key is well hidden and simply part of the protocol then it
> >>>>looks just like RSA is encrypting big slabs of data. If you know that
> >>>>RSA is bound by the modulus size then you know what is really
> >>>>happening but not all users of PKI know RSA so well. Why should they?
> >>>>
> >>>>Couple this interpretation of key-usage with a dubious decision to
> >>>>reject encryption requests with certs that dont have key-usage='data
> >>>>encipherment' and you have an interoperability problem. I say
> >>>>"dubious" because it is a public key so you cannot enforce usage
> >>>>policy anyway. The CA could set both flags to fix it, which by the way
> >>>>was the vendors preferred solution, but its not my CA or their CA and
> >>>>the CA doesn't do that. Why should they?
> >>>>
> >>>>This reference, in my opinion, allows the ambiguous interpretation:
> >>>>
> >>>>
> >>>>>    The keyEncipherment bit is asserted when the subject public key
is
> >>>>>     used for key transport.  For example, when an RSA key is to be
> >>>>>     used for key management, then this bit shall asserted.
> >>>>>
> >>>>>     The dataEncipherment bit is asserted when the subject public key
> >>>>>     is used for enciphering user data, other than cryptographic
keys.
> >>>>>
> >>>>>
> >>>>In this case the public key is clearly "intended" to be used to
> >>>>encrypt the XML data but it just doesn't do it directly because it
> >>>>cant. The term "key management" also has associations with more basic
> >>>>and explicit key management operations like installing trusted root
> >>>>certs or secure installation of shared secret keys etc. In this case
> >>>>it is much less obvious that key management is happening because the
> >>>>key is bundled with the data. It looks just like the public key is
> >>>>encrypting the data.
> >>>>
> >>>>In my opinion there are 3 cases presented as 2 in the RFC.
> >>>>1. RSA encrypts data - hardly ever used.
> >>>>2. RSA implicitly encrypts keys so it can really encrypt bulk data -
> >>>>common usage.
> >>>>3. RSA explicitly encrypts keys for explicit key management functions
> >>>>- common usage.
> >>>>The current bits separate 1 from 2/3 yet people make the
> >>>>interpretation that they split the more common 2 from 3 assuming 1 and
> >>>>2 are the same thing. Knowledge of RSA is required to know that 1 and
> >>>>2 are different.
> >>>>
> >>>>Peter's comment "This bit MUST NOT be set when the intention is to
> >>>>encipher intermediate cryptographic keys rather than raw user data" is
> >>>>most relevant in my case. Does PKIX support this clarification?
> >>>>
> >>>>In my opinion this problem will not entirely go away by clarifying the
> >>>>standard because most people dont read it before they implement
> >>>>something. The two bits are there and as long as they are both there
> >>>>then the mistake will be made by busy developers. Unenforceable
> >>>>key-usage policy, to "public" keys, will also continue to be
> >>>>implemented. People will come looking for clarification once they have
> >>>>an interoperability issue but by then it is often too late - the issue
> >>>>usually gets decided by who has the biggest corporate balls. In this
> >>>>case it wasn't too late so thanks for the assistance.
> >>>>
> >>>>If I could recommend a change to the standard then I would suggest
> >>>>dropping one of the encryption bits and just have a single key-usage =
> >>>>"encryption". Give it the value the same as "key-encryption" since
> >>>>this is the common usage.
> >>>>
> >>>>Thanks,
> >>>>
> >>>>Simon McMahon.
> >>>>
> >>>>
> >>>>Simon McMahon
> >>>>
> >>>>Work: (07) 31311420
> >>>>Mobile: (043) 2294180
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>>Russ Housley <[email-masked]> 05/12/05 01:06am >>>
> >>>>>>>
> >>>>>>>
> >>>>Simon:
> >>>>
> >>>>If they are encrypting the XML data directly with the RSA key (which
is
> >>>>very unlikely), then they are correct.
> >>>>
> >>>>The traditional way to handle this is to generate a random
> >>>>content-encryption key (CEK) and then encrypt the XML data with a
> >>>>symmetric algorithm using the CEK.  The CEK is encrypted with the RSA
> >>>>key from the certificate.  Thus, the RSA key is really being used to
> >>>>encrypt only
> >>>>symmetric keys.
> >>>>
> >>>>Russ
> >>>>
> >>>> At 08:33 PM 5/10/2005, Simon McMahon wrote:
> >>>>
> >>>>
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>I have had a recent interoperability issue with a application vendor
> >>>>>
> >>>>>
> >>>>that >didn't like the key-usage attributes in a cert from a CA
vendor's
> >>>>
> >>>>
> >>>>>certificate. Signing certs work fine, it was an encryption cert that
> >>>>>
> >>>>>
> >>>>failed.
> >>>>
> >>>>
> >>>>>CA sets key-usage = "key encipherment".
> >>>>>Application wants to encrypt some XML data so looks for key-usage =
> >>>>>
> >>>>>
> >>>>"data
> >>>>
> >>>>
> >>>>>encipherment". Reason - because XML is data, not a key.
> >>>>>
> >>>>>I believe the application vendor is wrong and I explained that the
> >>>>>
> >>>>>
> >>>>RSA key >actually encrypts an AES key so it doesn't directly encrypt
> >>>>the data but >they want an official "pkix" ruling based on the
> >>>>standard so can someone >please refer me to a statement in the
> >>>>standard that clears this up.
> >>>>
> >>>>
> >>>>>Thanks,
> >>>>>
> >>>>>Simon McMahon.
> >>>>>
> >>>>>
> >>>>>
> >>>>>Simon McMahon
> >>>>>
> >>>>>Work: (07) 31311420
> >>>>>Mobile: (043) 2294180
> >>>>>
> >>>>>
> >>>>>
> >>>>>Simon McMahon
> >>>>>
> >>>>>Work: (07) 31311420
> >>>>>Mobile: (043) 2294180
> >>>>>
> >>>>>
> >>>>>
> >>>>>
>
>>>>>***********************************************************************
**
> >>>>>
> >>>>>
> >>>>**********
> >>>>
> >>>>
> >>>>>This email, including any attachments sent with it, is confidential
and
> >>>>>for the sole use of the intended recipient(s).  This confidentiality
is
> >>>>>not waived or lost, if you receive it and you are not the intended
> >>>>>recipient(s), or if it is transmitted/received in error.
> >>>>>
> >>>>>Any unauthorised use, alteration, disclosure, distribution or review
of
> >>>>>this email is prohibited.  It may be subject to a statutory duty of
> >>>>>confidentiality if it relates to health service matters.
> >>>>>
> >>>>>If you are not the intended recipient(s), or if you have received
this
> >>>>>email in error, you are asked to immediately notify the sender by
> >>>>>telephone or by return email.  You should also delete this email and
> >>>>>destroy any hard copies produced.
>
>>>>>***********************************************************************
**
> >>>>>
> >>>>>
> >>>>**********
> >>>>
> >>>>
> >>>>
>
>>>>************************************************************************
***********
> >>>>
> >>>>This email, including any attachments sent with it, is confidential
> >>>>and for the sole use of the intended recipient(s).  This
> >>>>confidentiality is not waived or lost, if you receive it and you are
> >>>>not the intended recipient(s), or if it is transmitted/received in
error.
> >>>>
> >>>>Any unauthorised use, alteration, disclosure, distribution or review
> >>>>of this email is prohibited.  It may be subject to a statutory duty of
> >>>>confidentiality if it relates to health service matters.
> >>>>
> >>>>If you are not the intended recipient(s), or if you have received this
> >>>>email in error, you are asked to immediately notify the sender by
> >>>>telephone or by return email.  You should also delete this email and
> >>>>destroy any hard copies produced.
>
>>>>************************************************************************
***********

Date: Thu, 12 May 2005 13:46:41 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

Wrote Dino Esposito <[email-masked]>, on Thu, May 12, 2005 at 06:25:38PM +0200:
> IMO, the typical reader of a RFC is a technician. Especially for a RFC 
> full of PKI jargon.

Many of the PKI flags are sufficiently succinctly subscribed that they
have been interpreted differently by "technicians". Didn't an earlier
poster recount an experience with a *certificate authority* that had
been using the wrong flag?  If an issuer of certs doesn't get it, then
its not clear enough, IMHO. Making it clear enough that this
conversation doesn't have to happen again would be useful. It helps none
of us if people who (arguably) don't know enough about pki/crypto deploy
systems wrongly, because we get asked to interop with them.

My 2 cents.

> If we wanted to write for a layman reader, we should write an encyclopedia

Its always a balance, but when interop has failed to occur, perhaps we
need to be more encyclopedic.

> I think the Pinkas' proposal is quite clear.

You probably understood the original text, too.

Cheers,
Sam

> Dino Esposito
> 
> Sam Roberts wrote:
> 
> >Wrote Denis Pinkas <[email-masked]>, on Thu, May 12, 2005 at 
> >04:44:28PM +0200:
> > 
> >
> >>Russ,
> >>
> >>   
> >>
> >>>Since we are working on an update to RFC 3280, I propose the following 
> >>>revisions to these descritions.
> >>>     
> >>>
> >>>   The keyEncipherment bit is asserted when the subject public key is
> >>>   used for key transport.  For example, when an RSA key is to be
> >>>   used for key management by encrypting a symmetric content-encryption
> >>>   key, then this bit shall asserted.
> >>>
> >>>   The dataEncipherment bit is asserted when the subject public key
> >>>   is used for directly enciphering raw user data without the use of
> >>>   an intermediate symmetric cipher.
> >>>     
> >>>
> >>Thank you for this strawman proposal. I would rather propose:
> >>
> >>     The keyEncipherment bit is asserted when the subject public key is
> >>     used for enciphering private or secret keys, i.e. for key transport.
> >>     For example, this bit shall be set when a public RSA key is to be
> >>     used for encrypting a symmetric content-decryption key or an
> >>     asymmetric private key.
> >>   
> >>
> >
> >Hi Denis,
> >
> >I think this text has the same problem as the current. In other words,
> >somebody might read it and think "I'm not encrypting a key, I'm
> >encrypting email, and I'm "transporting" a word document, not a key, so
> >this isn't the bit I should look for". This is what happens now.
> >
> >I can't think of appropriate wording, but if the goal is to make it
> >clear to non-security experts so the bit is used consistently, a little
> >bit more explanation is needed.
> >
> > 
> >
> >>     The dataEncipherment bit is asserted when the subject public key
> >>     is used for directly enciphering raw user data without the use of
> >>     an intermediate key.
> >>   
> >>
> >
> >This is clear, I think.
> >
> >Cheers,
> >Sam
> >
> > 
> >
> >>Reasons:
> >>
> >>a) "Key transport" is not explicit enough. The purpose is to encipher 
> >>either a private key or a secret key.
> >>
> >>b) The example is not clear enough: "RSA key" can be a private key or a 
> >>public key, hence why "public" has been added.
> >>
> >>c) The key that is communicated is a decryption key rather than an 
> >>encryption key, hence why "content-encryption" has been changed into 
> >>"content-decryption".
> >>
> >>d) The example has been extended to cover the case of an asymmetric 
> >>cipher as well.
> >>
> >>e) In the last statement, the intermediate key would not necessarily be a 
> >>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" 
> >>has been replaced by "key'.
> >>
> >>Note that the current text from X.509 is:
> >>
> >> c) keyEncipherment: for enciphering keys or other security information,
> >>    e.g. for key transport;
> >>
> >> d) dataEncipherment: for enciphering user data, but not keys or other
> >>    security information as in c) above;
> >>
> >>Denis
> >>
> >>   
> >>
> >>>Russ
> >>>
> >>>At 10:14 PM 5/11/2005, Simon McMahon wrote:
> >>>
> >>>     
> >>>
> >>>>Russ,
> >>>>
> >>>>They were calling an 'encrypt' function to encrypt XML data and they 
> >>>>gave it an RSA key (the cert actually) to do it. Of course it 
> >>>>internally made an AES key but they never saw it until the 
> >>>>interoperability issue made them look. From what they saw at the level 
> >>>>they were looking the interpretation was reasonable. When the 
> >>>>transport key is well hidden and simply part of the protocol then it 
> >>>>looks just like RSA is encrypting big slabs of data. If you know that 
> >>>>RSA is bound by the modulus size then you know what is really 
> >>>>happening but not all users of PKI know RSA so well. Why should they?
> >>>>
> >>>>Couple this interpretation of key-usage with a dubious decision to 
> >>>>reject encryption requests with certs that dont have key-usage='data 
> >>>>encipherment' and you have an interoperability problem. I say 
> >>>>"dubious" because it is a public key so you cannot enforce usage 
> >>>>policy anyway. The CA could set both flags to fix it, which by the way 
> >>>>was the vendors preferred solution, but its not my CA or their CA and 
> >>>>the CA doesn't do that. Why should they?
> >>>>
> >>>>This reference, in my opinion, allows the ambiguous interpretation:
> >>>>       
> >>>>
> >>>>>   The keyEncipherment bit is asserted when the subject public key is
> >>>>>    used for key transport.  For example, when an RSA key is to be
> >>>>>    used for key management, then this bit shall asserted.
> >>>>>
> >>>>>    The dataEncipherment bit is asserted when the subject public key
> >>>>>    is used for enciphering user data, other than cryptographic keys.
> >>>>>         
> >>>>>
> >>>>In this case the public key is clearly "intended" to be used to 
> >>>>encrypt the XML data but it just doesn't do it directly because it 
> >>>>cant. The term "key management" also has associations with more basic 
> >>>>and explicit key management operations like installing trusted root 
> >>>>certs or secure installation of shared secret keys etc. In this case 
> >>>>it is much less obvious that key management is happening because the 
> >>>>key is bundled with the data. It looks just like the public key is 
> >>>>encrypting the data.
> >>>>
> >>>>In my opinion there are 3 cases presented as 2 in the RFC.
> >>>>1. RSA encrypts data - hardly ever used.
> >>>>2. RSA implicitly encrypts keys so it can really encrypt bulk data - 
> >>>>common usage.
> >>>>3. RSA explicitly encrypts keys for explicit key management functions 
> >>>>- common usage.
> >>>>The current bits separate 1 from 2/3 yet people make the 
> >>>>interpretation that they split the more common 2 from 3 assuming 1 and 
> >>>>2 are the same thing. Knowledge of RSA is required to know that 1 and 
> >>>>2 are different.
> >>>>
> >>>>Peter's comment "This bit MUST NOT be set when the intention is to 
> >>>>encipher intermediate cryptographic keys rather than raw user data" is 
> >>>>most relevant in my case. Does PKIX support this clarification?
> >>>>
> >>>>In my opinion this problem will not entirely go away by clarifying the 
> >>>>standard because most people dont read it before they implement 
> >>>>something. The two bits are there and as long as they are both there 
> >>>>then the mistake will be made by busy developers. Unenforceable 
> >>>>key-usage policy, to "public" keys, will also continue to be 
> >>>>implemented. People will come looking for clarification once they have 
> >>>>an interoperability issue but by then it is often too late - the issue 
> >>>>usually gets decided by who has the biggest corporate balls. In this 
> >>>>case it wasn't too late so thanks for the assistance.
> >>>>
> >>>>If I could recommend a change to the standard then I would suggest 
> >>>>dropping one of the encryption bits and just have a single key-usage = 
> >>>>"encryption". Give it the value the same as "key-encryption" since 
> >>>>this is the common usage.
> >>>>
> >>>>Thanks,
> >>>>
> >>>>Simon McMahon.
> >>>>
> >>>>
> >>>>Simon McMahon
> >>>>
> >>>>Work: (07) 31311420
> >>>>Mobile: (043) 2294180
> >>>>
> >>>>
> >>>>       
> >>>>
> >>>>>>>Russ Housley <[email-masked]> 05/12/05 01:06am >>>
> >>>>>>>             
> >>>>>>>
> >>>>Simon:
> >>>>
> >>>>If they are encrypting the XML data directly with the RSA key (which is
> >>>>very unlikely), then they are correct.
> >>>>
> >>>>The traditional way to handle this is to generate a random
> >>>>content-encryption key (CEK) and then encrypt the XML data with a 
> >>>>symmetric algorithm using the CEK.  The CEK is encrypted with the RSA 
> >>>>key from the certificate.  Thus, the RSA key is really being used to 
> >>>>encrypt only
> >>>>symmetric keys.
> >>>>
> >>>>Russ
> >>>>
> >>>>At 08:33 PM 5/10/2005, Simon McMahon wrote:
> >>>>
> >>>>       
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>I have had a recent interoperability issue with a application vendor 
> >>>>>         
> >>>>>
> >>>>that >didn't like the key-usage attributes in a cert from a CA vendor's
> >>>>       
> >>>>
> >>>>>certificate. Signing certs work fine, it was an encryption cert that 
> >>>>>         
> >>>>>
> >>>>failed.
> >>>>       
> >>>>
> >>>>>CA sets key-usage = "key encipherment".
> >>>>>Application wants to encrypt some XML data so looks for key-usage = 
> >>>>>         
> >>>>>
> >>>>"data
> >>>>       
> >>>>
> >>>>>encipherment". Reason - because XML is data, not a key.
> >>>>>
> >>>>>I believe the application vendor is wrong and I explained that the 
> >>>>>         
> >>>>>
> >>>>RSA key >actually encrypts an AES key so it doesn't directly encrypt 
> >>>>the data but >they want an official "pkix" ruling based on the 
> >>>>standard so can someone >please refer me to a statement in the 
> >>>>standard that clears this up.
> >>>>       
> >>>>
> >>>>>Thanks,
> >>>>>
> >>>>>Simon McMahon.
> >>>>>
> >>>>>
> >>>>>
> >>>>>Simon McMahon
> >>>>>
> >>>>>Work: (07) 31311420
> >>>>>Mobile: (043) 2294180
> >>>>>
> >>>>>
> >>>>>
> >>>>>Simon McMahon
> >>>>>
> >>>>>Work: (07) 31311420
> >>>>>Mobile: (043) 2294180
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>************************************************************************* 
> >>>>>         
> >>>>>
> >>>>**********
> >>>>       
> >>>>
> >>>>>This email, including any attachments sent with it, is confidential and
> >>>>>for the sole use of the intended recipient(s).  This confidentiality is
> >>>>>not waived or lost, if you receive it and you are not the intended
> >>>>>recipient(s), or if it is transmitted/received in error.
> >>>>>
> >>>>>Any unauthorised use, alteration, disclosure, distribution or review of
> >>>>>this email is prohibited.  It may be subject to a statutory duty of
> >>>>>confidentiality if it relates to health service matters.
> >>>>>
> >>>>>If you are not the intended recipient(s), or if you have received this
> >>>>>email in error, you are asked to immediately notify the sender by
> >>>>>telephone or by return email.  You should also delete this email and
> >>>>>destroy any hard copies produced.
> >>>>>************************************************************************* 
> >>>>>         
> >>>>>
> >>>>**********
> >>>>
> >>>>
> >>>>
> >>>>*********************************************************************************** 
> >>>>
> >>>>This email, including any attachments sent with it, is confidential 
> >>>>and for the sole use of the intended recipient(s).  This 
> >>>>confidentiality is not waived or lost, if you receive it and you are 
> >>>>not the intended recipient(s), or if it is transmitted/received in 
> >>>>error.
> >>>>
> >>>>Any unauthorised use, alteration, disclosure, distribution or review 
> >>>>of this email is prohibited.  It may be subject to a statutory duty of 
> >>>>confidentiality if it relates to health service matters.
> >>>>
> >>>>If you are not the intended recipient(s), or if you have received this 
> >>>>email in error, you are asked to immediately notify the sender by 
> >>>>telephone or by return email.  You should also delete this email and 
> >>>>destroy any hard copies produced.
> >>>>*********************************************************************************** 
> >>>>
> >>>>       
> >>>>
> >>>
> >>>     
> >>>
> >
> > 
> >

-- 
http://www.certicom.com

Date: Thu, 12 May 2005 10:27:27 -0700
To: Jean-Marc Desperrier <[email-masked]>
From: Hoyt L Kesterson II <[email-masked]>
Subject: Re: Technical Corrigenda 3 to the 4th edition of X.509
Cc: pkix <[email-masked]>
Sender: [email-masked]

i apologize for the name problem

This is approved text with no posibility of change except by subsequent defect report or amendment.

Denis Pinkas was very active in the several ballots held on this document over the last few years as well as several other PKIX participants. Your comments would have been appreciated and considered during that period but cannot now be applied to the document that has had approval within ISO and ITU.

    hoyt

At 14:40 +0200 5/12/05, Jean-Marc Desperrier wrote:
>Hoyt L Kesterson II wrote:
>
>>Some you worked with the X.509 standards committee over the last few years revising the text on key usage.
>>
>>You can find the text of that Technical Corrigenda at:
>>ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8|X.509-TC3(4th).pdf
>
>You should avoid using characters in the filename that are not compatible with the Microsoft OS, it makes it harder to download that file.
>
>From the text :
>"Bits in the KeyUsage type are as follows:
>[...]
>c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport;
>d) dataEncipherment: for enciphering user data, but not keys or other security information as in c) above;
>e) keyAgreement: for use as a public key agreement key;"
>
>It's not yet very precise. The contentCommitment bit text got very clear, so it shows how much we can improve on those bits.
>
>The text by Peter is quite good, how about :
>
>c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport, and also data encryption that uses an intermediate symmetric cipher;
>d) dataEncipherment: for directly enciphering raw user data, without the use of an intermediate symmetric cipher
>e) keyAgreement: for use as a public key agreement key, for example a Diffie-Hellman protocol key;
>
>Shouldn't we best find a way to say that an SSL client requires at a minimum only digitalSignature, but the SSL server must have keyEncipherment ?
>
>Maybe we should precise :
>In practice when someone wishes to send enciphered key or security information, he must check that the recipient has the keyEncipherment bit set before using his public key to encipher. For example in an SSL handshake, the client must check that the server has the keyEncipherment bit set before sending him an enciphered secret, but never needs to have that bit set in his own certificate, because the server will use his certificate only for authentification, not to send enciphered data.

Date: Thu, 12 May 2005 18:25:38 +0200
From: Dino Esposito <[email-masked]>
To: Sam Roberts <[email-masked]>
CC: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

IMO, the typical reader of a RFC is a technician. Especially for a RFC 
full of PKI jargon.
If we wanted to write for a layman reader, we should write an encyclopedia
I think the Pinkas' proposal is quite clear.

Dino Esposito

Sam Roberts wrote:

>Wrote Denis Pinkas <[email-masked]>, on Thu, May 12, 2005 at 04:44:28PM +0200:
>  
>
>>Russ,
>>
>>    
>>
>>>Since we are working on an update to RFC 3280, I propose the following 
>>>revisions to these descritions.
>>>      
>>>
>>>    The keyEncipherment bit is asserted when the subject public key is
>>>    used for key transport.  For example, when an RSA key is to be
>>>    used for key management by encrypting a symmetric content-encryption
>>>    key, then this bit shall asserted.
>>>
>>>    The dataEncipherment bit is asserted when the subject public key
>>>    is used for directly enciphering raw user data without the use of
>>>    an intermediate symmetric cipher.
>>>      
>>>
>>Thank you for this strawman proposal. I would rather propose:
>>
>>      The keyEncipherment bit is asserted when the subject public key is
>>      used for enciphering private or secret keys, i.e. for key transport.
>>      For example, this bit shall be set when a public RSA key is to be
>>      used for encrypting a symmetric content-decryption key or an
>>      asymmetric private key.
>>    
>>
>
>Hi Denis,
>
>I think this text has the same problem as the current. In other words,
>somebody might read it and think "I'm not encrypting a key, I'm
>encrypting email, and I'm "transporting" a word document, not a key, so
>this isn't the bit I should look for". This is what happens now.
>
>I can't think of appropriate wording, but if the goal is to make it
>clear to non-security experts so the bit is used consistently, a little
>bit more explanation is needed.
>
>  
>
>>      The dataEncipherment bit is asserted when the subject public key
>>      is used for directly enciphering raw user data without the use of
>>      an intermediate key.
>>    
>>
>
>This is clear, I think.
>
>Cheers,
>Sam
>
>  
>
>>Reasons:
>>
>>a) "Key transport" is not explicit enough. The purpose is to encipher 
>>either a private key or a secret key.
>>
>>b) The example is not clear enough: "RSA key" can be a private key or a 
>>public key, hence why "public" has been added.
>>
>>c) The key that is communicated is a decryption key rather than an 
>>encryption key, hence why "content-encryption" has been changed into 
>>"content-decryption".
>>
>>d) The example has been extended to cover the case of an asymmetric cipher 
>>as well.
>>
>>e) In the last statement, the intermediate key would not necessarily be a 
>>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" has 
>>been replaced by "key'.
>>
>>Note that the current text from X.509 is:
>>
>>  c) keyEncipherment: for enciphering keys or other security information,
>>     e.g. for key transport;
>>
>>  d) dataEncipherment: for enciphering user data, but not keys or other
>>     security information as in c) above;
>>
>>Denis
>>
>>    
>>
>>>Russ
>>>
>>>At 10:14 PM 5/11/2005, Simon McMahon wrote:
>>>
>>>      
>>>
>>>>Russ,
>>>>
>>>>They were calling an 'encrypt' function to encrypt XML data and they 
>>>>gave it an RSA key (the cert actually) to do it. Of course it 
>>>>internally made an AES key but they never saw it until the 
>>>>interoperability issue made them look. From what they saw at the level 
>>>>they were looking the interpretation was reasonable. When the 
>>>>transport key is well hidden and simply part of the protocol then it 
>>>>looks just like RSA is encrypting big slabs of data. If you know that 
>>>>RSA is bound by the modulus size then you know what is really 
>>>>happening but not all users of PKI know RSA so well. Why should they?
>>>>
>>>>Couple this interpretation of key-usage with a dubious decision to 
>>>>reject encryption requests with certs that dont have key-usage='data 
>>>>encipherment' and you have an interoperability problem. I say 
>>>>"dubious" because it is a public key so you cannot enforce usage 
>>>>policy anyway. The CA could set both flags to fix it, which by the way 
>>>>was the vendors preferred solution, but its not my CA or their CA and 
>>>>the CA doesn't do that. Why should they?
>>>>
>>>>This reference, in my opinion, allows the ambiguous interpretation:
>>>>        
>>>>
>>>>>    The keyEncipherment bit is asserted when the subject public key is
>>>>>     used for key transport.  For example, when an RSA key is to be
>>>>>     used for key management, then this bit shall asserted.
>>>>>
>>>>>     The dataEncipherment bit is asserted when the subject public key
>>>>>     is used for enciphering user data, other than cryptographic keys.
>>>>>          
>>>>>
>>>>In this case the public key is clearly "intended" to be used to 
>>>>encrypt the XML data but it just doesn't do it directly because it 
>>>>cant. The term "key management" also has associations with more basic 
>>>>and explicit key management operations like installing trusted root 
>>>>certs or secure installation of shared secret keys etc. In this case 
>>>>it is much less obvious that key management is happening because the 
>>>>key is bundled with the data. It looks just like the public key is 
>>>>encrypting the data.
>>>>
>>>>In my opinion there are 3 cases presented as 2 in the RFC.
>>>>1. RSA encrypts data - hardly ever used.
>>>>2. RSA implicitly encrypts keys so it can really encrypt bulk data - 
>>>>common usage.
>>>>3. RSA explicitly encrypts keys for explicit key management functions 
>>>>- common usage.
>>>>The current bits separate 1 from 2/3 yet people make the 
>>>>interpretation that they split the more common 2 from 3 assuming 1 and 
>>>>2 are the same thing. Knowledge of RSA is required to know that 1 and 
>>>>2 are different.
>>>>
>>>>Peter's comment "This bit MUST NOT be set when the intention is to 
>>>>encipher intermediate cryptographic keys rather than raw user data" is 
>>>>most relevant in my case. Does PKIX support this clarification?
>>>>
>>>>In my opinion this problem will not entirely go away by clarifying the 
>>>>standard because most people dont read it before they implement 
>>>>something. The two bits are there and as long as they are both there 
>>>>then the mistake will be made by busy developers. Unenforceable 
>>>>key-usage policy, to "public" keys, will also continue to be 
>>>>implemented. People will come looking for clarification once they have 
>>>>an interoperability issue but by then it is often too late - the issue 
>>>>usually gets decided by who has the biggest corporate balls. In this 
>>>>case it wasn't too late so thanks for the assistance.
>>>>
>>>>If I could recommend a change to the standard then I would suggest 
>>>>dropping one of the encryption bits and just have a single key-usage = 
>>>>"encryption". Give it the value the same as "key-encryption" since 
>>>>this is the common usage.
>>>>
>>>>Thanks,
>>>>
>>>>Simon McMahon.
>>>>
>>>>
>>>>Simon McMahon
>>>>
>>>>Work: (07) 31311420
>>>>Mobile: (043) 2294180
>>>>
>>>>
>>>>        
>>>>
>>>>>>>Russ Housley <[email-masked]> 05/12/05 01:06am >>>
>>>>>>>              
>>>>>>>
>>>>Simon:
>>>>
>>>>If they are encrypting the XML data directly with the RSA key (which is
>>>>very unlikely), then they are correct.
>>>>
>>>>The traditional way to handle this is to generate a random
>>>>content-encryption key (CEK) and then encrypt the XML data with a 
>>>>symmetric algorithm using the CEK.  The CEK is encrypted with the RSA 
>>>>key from the certificate.  Thus, the RSA key is really being used to 
>>>>encrypt only
>>>>symmetric keys.
>>>>
>>>>Russ
>>>>
>>>> At 08:33 PM 5/10/2005, Simon McMahon wrote:
>>>>
>>>>        
>>>>
>>>>>Hi,
>>>>>
>>>>>I have had a recent interoperability issue with a application vendor 
>>>>>          
>>>>>
>>>>that >didn't like the key-usage attributes in a cert from a CA vendor's
>>>>        
>>>>
>>>>>certificate. Signing certs work fine, it was an encryption cert that 
>>>>>          
>>>>>
>>>>failed.
>>>>        
>>>>
>>>>>CA sets key-usage = "key encipherment".
>>>>>Application wants to encrypt some XML data so looks for key-usage = 
>>>>>          
>>>>>
>>>>"data
>>>>        
>>>>
>>>>>encipherment". Reason - because XML is data, not a key.
>>>>>
>>>>>I believe the application vendor is wrong and I explained that the 
>>>>>          
>>>>>
>>>>RSA key >actually encrypts an AES key so it doesn't directly encrypt 
>>>>the data but >they want an official "pkix" ruling based on the 
>>>>standard so can someone >please refer me to a statement in the 
>>>>standard that clears this up.
>>>>        
>>>>
>>>>>Thanks,
>>>>>
>>>>>Simon McMahon.
>>>>>
>>>>>
>>>>>
>>>>>Simon McMahon
>>>>>
>>>>>Work: (07) 31311420
>>>>>Mobile: (043) 2294180
>>>>>
>>>>>
>>>>>
>>>>>Simon McMahon
>>>>>
>>>>>Work: (07) 31311420
>>>>>Mobile: (043) 2294180
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>************************************************************************* 
>>>>>          
>>>>>
>>>>**********
>>>>        
>>>>
>>>>>This email, including any attachments sent with it, is confidential and
>>>>>for the sole use of the intended recipient(s).  This confidentiality is
>>>>>not waived or lost, if you receive it and you are not the intended
>>>>>recipient(s), or if it is transmitted/received in error.
>>>>>
>>>>>Any unauthorised use, alteration, disclosure, distribution or review of
>>>>>this email is prohibited.  It may be subject to a statutory duty of
>>>>>confidentiality if it relates to health service matters.
>>>>>
>>>>>If you are not the intended recipient(s), or if you have received this
>>>>>email in error, you are asked to immediately notify the sender by
>>>>>telephone or by return email.  You should also delete this email and
>>>>>destroy any hard copies produced.
>>>>>************************************************************************* 
>>>>>          
>>>>>
>>>>**********
>>>>
>>>>
>>>>
>>>>*********************************************************************************** 
>>>>
>>>>This email, including any attachments sent with it, is confidential 
>>>>and for the sole use of the intended recipient(s).  This 
>>>>confidentiality is not waived or lost, if you receive it and you are 
>>>>not the intended recipient(s), or if it is transmitted/received in error.
>>>>
>>>>Any unauthorised use, alteration, disclosure, distribution or review 
>>>>of this email is prohibited.  It may be subject to a statutory duty of 
>>>>confidentiality if it relates to health service matters.
>>>>
>>>>If you are not the intended recipient(s), or if you have received this 
>>>>email in error, you are asked to immediately notify the sender by 
>>>>telephone or by return email.  You should also delete this email and 
>>>>destroy any hard copies produced.
>>>>*********************************************************************************** 
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>
>  
>

Date: Thu, 12 May 2005 11:22:04 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Cc: [email-masked]
Sender: [email-masked]

Denis:

Thanks.  I think you suggestion improves the text.

Russ

At 10:44 AM 5/12/2005, Denis Pinkas wrote:
>Russ,
>
>>Since we are working on an update to RFC 3280, I propose the following 
>>revisions to these descritions.
>
>>      The keyEncipherment bit is asserted when the subject public key is
>>      used for key transport.  For example, when an RSA key is to be
>>      used for key management by encrypting a symmetric content-encryption
>>      key, then this bit shall asserted.
>>      The dataEncipherment bit is asserted when the subject public key
>>      is used for directly enciphering raw user data without the use of
>>      an intermediate symmetric cipher.
>
>Thank you for this strawman proposal. I would rather propose:
>
>       The keyEncipherment bit is asserted when the subject public key is
>       used for enciphering private or secret keys, i.e. for key transport.
>       For example, this bit shall be set when a public RSA key is to be
>       used for encrypting a symmetric content-decryption key or an
>       asymmetric private key.
>
>       The dataEncipherment bit is asserted when the subject public key
>       is used for directly enciphering raw user data without the use of
>       an intermediate key.
>
>Reasons:
>
>a) "Key transport" is not explicit enough. The purpose is to encipher 
>either a private key or a secret key.
>
>b) The example is not clear enough: "RSA key" can be a private key or a 
>public key, hence why "public" has been added.
>
>c) The key that is communicated is a decryption key rather than an 
>encryption key, hence why "content-encryption" has been changed into 
>"content-decryption".
>
>d) The example has been extended to cover the case of an asymmetric cipher 
>as well.
>
>e) In the last statement, the intermediate key would not necessarily be a 
>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" 
>has been replaced by "key'.
>
>Note that the current text from X.509 is:
>
>   c) keyEncipherment: for enciphering keys or other security information,
>      e.g. for key transport;
>
>   d) dataEncipherment: for enciphering user data, but not keys or other
>      security information as in c) above;
>
>Denis

Date: Thu, 12 May 2005 11:17:55 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

Wrote Denis Pinkas <[email-masked]>, on Thu, May 12, 2005 at 04:44:28PM +0200:
> 
> Russ,
> 
> >Since we are working on an update to RFC 3280, I propose the following 
> >revisions to these descritions.
> 
> >     The keyEncipherment bit is asserted when the subject public key is
> >     used for key transport.  For example, when an RSA key is to be
> >     used for key management by encrypting a symmetric content-encryption
> >     key, then this bit shall asserted.
> >
> >     The dataEncipherment bit is asserted when the subject public key
> >     is used for directly enciphering raw user data without the use of
> >     an intermediate symmetric cipher.
> 
> Thank you for this strawman proposal. I would rather propose:
> 
>       The keyEncipherment bit is asserted when the subject public key is
>       used for enciphering private or secret keys, i.e. for key transport.
>       For example, this bit shall be set when a public RSA key is to be
>       used for encrypting a symmetric content-decryption key or an
>       asymmetric private key.

Hi Denis,

I think this text has the same problem as the current. In other words,
somebody might read it and think "I'm not encrypting a key, I'm
encrypting email, and I'm "transporting" a word document, not a key, so
this isn't the bit I should look for". This is what happens now.

I can't think of appropriate wording, but if the goal is to make it
clear to non-security experts so the bit is used consistently, a little
bit more explanation is needed.

>       The dataEncipherment bit is asserted when the subject public key
>       is used for directly enciphering raw user data without the use of
>       an intermediate key.

This is clear, I think.

Cheers,
Sam

> Reasons:
> 
> a) "Key transport" is not explicit enough. The purpose is to encipher 
> either a private key or a secret key.
> 
> b) The example is not clear enough: "RSA key" can be a private key or a 
> public key, hence why "public" has been added.
> 
> c) The key that is communicated is a decryption key rather than an 
> encryption key, hence why "content-encryption" has been changed into 
> "content-decryption".
> 
> d) The example has been extended to cover the case of an asymmetric cipher 
> as well.
> 
> e) In the last statement, the intermediate key would not necessarily be a 
> symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" has 
> been replaced by "key'.
> 
> Note that the current text from X.509 is:
> 
>   c) keyEncipherment: for enciphering keys or other security information,
>      e.g. for key transport;
> 
>   d) dataEncipherment: for enciphering user data, but not keys or other
>      security information as in c) above;
> 
> Denis
> 
> >Russ
> >
> >At 10:14 PM 5/11/2005, Simon McMahon wrote:
> >
> >>Russ,
> >>
> >>They were calling an 'encrypt' function to encrypt XML data and they 
> >>gave it an RSA key (the cert actually) to do it. Of course it 
> >>internally made an AES key but they never saw it until the 
> >>interoperability issue made them look. From what they saw at the level 
> >>they were looking the interpretation was reasonable. When the 
> >>transport key is well hidden and simply part of the protocol then it 
> >>looks just like RSA is encrypting big slabs of data. If you know that 
> >>RSA is bound by the modulus size then you know what is really 
> >>happening but not all users of PKI know RSA so well. Why should they?
> >>
> >>Couple this interpretation of key-usage with a dubious decision to 
> >>reject encryption requests with certs that dont have key-usage='data 
> >>encipherment' and you have an interoperability problem. I say 
> >>"dubious" because it is a public key so you cannot enforce usage 
> >>policy anyway. The CA could set both flags to fix it, which by the way 
> >>was the vendors preferred solution, but its not my CA or their CA and 
> >>the CA doesn't do that. Why should they?
> >>
> >>This reference, in my opinion, allows the ambiguous interpretation:
> >>>     The keyEncipherment bit is asserted when the subject public key is
> >>>      used for key transport.  For example, when an RSA key is to be
> >>>      used for key management, then this bit shall asserted.
> >>>
> >>>      The dataEncipherment bit is asserted when the subject public key
> >>>      is used for enciphering user data, other than cryptographic keys.
> >>
> >>In this case the public key is clearly "intended" to be used to 
> >>encrypt the XML data but it just doesn't do it directly because it 
> >>cant. The term "key management" also has associations with more basic 
> >>and explicit key management operations like installing trusted root 
> >>certs or secure installation of shared secret keys etc. In this case 
> >>it is much less obvious that key management is happening because the 
> >>key is bundled with the data. It looks just like the public key is 
> >>encrypting the data.
> >>
> >>In my opinion there are 3 cases presented as 2 in the RFC.
> >>1. RSA encrypts data - hardly ever used.
> >>2. RSA implicitly encrypts keys so it can really encrypt bulk data - 
> >>common usage.
> >>3. RSA explicitly encrypts keys for explicit key management functions 
> >>- common usage.
> >>The current bits separate 1 from 2/3 yet people make the 
> >>interpretation that they split the more common 2 from 3 assuming 1 and 
> >>2 are the same thing. Knowledge of RSA is required to know that 1 and 
> >>2 are different.
> >>
> >>Peter's comment "This bit MUST NOT be set when the intention is to 
> >>encipher intermediate cryptographic keys rather than raw user data" is 
> >>most relevant in my case. Does PKIX support this clarification?
> >>
> >>In my opinion this problem will not entirely go away by clarifying the 
> >>standard because most people dont read it before they implement 
> >>something. The two bits are there and as long as they are both there 
> >>then the mistake will be made by busy developers. Unenforceable 
> >>key-usage policy, to "public" keys, will also continue to be 
> >>implemented. People will come looking for clarification once they have 
> >>an interoperability issue but by then it is often too late - the issue 
> >>usually gets decided by who has the biggest corporate balls. In this 
> >>case it wasn't too late so thanks for the assistance.
> >>
> >>If I could recommend a change to the standard then I would suggest 
> >>dropping one of the encryption bits and just have a single key-usage = 
> >>"encryption". Give it the value the same as "key-encryption" since 
> >>this is the common usage.
> >>
> >>Thanks,
> >>
> >>Simon McMahon.
> >>
> >>
> >>Simon McMahon
> >>
> >>Work: (07) 31311420
> >>Mobile: (043) 2294180
> >>
> >>
> >>>>> Russ Housley <[email-masked]> 05/12/05 01:06am >>>
> >>Simon:
> >>
> >>If they are encrypting the XML data directly with the RSA key (which is
> >>very unlikely), then they are correct.
> >>
> >>The traditional way to handle this is to generate a random
> >>content-encryption key (CEK) and then encrypt the XML data with a 
> >>symmetric algorithm using the CEK.  The CEK is encrypted with the RSA 
> >>key from the certificate.  Thus, the RSA key is really being used to 
> >>encrypt only
> >>symmetric keys.
> >>
> >>Russ
> >>
> >>  At 08:33 PM 5/10/2005, Simon McMahon wrote:
> >>
> >>>Hi,
> >>>
> >>>I have had a recent interoperability issue with a application vendor 
> >>that >didn't like the key-usage attributes in a cert from a CA vendor's
> >>>certificate. Signing certs work fine, it was an encryption cert that 
> >>failed.
> >>>
> >>>CA sets key-usage = "key encipherment".
> >>>Application wants to encrypt some XML data so looks for key-usage = 
> >>"data
> >>>encipherment". Reason - because XML is data, not a key.
> >>>
> >>>I believe the application vendor is wrong and I explained that the 
> >>RSA key >actually encrypts an AES key so it doesn't directly encrypt 
> >>the data but >they want an official "pkix" ruling based on the 
> >>standard so can someone >please refer me to a statement in the 
> >>standard that clears this up.
> >>>
> >>>Thanks,
> >>>
> >>>Simon McMahon.
> >>>
> >>>
> >>>
> >>>Simon McMahon
> >>>
> >>>Work: (07) 31311420
> >>>Mobile: (043) 2294180
> >>>
> >>>
> >>>
> >>>Simon McMahon
> >>>
> >>>Work: (07) 31311420
> >>>Mobile: (043) 2294180
> >>>
> >>>
> >>>
> >>>
> >>>************************************************************************* 
> >>**********
> >>>This email, including any attachments sent with it, is confidential and
> >>>for the sole use of the intended recipient(s).  This confidentiality is
> >>>not waived or lost, if you receive it and you are not the intended
> >>>recipient(s), or if it is transmitted/received in error.
> >>>
> >>>Any unauthorised use, alteration, disclosure, distribution or review of
> >>>this email is prohibited.  It may be subject to a statutory duty of
> >>>confidentiality if it relates to health service matters.
> >>>
> >>>If you are not the intended recipient(s), or if you have received this
> >>>email in error, you are asked to immediately notify the sender by
> >>>telephone or by return email.  You should also delete this email and
> >>>destroy any hard copies produced.
> >>>************************************************************************* 
> >>**********
> >>
> >>
> >>
> >>*********************************************************************************** 
> >>
> >>This email, including any attachments sent with it, is confidential 
> >>and for the sole use of the intended recipient(s).  This 
> >>confidentiality is not waived or lost, if you receive it and you are 
> >>not the intended recipient(s), or if it is transmitted/received in error.
> >>
> >>Any unauthorised use, alteration, disclosure, distribution or review 
> >>of this email is prohibited.  It may be subject to a statutory duty of 
> >>confidentiality if it relates to health service matters.
> >>
> >>If you are not the intended recipient(s), or if you have received this 
> >>email in error, you are asked to immediately notify the sender by 
> >>telephone or by return email.  You should also delete this email and 
> >>destroy any hard copies produced.
> >>*********************************************************************************** 
> >>
> >
> >
> >
> 

-- 
http://www.certicom.com

Date: Thu, 12 May 2005 10:56:46 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Cc: [email-masked]
Sender: [email-masked]

Denis:

> >>> You say that it is not clear what validation policy needs to be used,
> >>> but this is completely irrelevant to the discussion of the CRL AIA
> >>> extension.  This extension aid in certification path construction,
> >>> not the validation of the path once it is constructed.
>
> >> Not exactly, it could "help" finding a wrong path !
>
> > Not likely.  The signer of the CRL is providing a pointer to their own
> > certificate.  Path construction to locate a parent of that certificate
> > through a complex PKI might include paths that are acceptable and paths
> > that are unacceptable, but the certificate that contains the public key
> > needed to validate the signature on the CRL is clearly needed.
>
>The problem is to know if a CRL that has been fetched "somewhere" is 
>adequate for the target certificate. It is not to validate a CRL that has 
>been fetched "somewhere".

You continue to miss the whole point of this document.

The certificate user has already obtained the CRL, but needs the 
certificate of the CRL issuer in order to validate the signature on the 
CRL.  That is the scope of this document.  You keep trying to make it 
something else.

Russ

Date: Thu, 12 May 2005 10:53:06 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Cc: pkix <[email-masked]>
Sender: [email-masked]

Denis:

Finally!  We now uncover the actual point of disagreement.

You say:
    The same trust anchor is not a *sufficient* condition. The same node in the
    certification tree is the necessary condition. This implies, of course, the
    same trust anchor, but since two CRL issuers located at different nodes
    (i.e. certified by different CAS) might have the same CRL issuer name, this
    condition is insufficient to solve the issue.

When policies, procedures, and practices are followed, I do not believe 
that two different CRL issuers that are subordinate to the same trust 
anchor can legitimately have the same name.  As I said yesterday, I am 
willing to add text to the Security Considerations section to state 
this.  I am even willing to state that certificate users should not include 
trust anchors that do not have policies, procedures, and practices that 
would prevent such name collisions.

Russ

Date: Thu, 12 May 2005 16:44:28 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

Russ,

> Since we are working on an update to RFC 3280, I propose the following 
> revisions to these descritions.

>      The keyEncipherment bit is asserted when the subject public key is
>      used for key transport.  For example, when an RSA key is to be
>      used for key management by encrypting a symmetric content-encryption
>      key, then this bit shall asserted.
> 
>      The dataEncipherment bit is asserted when the subject public key
>      is used for directly enciphering raw user data without the use of
>      an intermediate symmetric cipher.

Thank you for this strawman proposal. I would rather propose:

       The keyEncipherment bit is asserted when the subject public key is
       used for enciphering private or secret keys, i.e. for key transport.
       For example, this bit shall be set when a public RSA key is to be
       used for encrypting a symmetric content-decryption key or an
       asymmetric private key.

       The dataEncipherment bit is asserted when the subject public key
       is used for directly enciphering raw user data without the use of
       an intermediate key.

Reasons:

a) "Key transport" is not explicit enough. The purpose is to encipher either 
a private key or a secret key.

b) The example is not clear enough: "RSA key" can be a private key or a 
public key, hence why "public" has been added.

c) The key that is communicated is a decryption key rather than an 
encryption key, hence why "content-encryption" has been changed into 
"content-decryption".

d) The example has been extended to cover the case of an asymmetric cipher 
as well.

e) In the last statement, the intermediate key would not necessarily be a 
symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" has 
been replaced by "key'.

Note that the current text from X.509 is:

   c) keyEncipherment: for enciphering keys or other security information,
      e.g. for key transport;

   d) dataEncipherment: for enciphering user data, but not keys or other
      security information as in c) above;

Denis

> Russ
> 
> At 10:14 PM 5/11/2005, Simon McMahon wrote:
> 
>> Russ,
>>
>> They were calling an 'encrypt' function to encrypt XML data and they 
>> gave it an RSA key (the cert actually) to do it. Of course it 
>> internally made an AES key but they never saw it until the 
>> interoperability issue made them look. From what they saw at the level 
>> they were looking the interpretation was reasonable. When the 
>> transport key is well hidden and simply part of the protocol then it 
>> looks just like RSA is encrypting big slabs of data. If you know that 
>> RSA is bound by the modulus size then you know what is really 
>> happening but not all users of PKI know RSA so well. Why should they?
>>
>> Couple this interpretation of key-usage with a dubious decision to 
>> reject encryption requests with certs that dont have key-usage='data 
>> encipherment' and you have an interoperability problem. I say 
>> "dubious" because it is a public key so you cannot enforce usage 
>> policy anyway. The CA could set both flags to fix it, which by the way 
>> was the vendors preferred solution, but its not my CA or their CA and 
>> the CA doesn't do that. Why should they?
>>
>> This reference, in my opinion, allows the ambiguous interpretation:
>> >     The keyEncipherment bit is asserted when the subject public key is
>> >      used for key transport.  For example, when an RSA key is to be
>> >      used for key management, then this bit shall asserted.
>> >
>> >      The dataEncipherment bit is asserted when the subject public key
>> >      is used for enciphering user data, other than cryptographic keys.
>>
>> In this case the public key is clearly "intended" to be used to 
>> encrypt the XML data but it just doesn't do it directly because it 
>> cant. The term "key management" also has associations with more basic 
>> and explicit key management operations like installing trusted root 
>> certs or secure installation of shared secret keys etc. In this case 
>> it is much less obvious that key management is happening because the 
>> key is bundled with the data. It looks just like the public key is 
>> encrypting the data.
>>
>> In my opinion there are 3 cases presented as 2 in the RFC.
>> 1. RSA encrypts data - hardly ever used.
>> 2. RSA implicitly encrypts keys so it can really encrypt bulk data - 
>> common usage.
>> 3. RSA explicitly encrypts keys for explicit key management functions 
>> - common usage.
>> The current bits separate 1 from 2/3 yet people make the 
>> interpretation that they split the more common 2 from 3 assuming 1 and 
>> 2 are the same thing. Knowledge of RSA is required to know that 1 and 
>> 2 are different.
>>
>> Peter's comment "This bit MUST NOT be set when the intention is to 
>> encipher intermediate cryptographic keys rather than raw user data" is 
>> most relevant in my case. Does PKIX support this clarification?
>>
>> In my opinion this problem will not entirely go away by clarifying the 
>> standard because most people dont read it before they implement 
>> something. The two bits are there and as long as they are both there 
>> then the mistake will be made by busy developers. Unenforceable 
>> key-usage policy, to "public" keys, will also continue to be 
>> implemented. People will come looking for clarification once they have 
>> an interoperability issue but by then it is often too late - the issue 
>> usually gets decided by who has the biggest corporate balls. In this 
>> case it wasn't too late so thanks for the assistance.
>>
>> If I could recommend a change to the standard then I would suggest 
>> dropping one of the encryption bits and just have a single key-usage = 
>> "encryption". Give it the value the same as "key-encryption" since 
>> this is the common usage.
>>
>> Thanks,
>>
>> Simon McMahon.
>>
>>
>> Simon McMahon
>>
>> Work: (07) 31311420
>> Mobile: (043) 2294180
>>
>>
>> >>> Russ Housley <[email-masked]> 05/12/05 01:06am >>>
>> Simon:
>>
>> If they are encrypting the XML data directly with the RSA key (which is
>> very unlikely), then they are correct.
>>
>> The traditional way to handle this is to generate a random
>> content-encryption key (CEK) and then encrypt the XML data with a 
>> symmetric algorithm using the CEK.  The CEK is encrypted with the RSA 
>> key from the certificate.  Thus, the RSA key is really being used to 
>> encrypt only
>> symmetric keys.
>>
>> Russ
>>
>>   At 08:33 PM 5/10/2005, Simon McMahon wrote:
>>
>> >Hi,
>> >
>> >I have had a recent interoperability issue with a application vendor 
>> that >didn't like the key-usage attributes in a cert from a CA vendor's
>> >certificate. Signing certs work fine, it was an encryption cert that 
>> failed.
>> >
>> >CA sets key-usage = "key encipherment".
>> >Application wants to encrypt some XML data so looks for key-usage = 
>> "data
>> >encipherment". Reason - because XML is data, not a key.
>> >
>> >I believe the application vendor is wrong and I explained that the 
>> RSA key >actually encrypts an AES key so it doesn't directly encrypt 
>> the data but >they want an official "pkix" ruling based on the 
>> standard so can someone >please refer me to a statement in the 
>> standard that clears this up.
>> >
>> >Thanks,
>> >
>> >Simon McMahon.
>> >
>> >
>> >
>> >Simon McMahon
>> >
>> >Work: (07) 31311420
>> >Mobile: (043) 2294180
>> >
>> >
>> >
>> >Simon McMahon
>> >
>> >Work: (07) 31311420
>> >Mobile: (043) 2294180
>> >
>> >
>> >
>> >
>> >************************************************************************* 
>> **********
>> >This email, including any attachments sent with it, is confidential and
>> >for the sole use of the intended recipient(s).  This confidentiality is
>> >not waived or lost, if you receive it and you are not the intended
>> >recipient(s), or if it is transmitted/received in error.
>> >
>> >Any unauthorised use, alteration, disclosure, distribution or review of
>> >this email is prohibited.  It may be subject to a statutory duty of
>> >confidentiality if it relates to health service matters.
>> >
>> >If you are not the intended recipient(s), or if you have received this
>> >email in error, you are asked to immediately notify the sender by
>> >telephone or by return email.  You should also delete this email and
>> >destroy any hard copies produced.
>> >************************************************************************* 
>> **********
>>
>>
>>
>> *********************************************************************************** 
>>
>> This email, including any attachments sent with it, is confidential 
>> and for the sole use of the intended recipient(s).  This 
>> confidentiality is not waived or lost, if you receive it and you are 
>> not the intended recipient(s), or if it is transmitted/received in error.
>>
>> Any unauthorised use, alteration, disclosure, distribution or review 
>> of this email is prohibited.  It may be subject to a statutory duty of 
>> confidentiality if it relates to health service matters.
>>
>> If you are not the intended recipient(s), or if you have received this 
>> email in error, you are asked to immediately notify the sender by 
>> telephone or by return email.  You should also delete this email and 
>> destroy any hard copies produced.
>> *********************************************************************************** 
>>
> 
> 
> 

Date: Thu, 12 May 2005 10:05:10 -0400
To: "Simon McMahon" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Cc: <[email-masked]>
Sender: [email-masked]

Since we are working on an update to RFC 3280, I propose the following 
revisions to these descritions.

      The keyEncipherment bit is asserted when the subject public key is
      used for key transport.  For example, when an RSA key is to be
      used for key management by encrypting a symmetric content-encryption
      key, then this bit shall asserted.

      The dataEncipherment bit is asserted when the subject public key
      is used for directly enciphering raw user data without the use of
      an intermediate symmetric cipher.

Russ

At 10:14 PM 5/11/2005, Simon McMahon wrote:
>Russ,
>
>They were calling an 'encrypt' function to encrypt XML data and they gave 
>it an RSA key (the cert actually) to do it. Of course it internally made 
>an AES key but they never saw it until the interoperability issue made 
>them look. From what they saw at the level they were looking the 
>interpretation was reasonable. When the transport key is well hidden and 
>simply part of the protocol then it looks just like RSA is encrypting big 
>slabs of data. If you know that RSA is bound by the modulus size then you 
>know what is really happening but not all users of PKI know RSA so well. 
>Why should they?
>
>Couple this interpretation of key-usage with a dubious decision to reject 
>encryption requests with certs that dont have key-usage='data 
>encipherment' and you have an interoperability problem. I say "dubious" 
>because it is a public key so you cannot enforce usage policy anyway. The 
>CA could set both flags to fix it, which by the way was the vendors 
>preferred solution, but its not my CA or their CA and the CA doesn't do 
>that. Why should they?
>
>This reference, in my opinion, allows the ambiguous interpretation:
> >     The keyEncipherment bit is asserted when the subject public key is
> >      used for key transport.  For example, when an RSA key is to be
> >      used for key management, then this bit shall asserted.
> >
> >      The dataEncipherment bit is asserted when the subject public key
> >      is used for enciphering user data, other than cryptographic keys.
>
>In this case the public key is clearly "intended" to be used to encrypt 
>the XML data but it just doesn't do it directly because it cant. The term 
>"key management" also has associations with more basic and explicit key 
>management operations like installing trusted root certs or secure 
>installation of shared secret keys etc. In this case it is much less 
>obvious that key management is happening because the key is bundled with 
>the data. It looks just like the public key is encrypting the data.
>
>In my opinion there are 3 cases presented as 2 in the RFC.
>1. RSA encrypts data - hardly ever used.
>2. RSA implicitly encrypts keys so it can really encrypt bulk data - 
>common usage.
>3. RSA explicitly encrypts keys for explicit key management functions - 
>common usage.
>The current bits separate 1 from 2/3 yet people make the interpretation 
>that they split the more common 2 from 3 assuming 1 and 2 are the same 
>thing. Knowledge of RSA is required to know that 1 and 2 are different.
>
>Peter's comment "This bit MUST NOT be set when the intention is to 
>encipher intermediate cryptographic keys rather than raw user data" is 
>most relevant in my case. Does PKIX support this clarification?
>
>In my opinion this problem will not entirely go away by clarifying the 
>standard because most people dont read it before they implement something. 
>The two bits are there and as long as they are both there then the mistake 
>will be made by busy developers. Unenforceable key-usage policy, to 
>"public" keys, will also continue to be implemented. People will come 
>looking for clarification once they have an interoperability issue but by 
>then it is often too late - the issue usually gets decided by who has the 
>biggest corporate balls. In this case it wasn't too late so thanks for the 
>assistance.
>
>If I could recommend a change to the standard then I would suggest 
>dropping one of the encryption bits and just have a single key-usage = 
>"encryption". Give it the value the same as "key-encryption" since this is 
>the common usage.
>
>Thanks,
>
>Simon McMahon.
>
>
>Simon McMahon
>
>Work: (07) 31311420
>Mobile: (043) 2294180
>
>
> >>> Russ Housley <[email-masked]> 05/12/05 01:06am >>>
>Simon:
>
>If they are encrypting the XML data directly with the RSA key (which is
>very unlikely), then they are correct.
>
>The traditional way to handle this is to generate a random
>content-encryption key (CEK) and then encrypt the XML data with a 
>symmetric algorithm using the CEK.  The CEK is encrypted with the RSA key 
>from the certificate.  Thus, the RSA key is really being used to encrypt only
>symmetric keys.
>
>Russ
>
>   At 08:33 PM 5/10/2005, Simon McMahon wrote:
>
> >Hi,
> >
> >I have had a recent interoperability issue with a application vendor 
> that >didn't like the key-usage attributes in a cert from a CA vendor's
> >certificate. Signing certs work fine, it was an encryption cert that failed.
> >
> >CA sets key-usage = "key encipherment".
> >Application wants to encrypt some XML data so looks for key-usage = "data
> >encipherment". Reason - because XML is data, not a key.
> >
> >I believe the application vendor is wrong and I explained that the RSA 
> key >actually encrypts an AES key so it doesn't directly encrypt the data 
> but >they want an official "pkix" ruling based on the standard so can 
> someone >please refer me to a statement in the standard that clears this up.
> >
> >Thanks,
> >
> >Simon McMahon.
> >
> >
> >
> >Simon McMahon
> >
> >Work: (07) 31311420
> >Mobile: (043) 2294180
> >
> >
> >
> >Simon McMahon
> >
> >Work: (07) 31311420
> >Mobile: (043) 2294180
> >
> >
> >
> >
> >************************************************************************* 
> **********
> >This email, including any attachments sent with it, is confidential and
> >for the sole use of the intended recipient(s).  This confidentiality is
> >not waived or lost, if you receive it and you are not the intended
> >recipient(s), or if it is transmitted/received in error.
> >
> >Any unauthorised use, alteration, disclosure, distribution or review of
> >this email is prohibited.  It may be subject to a statutory duty of
> >confidentiality if it relates to health service matters.
> >
> >If you are not the intended recipient(s), or if you have received this
> >email in error, you are asked to immediately notify the sender by
> >telephone or by return email.  You should also delete this email and
> >destroy any hard copies produced.
> >************************************************************************* 
> **********
>
>
>
>***********************************************************************************
>This email, including any attachments sent with it, is confidential and 
>for the sole use of the intended recipient(s).  This confidentiality is 
>not waived or lost, if you receive it and you are not the intended 
>recipient(s), or if it is transmitted/received in error.
>
>Any unauthorised use, alteration, disclosure, distribution or review of 
>this email is prohibited.  It may be subject to a statutory duty of 
>confidentiality if it relates to health service matters.
>
>If you are not the intended recipient(s), or if you have received this 
>email in error, you are asked to immediately notify the sender by 
>telephone or by return email.  You should also delete this email and 
>destroy any hard copies produced.
>***********************************************************************************

Content-class: urn:content-classes:message
Subject: RE: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Thu, 12 May 2005 13:56:29 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Denis Pinkas" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

Denis,

Reading my own e-mail I think I was not 100% clear on one point.

"Proposed resolution" should read "Denis proposed resolution".

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of Stefan Santesson
> Sent: den 12 maj 2005 13:24
> To: Denis Pinkas; Russ Housley
> Cc: pkix
> Subject: Structuring Denis issues RE: Comments on
<draft-ietf-pkix-crlaia-
> 00.txt>
> 
> 
> Denis,
> 
> The core of your comments are spread over many emails and opinions may
> have changed on details so I'm not sure I have got the latest picture
of
> your recorded problems and what you propose as resolution.
> 
> I'm thus trying to summarize the current complete picture of the last
> call comments below. Please correct me if something is wrong or
missing.
> Note that I'm not arguing here, just trying to structure the issues (I
> will argue in separate mails). Also note that agreed typos are omitted
> from the list:
> 
> 1)
> Problem: There are SHOULD and MUST requirements in the security
> considerations section.
> 
> Proposed resolution: Reword to make sure we don't use SHOULD or MUST
in
> this section.
> 
> -----
> 2)
> Problem: The security considerations talk about "mitigation" of the
name
> collision problem but gives inadequate advice.
> 
> Proposed resolution: Either delete all text talking about how to
> mitigate this problem or provide full guidance on what it takes to
> guarantee that a CRL Issuer with a matching name actually is the
> intended CRL Issuer. Also explain that this is not an issue when the
CRL
> Issuer certification path and the target certificate certification
path
> are identical.
> 
> 
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > On Behalf Of Denis Pinkas
> > Sent: den 12 maj 2005 11:27
> > To: Russ Housley
> > Cc: pkix
> > Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> >
> >
> > Russ,
> >
> > Since Tim has now made the call at the WG level, please consider
this
> > message as an answer to the call: the current security
considerations
> > section is not acceptable.
> >
> >   > The document already says that the CA and the CRL issuer need to
> >   > terminate at the same trust anchor.  This is the important
point.
> >   > I disagree that there is anything else that ought to be said in
> the
> >   > security considerations.
> >
> > This statement still does not answer to the point I raised, but
> > I will nevertheless answer to your statement.
> >
> > The same trust anchor is not a *sufficient* condition. The same node
> in
> > the
> > certification tree is the necessary condition. This implies, of
> course,
> > the
> > same trust anchor, but since two CRL issuers located at different
> nodes
> > (i.e. certified by different CAS) might have the same CRL issuer
name,
> > this
> > condition is insufficient to solve the issue.
> >
> > May I recall an extract from the security considerations section of
an
> > approved draft that will be published soon as RFC 4043 ? (this is
the
> > permanent-identifier document):
> >
> >       Subject names in certificates are chosen by the issuing CA and
> are
> >       mandated to be unique for each CA; so there can be no name
> collision
> >       between subject names from the same CA.  Such a name may be an
> end-
> >       entity name when the certificate is a leaf certificate, or a
CA
> > name,
> >       when it is a CA certificate.
> >
> >       Since a name is only unique towards its superior CA, unless
some
> >       naming constraints are being used, a name would only be
> guaranteed
> > to
> >       be globally unique when considered to include a sequence of
all
> the
> >       names of the superior CAs. (...)
> >
> >       Additional checks need to be done, e.g., to check if the
public
> key
> >       values of the two CAs which have issued the certificates to be
> >       compared are identical or if the sequence of CA names in the
> >       certification path from the trust anchor to the CA are
> identical.
> >
> >       (...)
> >
> >       The certification of different CAs with the same DN by
different
> CAs
> >       has other negative consequences in various parts of the PKI,
> notably
> >       rendering the IssuerAndSerialNumber structure in [RFC3852]
> section
> >       10.2.4 ambiguous.
> >
> > It speaks for itself, as it applies to CRL Issuers as well. Some
parts
> of
> > it should indeed be copied and pasted in the security considerations
> > section
> > of the current proposed draft.
> >
> > When the certification path used to validate the target certificate
is
> > also used to validate the CRL Issuer certificate, then there is no
> > security
> > issue: this should be said in the security considerations section.
> >
> > What about the other cases ? The other cases belong to the category
of
> > indirect CRLs. Depending on the local validation policy checks done
or
> not
> > done there may be security issues.
> >
> > Denis
> >
> >   > Russ
> >   >
> >   > At 02:59 AM 5/10/2005, Denis Pinkas wrote:
> >   >
> >   >> Russ,
> >   >>
> >   >> Your statement below is correct, but does not answer to any of
my
> >   >> questions/issues. In particular, the last one. I am still
> awaiting
> >   >> your responses.
> >   >>
> >   >> Denis
> >   >>
> >   >>> Denis:
> >   >>> RFC 3280 does not tell an implementor how for locate
> certificates
> > for
> >   >>> any certification path construction.  There are several
> extensions
> >   >>> that provide pointers that may help an implementation, but
other
> >   >>> approaches to obtaining the same certificates are always
> permitted.
> >   >>> I would fully expect an implementation to check any local
cache
> >   >>> before accessing a repository.
> >   >>> The CRL AIA extension fits this pattern.  A method for
locating
> a
> >   >>> certificate is provided, but any other mechanism for locating
> the
> >   >>> same certificate is acceptable.
> >   >>> Russ
> >   >>>
> >   >>>> Stefan,
> >   >>>>
> >   >>>> I made the e-mail shorter. Your main arguments are the
> following:
> >   >>>>
> >   >>>>
> >
>
========================================================================
> ==
> >   >>>>
> >   >>>>
> >   >>>> [Stefan] But it has to provide a warning to something that is
> >   >>>> introduced
> >   >>>> by the standard. This standard does not introduce the concept
> of
> > CRL
> >   >>>> signature checking or CRL issuer certificate validation, so
> that is
> >   >>>> clearly out of scope. More about that below;
> >   >>>>
> >   >>>> [Denis] See below the last answer and also my arguments in
the
> >   >>>> soon-to-be-posted answer to Russ.
> >   >>>>
> >   >>>>
> >
>
========================================================================
> ==
> >   >>>>
> >   >>>>
> >   >>>>
> >   >>>> > > RFC 3280 [PKIX1] specifies the validation of
certification
> > paths.
> >   >>>> > > One aspect involves the determination that a certificate
> has
> > not
> >   >>>> been
> >   >>>> > > revoked, and one revocation checking mechanism is the
> > Certificate
> >   >>>> > > Revocation List (CRL).  CRL validation is also specified
in
> RFC
> >   >>>> 3280,
> >   >>>>
> >   >>>> > I would love this last sentence to be true but the reality
is
> > that:
> >   >>>> > "CRL validation is NOT specified in RFC 3280". :-(
> >   >>>>
> >   >>>> [Stefan] In fact it is.
> >   >>>>
> >   >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85:
> >   >>>>
> >   >>>>    (f)  Obtain and validate the certification path for the
> complete
> > CRL
> >   >>>>    issuer.  If a key usage extension is present in the CRL
> issuer's
> >   >>>>    certificate, verify that the cRLSign bit is set.
> >   >>>>
> >   >>>>    (g)  Validate the signature on the complete CRL using the
> public
> > key
> >   >>>>    validated in step (f).
> >   >>>>
> >   >>>> [Denis] The text does not say how to obtain and validate the
> >   >>>> certification path for the complete (???) CRL issuer. The
text
> is
> >   >>>> not clear enough so that two implementors only looking at
this
> >   >>>> sentence will provide interoperable implementations.
> >   >>>>
> >   >>>>
> >
>
========================================================================
> ==
> >   >>>>
> >   >>>>
> >   >>>> [Stefan] It is my hope that the provided responses here can
> help
> >   >>>> convince you to change your mind about that. If it doesn't I
> still
> >   >>>> argue
> >   >>>> that the place to specify requirements and security
> considerations
> > for
> >   >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL
> > draft.
> >   >>>>
> >   >>>> [Denis] I can agree with your last sentence, ... which means
> that
> > it
> >   >>>> should not be in the main body of the document. In the
security
> >   >>>> considerations section, text is free and we shall at the very
> >   >>>> minimum warn implementers and we should provide some
guidance.
> When
> >   >>>> the same certification path (i.e. the path used to validate
the
> >   >>>> target certificate) is used, then there is no security issue:
> this
> >   >>>> should be said. For all other cases, there MAY be problems:
> this
> >   >>>> should also be said. It is as simple as that.
> >   >>>>
> >   >>>> Denis
> >   >>>
> >   >>
> >   >>
> >   >
> >   >
> >
> >
> >
> 

Date: Thu, 12 May 2005 14:40:48 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: Hoyt L Kesterson II <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Technical Corrigenda 3 to the 4th edition of X.509
Sender: [email-masked]

Hoyt L Kesterson II wrote:

> Some you worked with the X.509 standards committee over the last few 
> years revising the text on key usage.
>
> You can find the text of that Technical Corrigenda at:
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8|X.509-TC3(4th).pdf

You should avoid using characters in the filename that are not 
compatible with the Microsoft OS, it makes it harder to download that file.

 From the text :
"Bits in the KeyUsage type are as follows:
[...]
c) keyEncipherment: for enciphering keys or other security information, 
e.g. for key transport;
d) dataEncipherment: for enciphering user data, but not keys or other 
security information as in c) above;
e) keyAgreement: for use as a public key agreement key;"

It's not yet very precise. The contentCommitment bit text got very 
clear, so it shows how much we can improve on those bits.

The text by Peter is quite good, how about :

c) keyEncipherment: for enciphering keys or other security information, 
e.g. for key transport, and also data encryption that uses an 
intermediate symmetric cipher;
d) dataEncipherment: for directly enciphering raw user data, without the 
use of an intermediate symmetric cipher
e) keyAgreement: for use as a public key agreement key, for example a 
Diffie-Hellman protocol key;

Shouldn't we best find a way to say that an SSL client requires at a 
minimum only digitalSignature, but the SSL server must have 
keyEncipherment ?

Maybe we should precise :
In practice when someone wishes to send enciphered key or security 
information, he must check that the recipient has the keyEncipherment 
bit set before using his public key to encipher. For example in an SSL 
handshake, the client must check that the server has the keyEncipherment 
bit set before sending him an enciphered secret, but never needs to have 
that bit set in his own certificate, because the server will use his 
certificate only for authentification, not to send enciphered data.

Content-class: urn:content-classes:message
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Thu, 12 May 2005 12:39:08 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

Denis,

My main comment to this is that there is no exact definition of what is
"sufficient" in this case.

What is sufficient to you may not be sufficient to me or vice versa.
This issue is as many times when security is the issue a tradeoff. In IT
security you always have the 3 goals:

- Cheep
- Easy to use
- Secure

The sad truth is that we often discover that we can have any 2 of those
but never all 3.

The fact about name uniqueness you provide in the referenced text is a
true facts but it still does not tell me what is sufficient or not in my
environment or how I can achieve reasonable security when the trust
paths differ (in case they have to).

My basic assessment is that there is neither a single truth nor a single
solution to the problem. The chaining to a common root was the
reasonable recommendation agreed at the San Diego PKIX meeting. This is
in my mind not intended to be advertised as a "sufficient" solution,
just good practice to reduce the risk of problems.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of Denis Pinkas
> Sent: den 12 maj 2005 11:27
> To: Russ Housley
> Cc: pkix
> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> 
> Russ,
> 
> Since Tim has now made the call at the WG level, please consider this
> message as an answer to the call: the current security considerations
> section is not acceptable.
> 
>   > The document already says that the CA and the CRL issuer need to
>   > terminate at the same trust anchor.  This is the important point.
>   > I disagree that there is anything else that ought to be said in
the
>   > security considerations.
> 
> This statement still does not answer to the point I raised, but
> I will nevertheless answer to your statement.
> 
> The same trust anchor is not a *sufficient* condition. The same node
in
> the
> certification tree is the necessary condition. This implies, of
course,
> the
> same trust anchor, but since two CRL issuers located at different
nodes
> (i.e. certified by different CAS) might have the same CRL issuer name,
> this
> condition is insufficient to solve the issue.
> 
> May I recall an extract from the security considerations section of an
> approved draft that will be published soon as RFC 4043 ? (this is the
> permanent-identifier document):
> 
>       Subject names in certificates are chosen by the issuing CA and
are
>       mandated to be unique for each CA; so there can be no name
collision
>       between subject names from the same CA.  Such a name may be an
end-
>       entity name when the certificate is a leaf certificate, or a CA
> name,
>       when it is a CA certificate.
> 
>       Since a name is only unique towards its superior CA, unless some
>       naming constraints are being used, a name would only be
guaranteed
> to
>       be globally unique when considered to include a sequence of all
the
>       names of the superior CAs. (...)
> 
>       Additional checks need to be done, e.g., to check if the public
key
>       values of the two CAs which have issued the certificates to be
>       compared are identical or if the sequence of CA names in the
>       certification path from the trust anchor to the CA are
identical.
> 
>       (...)
> 
>       The certification of different CAs with the same DN by different
CAs
>       has other negative consequences in various parts of the PKI,
notably
>       rendering the IssuerAndSerialNumber structure in [RFC3852]
section
>       10.2.4 ambiguous.
> 
> It speaks for itself, as it applies to CRL Issuers as well. Some parts
of
> it should indeed be copied and pasted in the security considerations
> section
> of the current proposed draft.
> 
> When the certification path used to validate the target certificate is
> also used to validate the CRL Issuer certificate, then there is no
> security
> issue: this should be said in the security considerations section.
> 
> What about the other cases ? The other cases belong to the category of
> indirect CRLs. Depending on the local validation policy checks done or
not
> done there may be security issues.
> 
> Denis
> 
>   > Russ
>   >
>   > At 02:59 AM 5/10/2005, Denis Pinkas wrote:
>   >
>   >> Russ,
>   >>
>   >> Your statement below is correct, but does not answer to any of my
>   >> questions/issues. In particular, the last one. I am still
awaiting
>   >> your responses.
>   >>
>   >> Denis
>   >>
>   >>> Denis:
>   >>> RFC 3280 does not tell an implementor how for locate
certificates
> for
>   >>> any certification path construction.  There are several
extensions
>   >>> that provide pointers that may help an implementation, but other
>   >>> approaches to obtaining the same certificates are always
permitted.
>   >>> I would fully expect an implementation to check any local cache
>   >>> before accessing a repository.
>   >>> The CRL AIA extension fits this pattern.  A method for locating
a
>   >>> certificate is provided, but any other mechanism for locating
the
>   >>> same certificate is acceptable.
>   >>> Russ
>   >>>
>   >>>> Stefan,
>   >>>>
>   >>>> I made the e-mail shorter. Your main arguments are the
following:
========================================================================
==
>   >>>>
>   >>>>
>   >>>> [Stefan] But it has to provide a warning to something that is
>   >>>> introduced
>   >>>> by the standard. This standard does not introduce the concept
of
> CRL
>   >>>> signature checking or CRL issuer certificate validation, so
that is
>   >>>> clearly out of scope. More about that below;
>   >>>>
>   >>>> [Denis] See below the last answer and also my arguments in the
>   >>>> soon-to-be-posted answer to Russ.
>   >>>>
>   >>>>
>
========================================================================
==
>   >>>>
>   >>>>
>   >>>>
>   >>>> > > RFC 3280 [PKIX1] specifies the validation of certification
> paths.
>   >>>> > > One aspect involves the determination that a certificate
has
> not
>   >>>> been
>   >>>> > > revoked, and one revocation checking mechanism is the
> Certificate
>   >>>> > > Revocation List (CRL).  CRL validation is also specified in
RFC
>   >>>> 3280,
>   >>>>
>   >>>> > I would love this last sentence to be true but the reality is
> that:
>   >>>> > "CRL validation is NOT specified in RFC 3280". :-(
>   >>>>
>   >>>> [Stefan] In fact it is.
>   >>>>
>   >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85:
>   >>>>
>   >>>>    (f)  Obtain and validate the certification path for the
complete
> CRL
>   >>>>    issuer.  If a key usage extension is present in the CRL
issuer's
>   >>>>    certificate, verify that the cRLSign bit is set.
>   >>>>
>   >>>>    (g)  Validate the signature on the complete CRL using the
public
> key
>   >>>>    validated in step (f).
>   >>>>
>   >>>> [Denis] The text does not say how to obtain and validate the
>   >>>> certification path for the complete (???) CRL issuer. The text
is
>   >>>> not clear enough so that two implementors only looking at this
>   >>>> sentence will provide interoperable implementations.
>   >>>>
>   >>>>
>
========================================================================
==
>   >>>>
>   >>>>
>   >>>> [Stefan] It is my hope that the provided responses here can
help
>   >>>> convince you to change your mind about that. If it doesn't I
still
>   >>>> argue
>   >>>> that the place to specify requirements and security
considerations
> for
>   >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL
> draft.
>   >>>>
>   >>>> [Denis] I can agree with your last sentence, ... which means
that
> it
>   >>>> should not be in the main body of the document. In the security
>   >>>> considerations section, text is free and we shall at the very
>   >>>> minimum warn implementers and we should provide some guidance.
When
>   >>>> the same certification path (i.e. the path used to validate the
>   >>>> target certificate) is used, then there is no security issue:
this
>   >>>> should be said. For all other cases, there MAY be problems:
this
>   >>>> should also be said. It is as simple as that.
>   >>>>
>   >>>> Denis
>   >>>
>   >>
>   >>
>   >
>   >
> 
> 
> 

Content-class: urn:content-classes:message
Subject: Structuring Denis issues RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Thu, 12 May 2005 12:23:40 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

Denis,

The core of your comments are spread over many emails and opinions may
have changed on details so I'm not sure I have got the latest picture of
your recorded problems and what you propose as resolution.

I'm thus trying to summarize the current complete picture of the last
call comments below. Please correct me if something is wrong or missing.
Note that I'm not arguing here, just trying to structure the issues (I
will argue in separate mails). Also note that agreed typos are omitted
from the list:

1)
Problem: There are SHOULD and MUST requirements in the security
considerations section.

Proposed resolution: Reword to make sure we don't use SHOULD or MUST in
this section.

-----
2)
Problem: The security considerations talk about "mitigation" of the name
collision problem but gives inadequate advice.

Proposed resolution: Either delete all text talking about how to
mitigate this problem or provide full guidance on what it takes to
guarantee that a CRL Issuer with a matching name actually is the
intended CRL Issuer. Also explain that this is not an issue when the CRL
Issuer certification path and the target certificate certification path
are identical.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of Denis Pinkas
> Sent: den 12 maj 2005 11:27
> To: Russ Housley
> Cc: pkix
> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> 
> Russ,
> 
> Since Tim has now made the call at the WG level, please consider this
> message as an answer to the call: the current security considerations
> section is not acceptable.
> 
>   > The document already says that the CA and the CRL issuer need to
>   > terminate at the same trust anchor.  This is the important point.
>   > I disagree that there is anything else that ought to be said in
the
>   > security considerations.
> 
> This statement still does not answer to the point I raised, but
> I will nevertheless answer to your statement.
> 
> The same trust anchor is not a *sufficient* condition. The same node
in
> the
> certification tree is the necessary condition. This implies, of
course,
> the
> same trust anchor, but since two CRL issuers located at different
nodes
> (i.e. certified by different CAS) might have the same CRL issuer name,
> this
> condition is insufficient to solve the issue.
> 
> May I recall an extract from the security considerations section of an
> approved draft that will be published soon as RFC 4043 ? (this is the
> permanent-identifier document):
> 
>       Subject names in certificates are chosen by the issuing CA and
are
>       mandated to be unique for each CA; so there can be no name
collision
>       between subject names from the same CA.  Such a name may be an
end-
>       entity name when the certificate is a leaf certificate, or a CA
> name,
>       when it is a CA certificate.
> 
>       Since a name is only unique towards its superior CA, unless some
>       naming constraints are being used, a name would only be
guaranteed
> to
>       be globally unique when considered to include a sequence of all
the
>       names of the superior CAs. (...)
> 
>       Additional checks need to be done, e.g., to check if the public
key
>       values of the two CAs which have issued the certificates to be
>       compared are identical or if the sequence of CA names in the
>       certification path from the trust anchor to the CA are
identical.
> 
>       (...)
> 
>       The certification of different CAs with the same DN by different
CAs
>       has other negative consequences in various parts of the PKI,
notably
>       rendering the IssuerAndSerialNumber structure in [RFC3852]
section
>       10.2.4 ambiguous.
> 
> It speaks for itself, as it applies to CRL Issuers as well. Some parts
of
> it should indeed be copied and pasted in the security considerations
> section
> of the current proposed draft.
> 
> When the certification path used to validate the target certificate is
> also used to validate the CRL Issuer certificate, then there is no
> security
> issue: this should be said in the security considerations section.
> 
> What about the other cases ? The other cases belong to the category of
> indirect CRLs. Depending on the local validation policy checks done or
not
> done there may be security issues.
> 
> Denis
> 
>   > Russ
>   >
>   > At 02:59 AM 5/10/2005, Denis Pinkas wrote:
>   >
>   >> Russ,
>   >>
>   >> Your statement below is correct, but does not answer to any of my
>   >> questions/issues. In particular, the last one. I am still
awaiting
>   >> your responses.
>   >>
>   >> Denis
>   >>
>   >>> Denis:
>   >>> RFC 3280 does not tell an implementor how for locate
certificates
> for
>   >>> any certification path construction.  There are several
extensions
>   >>> that provide pointers that may help an implementation, but other
>   >>> approaches to obtaining the same certificates are always
permitted.
>   >>> I would fully expect an implementation to check any local cache
>   >>> before accessing a repository.
>   >>> The CRL AIA extension fits this pattern.  A method for locating
a
>   >>> certificate is provided, but any other mechanism for locating
the
>   >>> same certificate is acceptable.
>   >>> Russ
>   >>>
>   >>>> Stefan,
>   >>>>
>   >>>> I made the e-mail shorter. Your main arguments are the
following:
========================================================================
==
>   >>>>
>   >>>>
>   >>>> [Stefan] But it has to provide a warning to something that is
>   >>>> introduced
>   >>>> by the standard. This standard does not introduce the concept
of
> CRL
>   >>>> signature checking or CRL issuer certificate validation, so
that is
>   >>>> clearly out of scope. More about that below;
>   >>>>
>   >>>> [Denis] See below the last answer and also my arguments in the
>   >>>> soon-to-be-posted answer to Russ.
>   >>>>
>   >>>>
>
========================================================================
==
>   >>>>
>   >>>>
>   >>>>
>   >>>> > > RFC 3280 [PKIX1] specifies the validation of certification
> paths.
>   >>>> > > One aspect involves the determination that a certificate
has
> not
>   >>>> been
>   >>>> > > revoked, and one revocation checking mechanism is the
> Certificate
>   >>>> > > Revocation List (CRL).  CRL validation is also specified in
RFC
>   >>>> 3280,
>   >>>>
>   >>>> > I would love this last sentence to be true but the reality is
> that:
>   >>>> > "CRL validation is NOT specified in RFC 3280". :-(
>   >>>>
>   >>>> [Stefan] In fact it is.
>   >>>>
>   >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85:
>   >>>>
>   >>>>    (f)  Obtain and validate the certification path for the
complete
> CRL
>   >>>>    issuer.  If a key usage extension is present in the CRL
issuer's
>   >>>>    certificate, verify that the cRLSign bit is set.
>   >>>>
>   >>>>    (g)  Validate the signature on the complete CRL using the
public
> key
>   >>>>    validated in step (f).
>   >>>>
>   >>>> [Denis] The text does not say how to obtain and validate the
>   >>>> certification path for the complete (???) CRL issuer. The text
is
>   >>>> not clear enough so that two implementors only looking at this
>   >>>> sentence will provide interoperable implementations.
>   >>>>
>   >>>>
>
========================================================================
==
>   >>>>
>   >>>>
>   >>>> [Stefan] It is my hope that the provided responses here can
help
>   >>>> convince you to change your mind about that. If it doesn't I
still
>   >>>> argue
>   >>>> that the place to specify requirements and security
considerations
> for
>   >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL
> draft.
>   >>>>
>   >>>> [Denis] I can agree with your last sentence, ... which means
that
> it
>   >>>> should not be in the main body of the document. In the security
>   >>>> considerations section, text is free and we shall at the very
>   >>>> minimum warn implementers and we should provide some guidance.
When
>   >>>> the same certification path (i.e. the path used to validate the
>   >>>> target certificate) is used, then there is no security issue:
this
>   >>>> should be said. For all other cases, there MAY be problems:
this
>   >>>> should also be said. It is as simple as that.
>   >>>>
>   >>>> Denis
>   >>>
>   >>
>   >>
>   >
>   >
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: Typo in <draft-ietf-pkix-crlaia-01.txt>
Date: Thu, 12 May 2005 10:52:40 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Thanks Denis,

Typo noted and will be corrected

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 12 maj 2005 11:45
> To: Russ Housley; Stefan Santesson
> Cc: [email-masked]
> Subject: Typo in <draft-ietf-pkix-crlaia-01.txt>
> 
> Please correct this typo:
> 
> AccessDescription specifying id-ad-caIssuers as the acessMethod
>                                                       ^^
> 
> 
>               Denis
> 
> 

Date: Thu, 12 May 2005 11:45:16 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>, Stefan Santesson <[email-masked]>
CC: [email-masked]
Subject: Typo in <draft-ietf-pkix-crlaia-01.txt>
Sender: [email-masked]

Please correct this typo:

AccessDescription specifying id-ad-caIssuers as the acessMethod
                                                      ^^

              Denis

Date: Thu, 12 May 2005 11:42:33 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Russ,

 > Denis:

 >>> Yes, it is OBVIOUS that the CRL issuer certificate needs to be
 >>> validated.

 >>> You say that it is not clear what validation policy needs to be used,
 >>> but this is completely irrelevant to the discussion of the CRL AIA
 >>> extension.  This extension aid in certification path construction,
 >>> not the validation of the path once it is constructed.

 >> Not exactly, it could "help" finding a wrong path !

 > Not likely.  The signer of the CRL is providing a pointer to their own
 > certificate.  Path construction to locate a parent of that certificate
 > through a complex PKI might include paths that are acceptable and paths
 > that are unacceptable, but the certificate that contains the public key
 > needed to validate the signature on the CRL is clearly needed.

The problem is to know if a CRL that has been fetched "somewhere" is 
adequate for the target certificate. It is not to validate a CRL that has 
been fetched "somewhere".

 >>> There are many factors which need to be considered in the validation
 >>> of the CRL issue certificate.  The values of the key usage extension
 >>> and the certificate policies extension are two that jump to mind.
 >>> There are probably more if I spend the time to consider each possible
 >>> scenario.

 >> One simple rule would allow no security problem at all and I wonder
 >> why you have so much resistance to mention it.

 > We have that rule:  The CA certificate and the CRL Issuer certificate
 > must validate back to the same trust anchor.

As explained in a just posted e-mail this rule is insufficient and thus
insecure.

 >>> In my opinion, this document is ready for WG Last Call.
 >>
 >>
 >> As an editor of the draft, I may understand your position; but it is
 >> up the the PKIX chairs to decide whether or not the document is ready
 >> for WG last call.

 > Correct.  I included this sentence for the WG chairs.  I hope they will
 > agree with me, and that they will issue WG Last Call for this document.

 >> Once again the current Security Considerations section is not acceptable.

 > To you...  No one else is advocating this change.  I continue to believe
 > that requiring the CA certificate and the CRL Issuer certificate to
 > validate back to the same trust anchor resolves your concern.

It does not.

 > I am
 > willing to add a few words to the security considerations about name
 > collisions (my co-author may disagree), but I am not willing to use
 > "MUST" or "SHOULD" in those words.

We agree that "MUST" or "SHOULD" should not be used in the security
considerations section.

 > There is absolutely nothing that a
 > client can do to determine deal with name collisions that are
 > subordinate to the same trust anchor.

This last statement is wrong. Please look again at the security
considerations section of "Permanent Identifier". As an example:

    "Since a name is only unique towards its superior CA, unless some
     naming constraints are being used, a name would only be guaranteed to
     be globally unique when considered to include a sequence of all the
     names of the superior CAs".

Denis

 > Russ

Date: Thu, 12 May 2005 11:26:43 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Russ,

Since Tim has now made the call at the WG level, please consider this 
message as an answer to the call: the current security considerations 
section is not acceptable.

  > The document already says that the CA and the CRL issuer need to
  > terminate at the same trust anchor.  This is the important point.
  > I disagree that there is anything else that ought to be said in the
  > security considerations.

This statement still does not answer to the point I raised, but
I will nevertheless answer to your statement.

The same trust anchor is not a *sufficient* condition. The same node in the
certification tree is the necessary condition. This implies, of course, the
same trust anchor, but since two CRL issuers located at different nodes
(i.e. certified by different CAS) might have the same CRL issuer name, this
condition is insufficient to solve the issue.

May I recall an extract from the security considerations section of an
approved draft that will be published soon as RFC 4043 ? (this is the
permanent-identifier document):

      Subject names in certificates are chosen by the issuing CA and are
      mandated to be unique for each CA; so there can be no name collision
      between subject names from the same CA.  Such a name may be an end-
      entity name when the certificate is a leaf certificate, or a CA name,
      when it is a CA certificate.

      Since a name is only unique towards its superior CA, unless some
      naming constraints are being used, a name would only be guaranteed to
      be globally unique when considered to include a sequence of all the
      names of the superior CAs. (...)

      Additional checks need to be done, e.g., to check if the public key
      values of the two CAs which have issued the certificates to be
      compared are identical or if the sequence of CA names in the
      certification path from the trust anchor to the CA are identical.

      (...)

      The certification of different CAs with the same DN by different CAs
      has other negative consequences in various parts of the PKI, notably
      rendering the IssuerAndSerialNumber structure in [RFC3852] section
      10.2.4 ambiguous.

It speaks for itself, as it applies to CRL Issuers as well. Some parts of
it should indeed be copied and pasted in the security considerations section
of the current proposed draft.

When the certification path used to validate the target certificate is
also used to validate the CRL Issuer certificate, then there is no security
issue: this should be said in the security considerations section.

What about the other cases ? The other cases belong to the category of
indirect CRLs. Depending on the local validation policy checks done or not
done there may be security issues.

Denis

  > Russ
  >
  > At 02:59 AM 5/10/2005, Denis Pinkas wrote:
  >
  >> Russ,
  >>
  >> Your statement below is correct, but does not answer to any of my
  >> questions/issues. In particular, the last one. I am still awaiting
  >> your responses.
  >>
  >> Denis
  >>
  >>> Denis:
  >>> RFC 3280 does not tell an implementor how for locate certificates for
  >>> any certification path construction.  There are several extensions
  >>> that provide pointers that may help an implementation, but other
  >>> approaches to obtaining the same certificates are always permitted.
  >>> I would fully expect an implementation to check any local cache
  >>> before accessing a repository.
  >>> The CRL AIA extension fits this pattern.  A method for locating a
  >>> certificate is provided, but any other mechanism for locating the
  >>> same certificate is acceptable.
  >>> Russ
  >>>
  >>>> Stefan,
  >>>>
  >>>> I made the e-mail shorter. Your main arguments are the following:
  >>>>
  >>>>
==========================================================================
  >>>>
  >>>>
  >>>> [Stefan] But it has to provide a warning to something that is
  >>>> introduced
  >>>> by the standard. This standard does not introduce the concept of CRL
  >>>> signature checking or CRL issuer certificate validation, so that is
  >>>> clearly out of scope. More about that below;
  >>>>
  >>>> [Denis] See below the last answer and also my arguments in the
  >>>> soon-to-be-posted answer to Russ.
  >>>>
  >>>>
==========================================================================
  >>>>
  >>>>
  >>>>
  >>>> > > RFC 3280 [PKIX1] specifies the validation of certification paths.
  >>>> > > One aspect involves the determination that a certificate has not
  >>>> been
  >>>> > > revoked, and one revocation checking mechanism is the Certificate
  >>>> > > Revocation List (CRL).  CRL validation is also specified in RFC
  >>>> 3280,
  >>>>
  >>>> > I would love this last sentence to be true but the reality is that:
  >>>> > "CRL validation is NOT specified in RFC 3280". :-(
  >>>>
  >>>> [Stefan] In fact it is.
  >>>>
  >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85:
  >>>>
  >>>>    (f)  Obtain and validate the certification path for the complete CRL
  >>>>    issuer.  If a key usage extension is present in the CRL issuer's
  >>>>    certificate, verify that the cRLSign bit is set.
  >>>>
  >>>>    (g)  Validate the signature on the complete CRL using the public key
  >>>>    validated in step (f).
  >>>>
  >>>> [Denis] The text does not say how to obtain and validate the
  >>>> certification path for the complete (???) CRL issuer. The text is
  >>>> not clear enough so that two implementors only looking at this
  >>>> sentence will provide interoperable implementations.
  >>>>
  >>>>
==========================================================================
  >>>>
  >>>>
  >>>> [Stefan] It is my hope that the provided responses here can help
  >>>> convince you to change your mind about that. If it doesn't I still
  >>>> argue
  >>>> that the place to specify requirements and security considerations for
  >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft.
  >>>>
  >>>> [Denis] I can agree with your last sentence, ... which means that it
  >>>> should not be in the main body of the document. In the security
  >>>> considerations section, text is free and we shall at the very
  >>>> minimum warn implementers and we should provide some guidance. When
  >>>> the same certification path (i.e. the path used to validate the
  >>>> target certificate) is used, then there is no security issue: this
  >>>> should be said. For all other cases, there MAY be problems: this
  >>>> should also be said. It is as simple as that.
  >>>>
  >>>> Denis
  >>>
  >>
  >>
  >
  >

Date: Thu, 12 May 2005 11:23:58 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: David Cross <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

David,

Since Tim has now made the call at the WG level, please consider this
message as an answer to the call.

 > Denis:

 > I have to disagree on removal of the text. I have not seen any
 > objections from the list or working group to this inclusion.  I have to
 > disagree with your assertion that removing the text is a more secure
 > recommendation.  The below text (slightly edited to my taste) is an
 > excellent recommendation from an implementation standoint and a security
 > consideration.

You are using the wording "excellent" but as it will be demonstrated this is
far from excellent.

 > I would personally concede that using MUST *may* be
 > incorrect here and a SHOULD *may* be more appropriate.

Fine.

 > As a means of mitigating implementation challenges and security
 > issues related to issuer name collisions, CA names SHOULD be
  > formed in such a way that reduce the likelihood of name collisions.

The word "mitigating" is used: it already indicates that it is not a secure
solution. While this recommendation is wise, nothing forces CA to follow
it. So the question is : what would happen if a CA name is formed in such
a way that there is a name collision ? Relying parties cannot base their
security on this "SHOULD requirement".

So this does not suppress the issue: this should clearly be said that this
is not a solution.

 > Implementations validating CRLs SHOULD ensure that the certification
 > path of the target certificate and the CRL issuer certification path
 > used to validate the target certificate, terminate at a common trust
 > anchor.

This does not solve the issue either. Under the same trust anchor there may
be a tree with many branches and leaves, nothing prevents two CRL Issuers to
have the same name.

For this reason the proposed text is inappropriate.

Denis

 > On Behalf Of Denis Pinkas
 > Sent: Tuesday, May 10, 2005 12:01 AM
 > To: Russ Housley
 > Cc: [email-masked]
 > Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
 >
 >
 > Russ,
 >
 >
 >>Denis:
 >>
 >>Yes, it is OBVIOUS that the CRL issuer certificate needs to be
 >
 > validated.
 >
 >>You say that it is not clear what validation policy needs to be used,
 >>but this is completely irrelevant to the discussion of the CRL AIA
 >>extension.  This extension aid in certification path construction, not
 >
 >
 >>the validation of the path once it is constructed.
 >
 >
 > Not exactly, it could "help" finding a wrong path !
 >
 >
 >>There are many factors which need to be considered in the validation
 >>of the CRL issue certificate.  The values of the key usage extension
 >>and the certificate policies extension are two that jump to mind.
 >>There are probably more if I spend the time to consider each possible
 >
 > scenario.
 >
 > One simple rule would allow no security problem at all and I wonder why
 > you have so much resistance to mention it.
 >
 >
 >>In my opinion, this document is ready for WG Last Call.
 >
 >
 > As an editor of the draft, I may understand your position; but it is up
 > the the PKIX chairs to decide whether or not the document is ready for
 > WG last call.
 >
 > Once again the current Security Considerations section is not
 > acceptable.
 > In particular it contains a "MUST" statement that cannot be placed in
 > such a section and which is in addition fully wrong.
 >
 > Hereabove is the last one from draft 01:
 >
 > 3  Security Considerations
 >
 >       Implementers should take into account the possible existence of
 >       multiple unrelated CAs and CRL issuers with the same name.  As
 >       means of reducing problems and security issues related to issuer
 >       name collisions, CA names SHOULD be formed in a way that reduce
 > the
 >       likelihood of name collisions.  Implementations validating CRLs
 >       MUST ensure that the certification path of the target certificate
 >       and the CRL issuer certification path used to validate the target
 >       certificate, terminate at the same trust anchor.
 >
 >       Implementers should be aware of risks involved if the Authority
 >       Information Access extensions of corrupted CRLs contain links to
 >       malicious code.  Implementers should always take the steps of
 >       validating the retrieved data to ensure that the data is properly
 >       formed.
 >
 > Hereafter is a "minimalist" rewriting of this section, if we take the
 > choice to mention the issue, but not to provide any secure solution
 > (mentioning insecure or insufficient solutions is not appropriate). Two
 > sentences have thus been deleted.
 >
 > 3  Security Considerations
 >
 >       Implementers should take into account the possible existence of
 >       multiple unrelated CAs and CRL issuers with the same name.
 >
 >       Implementers should be aware of risks involved if the Authority
 >       Information Access extensions of corrupted CRLs contain links to
 >       malicious code.  Implementers should always take the steps of
 >       validating the retrieved data to ensure that the data is properly
 >       formed.
 >
 > Denis
 >
 >
 >
 >>Russ
 >>
 >>
 >>At 09:07 AM 5/9/2005, Denis Pinkas wrote:
 >>
 >>
 >>>Russ,
 >>>
 >>>
 >>>>Here is a quote from RFC 3280.  To me, it is clear that a CRL
 >>>>issuer
 >>>
 >>>has
 >>>
 >>>>a certificate.
 >>>
 >>>True, a CRL issuer (that is different from the CA that has issued the
 >>
 >
 >>>target
 >>>certificate) has a certificate. So we both strongly agree on this
 >>>this. :-)
 >>>
 >>>
 >>>>Obviously, all certificates need to be validated, which includes
 >>>>certification path construction and certification path
 >>>
 >>>validation.
 >>>
 >>>When a sentence starts with "Obviously", it means that it is not so
 >>>obvious.
 >>>:-|
 >>>
 >>>The real question is whether the CRL issuer certificate has to be
 >>>verified using rules (i.e. a validation policy) which are independent
 >>
 >
 >>>from the certification path construction of the target certificate.
 >>>RFC 3280 does not provide a crystal clear answer to that question.
 >>>
 >>>If the rules are different, then you MAY end up with a security issue
 >>
 >
 >>>(see my previous explanations). The current "recommendations" that
 >>>are in the security considerations section do NOT solve this issue in
 >>
 >
 >>>the general case.
 >>>
 >>>If the rules are the same, i.e. the path used to validate the
 >>>certification path from the certificate are also used, then there is
 >>>no security issue.
 >>>
 >>>I do not think it would be good to hide this issue in the proposed
 >>
 > draft.
 >
 >>>Anyway, the current "recommendations" do NOT solve the issue and are
 >>>thus not acceptable and so this section cannot stand as it is.
 >>>
 >>>Denis
 >>>
 >>>
 >>>>5.1.1.3  signatureValue
 >>>>
 >>>>   The signatureValue field contains a digital signature computed
 >>>
 > upon
 >
 >>>>   the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded
 >>>
 >>>tbsCertList
 >>>
 >>>>   is used as the input to the signature function.  This signature
 >>>
 >>>value
 >>>
 >>>>   is encoded as a BIT STRING and included in the CRL
 >>>
 > signatureValue
 >
 >>>>   field.  The details of this process are specified for each of
 >>>
 > the
 >
 >>>>   supported algorithms in [PKIXALGS].
 >>>>
 >>>>   CAs that are also CRL issuers MAY use one private key to
 >>>
 > digitally
 >
 >>>>   sign certificates and CRLs, or MAY use separate private keys to
 >>>>   digitally sign certificates and CRLs.  When separate private
 >>>>keys
 >>>
 >>>are
 >>>
 >>>>   employed, each of the public keys associated with these private
 >>>
 > keys
 >
 >>>>   is placed in a separate certificate, one with the keyCertSign
 >>>>bit
 >>>
 >>>set
 >>>
 >>>>   in the key usage extension, and one with the cRLSign bit set in
 >>>
 > the
 >
 >>>>   key usage extension (section 4.2.1.3).  When separate private
 >>>
 > keys
 >
 >>>>   are employed, certificates issued by the CA contain one
 >>>>authority
 >>>
 >>>key
 >>>
 >>>>   identifier, and the corresponding CRLs contain a different
 >>>
 > authority
 >
 >>>>   key identifier.  The use of separate CA certificates for
 >>>
 > validation
 >
 >>>>   of certificate signatures and CRL signatures can offer improved
 >>>>   security characteristics; however, it imposes a burden on
 >>>>   applications, and it might limit interoperability.  Many
 >>>
 >>>applications
 >>>
 >>>>   construct a certification path, and then validate the
 >>>
 > certification
 >
 >>>>   path (section 6).  CRL checking in turn requires a separate
 >>>>   certification path to be constructed and validated for the CA's
 >>>
 > CRL
 >
 >>>>   signature validation certificate.  Applications that perform CRL
 >>>>   checking MUST support certification path validation when
 >>>
 >>>certificates
 >>>
 >>>>   and CRLs are digitally signed with the same CA private key.
 >>>
 > These
 >
 >>>>   applications SHOULD support certification path validation when
 >>>>   certificates and CRLs are digitally signed with different CA
 >>>
 > private
 >
 >>>>   keys.
 >>>>
 >>>>Russ
 >>>>
 >>>>At 01:12 PM 4/28/2005, Denis Pinkas wrote:
 >>>>
 >>>>
 >>>>>Stefan and Russ,
 >>>>>
 >>>>>
 >>>>>>Denis,
 >>>>>
 >>>>>
 >>>>>>Russ and I have taken a thorough look at your text proposal and
 >>>>>>we
 >>>>>
 >>>have
 >>>
 >>>>>>edited a counter proposal where we try to meet your needs as much
 >>>>>
 >
 >>>>>>as possible without compromising what we think is the core
 >>>>>>purpose of
 >>>>>
 >>>the
 >>>
 >>>>>>draft (to enable certificate discovery bottom-up).
 >>>>>
 >>>>>
 >>>>>>The conclusion is that we suggest changes to the introduction
 >>>>>>section but we keep the old security considerations intact.
 >>>>>
 >>>>>
 >>>>>I would suggest that a merge would need to be done between the
 >>>>
 > "old"
 >
 >>>>>security considerations section and the "new" one.
 >>>>>
 >>>>>The "old" security considerations section is mentionning a
 >>>>>solution which does NOT suppress the problem, but minimize the
 >>>>>risk only in case the CAs are really "honest".
 >>>>>
 >>>>>The old" security considerations section does not provide a
 >>>>>solution in case the name collsion between two CRL issuer name is
 >>>>>deliberate, whereas the "new" security considerations section
 >>>>>provides a secure solution in one case and clearly mentions that
 >>>>>all other cases are dependant about "zillions" of *local* trust
 >>>>>conditions which cannot all be standardized.
 >>>>>
 >>>>>The main purpose of a security considerations section is to
 >>>>>provide the adequate warnings and solutions when they exist and
 >>>>>not to hide the problems.
 >>>>>
 >>>>>
 >>>>>>That is not because
 >>>>>>we necessarily disagree with all of the statements in your
 >>>>>
 >>>proposal, but
 >>>
 >>>>>>in the cases we don't, we still think it is out of scope for this
 >>>>>
 >>>work.
 >>>
 >>>>>
 >>>>>This is clearly within the scope of a security considerations
 >>>>
 > section.
 >
 >>>>>>The new introduction proposal based on your input is:
 >>>>>>--------------------------------------------------------------
 >>>>>>RFC 3280 [PKIX1] specifies the validation of certification paths.
 >>>>>
 >
 >>>One
 >>>
 >>>>>>aspect involves the determination that a certificate has not been
 >>>>>
 >
 >>>>>>revoked, and one revocation checking mechanism is the Certificate
 >>>>>
 >
 >>>>>>Revocation List (CRL).  CRL validation is also specified in RFC
 >>>>>>3280,
 >>>>>
 >>>>>
 >>>>>I would love this last sentence to be true but the reality is
 >>>>
 > that:
 >
 >>>>>"CRL validation is NOT specified in RFC 3280". :-(
 >>>>>
 >>>>>
 >>>>>>which involves the constructions of a valid certification path
 >>>>>>for
 >>>>>
 >>>the
 >>>
 >>>>>>CRL issuer.
 >>>>>
 >>>>>
 >>>>>There is no such a statement in RFC 3280.
 >>>>>
 >>>>>
 >>>>>>Building a CRL issuer certification path from the signer of
 >>>>>
 >>>>>
 >>>>>There is no notion of "CRL issuer certification path" in RFC 3280.
 >>>>>The primary requirement is to make sure that the CRL issuer
 >>>>>designated by the CA is indeed the right one. In some (but not
 >>>>>all) cases, I mean among the zillion of cases, there MAY be a need
 >>>>
 >
 >>>>>to construct a CRL issuer certification path.
 >>>>>
 >>>>>
 >>>>>>the CRL to a trust anchor is straightforward when the certificate
 >>>>>
 >>>of the
 >>>
 >>>>>>CRL issuer is present in the certification path associated with
 >>>>>>the target certificate, but it can be complex in other
 >>>>>
 > situations.
 >
 >>>>>
 >>>>>From the comments above, you can see that I cannot agree with the
 >>>>>above revised text. The remaining of the text is acceptable in
 >>>>>general, but could possibly be slightly revised to be more in
 >>>>>continuation with the changes there are needed above (i.e. it is
 >>>>>not cast in concrete).
 >>>>>
 >>>>>Denis
 >>>>>
 >>>>>
 >>>>>>There are several legitimate scenarios where the certificate of
 >>>>>
 >>>the CRL
 >>>
 >>>>>>issuer is not present, or easily discovered, from the target
 >>>>>>certification path.  This can be the case when indirect CRLs are
 >>>>>
 >>>used,
 >>>
 >>>>>>when the certification Authority (CA) that issued the target
 >>>>>
 >>>certificate
 >>>
 >>>>>>changes its certificate signing key, or when the CA employs
 >>>>>>separate keys for certificate signing and CRL signing.
 >>>>>>Methods of finding the certificate of the CRL issuer are
 >>>>>>currently available, such as though an accessible directory
 >>>>>>location or through use of the Subject Information Access
 >>>>>>extension in intermediary CA certificates.
 >>>>>>Directory lookup requires existence and access to a directory
 >>>>>>that
 >>>>>
 >>>has
 >>>
 >>>>>>been populated with all of the necessary certificates.  The
 >>>>>>Subject Information Access extension, which supports building the
 >>>>>
 >
 >>>>>>CRL issuer certification path top-down (in the direction from the
 >>>>>
 >
 >>>>>>trust
 >>>>>
 >>>anchor to
 >>>
 >>>>>>the CRL issuer), requires that some certificates in the CRL
 >>>>>>issuer certification path includes an appropriate Subject
 >>>>>>Information Access extension.
 >>>>>>RFC 3280 [PKIX1] provides for bottom-up discovery of
 >>>>>>certification
 >>>>>
 >>>paths
 >>>
 >>>>>>through the Authority Information Access extension, where the
 >>>>>>id-ad-caIssuers access method may specify one or more
 >>>>>>accessLocation fields that reference CA certificates associated
 >>>>>>with the certificate containing this extension.
 >>>>>>This document enables the use of the Authority Information Access
 >>>>>
 >
 >>>>>>extension in CRLs, enabling a CRL checking application to use the
 >>>>>
 >>>access
 >>>
 >>>>>>method (id-ad-caIssuers) to locate certificates that may be
 >>>>>>useful in the construction of a valid CRL issuer certification
 >>>>>>path to an appropriate trust anchor.
 >>>>>>
 >>>>>>Stefan Santesson
 >>>>>>Program Manager, Standards Liaison Windows Security
 >>>>>>
 >>>>>>
 >>>>>>
 >>>>>>>From: Denis Pinkas [mailto:[email-masked]]
 >>>>>>>Sent: den 18 april 2005 13:41
 >>>>>>>To: Stefan Santesson
 >>>>>>>Cc: Russ Housley; pkix
 >>>>>>>Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
 >>>>>>>
 >>>>>>>Stefan,
 >>>>>>>
 >>>>>>>
 >>>>>>>
 >>>>>>>>Denis,
 >>>>>>>
 >>>>>>>
 >>>>>>>>I will come back and comment on your text proposals, but before
 >>>>>>>
 >>>>>>that,
 >>>>>>
 >>>>>>
 >>>>>>>>a few questions/comments:
 >>>>>>>
 >>>>>>>
 >>>>>>>><snip>
 >>>>>>>
 >>>>>>>
 >>>>>>>>>>You point out some well known issues related to the lack of
 >>>>>>>>>
 >>>>>>absolute
 >>>>>>
 >>>>>>
 >>>>>>>>>>cryptographic binding between CRL and certificates where the
 >>>>>>>>>>certificate and CRL is not signed by the same key.
 >>>>>>>>>
 >>>>>>>>>
 >>>>>>>>>Not really. It is indeed possible to have an absolute
 >>>>>>>>
 >>>cryptographic
 >>>
 >>>>>>>>>binding between CRL and certificates where the certificate and
 >>>>>>>>
 > CRL
 >
 >>>>>>is
 >>>>>>
 >>>>>>
 >>>>>>>not
 >>>>>>>
 >>>>>>>
 >>>>>>>>>signed by the same key, but the key point is that proposed
 >>>>>>>>
 >>>>>>extension
 >>>>>>
 >>>>>>
 >>>>>>>>>is *not* the means to provide such a binding (and you agree
 >>>>>>>>
 > with
 >
 >>>>>>this
 >>>>>>
 >>>>>>
 >>>>>>>>>further down in this e-mail).
 >>>>>>>>
 >>>>>>>
 >>>>>>>>We agree that this extension does not add to the concept of
 >>>>>>>>cryptographic binding. But how do you mean it can be done?
 >>>>>>>
 >>>>>>>
 >>>>>>>Would this mean that you believed this could not be done ? :-)
 >>>>>>>
 >>>>>>>I already provided the information, but since at that time you
 >>>>>>
 > were
 >
 >>>>>>>focussing on another issue, you probably missed the point.
 >>>>>>>
 >>>>>>>I would encourage you to read again that thread, but I will
 >>>>>>
 >>>provide a
 >>>
 >>>>>>>short
 >>>>>>>reply here to your question.
 >>>>>>>
 >>>>>>>This can be done using cRLIssuer from the CRL DP. cRLIssuer
 >>>>>>
 > contains
 >
 >>>>>>the
 >>>>>>
 >>>>>>
 >>>>>>>DN
 >>>>>>>of the CRL Issuer and we all know that CAs are free to assign
 >>>>>>
 > the
 >
 >>>DNs
 >>>
 >>>>>>they
 >>>>>>
 >>>>>>
 >>>>>>>wish. The next point is for a verifier to make sure that the DN
 >>>>>>
 >>>which
 >>>
 >>>>>>>identifies the CRL Issuer (in the CRL DP) is indeed the one that
 >>>>>>
 > was
 >
 >>>>>>meant
 >>>>>>
 >>>>>>
 >>>>>>>by the CA. The CRL must be issued by a CRL Issuer that has the
 >>>>>>
 > same
 >
 >>>>>>DN.
 >>>>>>
 >>>>>>
 >>>>>>>The
 >>>>>>>CRL Issuer will have a certificate issued by a CA.
 >>>>>>>
 >>>>>>>Case a): the CA that has issued that certificate is the same as
 >>>>>>
 >>>the CA
 >>>
 >>>>>>>that
 >>>>>>>has issued the target certificate (which contains the hereabove
 >>>>>>
 >>>>>>mentionned
 >>>>>>
 >>>>>>
 >>>>>>>CRL DP). This is easy to check for a verifier since the verifier
 >>>>>>
 >
 >>>must
 >>>
 >>>>>>>first
 >>>>>>>build the certification path and then test the revocation status
 >>>>>>
 > of
 >
 >>>>>>every
 >>>>>>
 >>>>>>
 >>>>>>>element of the path. So the verifier knows the validated
 >>>>>>
 > sequence of
 >
 >>>>>>DNs
 >>>>>>
 >>>>>>
 >>>>>>>starting from a self-signed certificate. It must then use the
 >>>>>>
 > same
 >
 >>>>>>>sequence
 >>>>>>>of DNs to validate the CRL Issuer certificate.
 >>>>>>>
 >>>>>>>This is a general rule which does not require any extra local
 >>>>>>
 > trust
 >
 >>>>>>>information.
 >>>>>>>
 >>>>>>>Case b) : the CA that has issued that certificate is NOT the
 >>>>>>
 > same as
 >
 >>>>>>the
 >>>>>>
 >>>>>>
 >>>>>>>CA
 >>>>>>>that has issued the target certificate. This case requires extra
 >>>>>>
 >>>>>>*0local*
 >>>>>>
 >>>>>>
 >>>>>>>trust information. There are many such trust conditions possible
 >>>>>>
 > and
 >
 >>>>>>thus
 >>>>>>
 >>>>>>
 >>>>>>>this cannot be defined in general. Cases a) and b) are thus not
 >>>>>>
 >>>>>>equivalent
 >>>>>>
 >>>>>>
 >>>>>>>and have to be distinguished.
 >>>>>>>
 >>>>>>>
 >>>>>>>
 >>>>>>>><snip>
 >>>>>>>
 >>>>>>>
 >>>>>>>>>>This draft only introduces a new way to locate certificates
 >>>>>>>>>>that can be helpful in building this path.
 >>>>>>>>>
 >>>>>>>>>
 >>>>>>>>>At least one sentence of which we both agree !
 >>>>>>>>>It should be copied and pasted in the abstract.
 >>>>>>>>
 >>>>>>>>
 >>>>>>>>Good, then I suggest that we leave unrelated topics out of this
 >>>>>>>
 >>>>>>draft
 >>>>>>
 >>>>>>
 >>>>>>>>and focus on the issues that are related to this limited scope.
 >>>>>>>
 >>>>>>>
 >>>>>>>This is what I did in my proposal, except that we need to have a
 >>>>>>
 >>>>>>security
 >>>>>>
 >>>>>>
 >>>>>>>considerations section and the goal of that section is not to
 >>>>>>
 > hide
 >
 >>>>>>>problems
 >>>>>>>but to correctly warn users. Thus why an informatiove annex on
 >>>>>>
 > the
 >
 >>>>>>topics
 >>>>>>
 >>>>>>
 >>>>>>>mentionned in the security considerations section would be quite
 >>>>>>
 >>>>>>useful.
 >>>>>>
 >>>>>>
 >>>>>>>In fact, its content would be along the lines of the
 >>>>>>
 > explanations
 >
 >>>>>>which
 >>>>>>
 >>>>>>
 >>>>>>>are
 >>>>>>>just above.
 >>>>>>>
 >>>>>>>I hope this e-mail will help us to progress.
 >>>>>>>
 >>>>>>>Denis
 >>>>>>>
 >>>>>>>
 >>>>>>>
 >>>>>>>>Stefan Santesson
 >>>>>>>>Program Manager - Standards Liaison
 >>>>>>>>Windows Security
 >>>>>>>
 >>>>>
 >>>>
 >>>
 >>>
 >>
 >
 >
 >

Date: Thu, 12 May 2005 01:51:24 -0700
To: "X.509":;
From: Hoyt L Kesterson II <[email-masked]>
Subject: Technical Corrigenda 3 to the 4th edition of X.509
Sender: [email-masked]

<!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>Technical Corrigenda 3 to the 4th edition of
X.509</title></head><body>
<div>Some you worked with the X.509 standards committee over the last
few years revising the text on key usage.</div>
<div><br></div>
<div>The Technical Corrigenda containing that revised text was
approved and is currently being incorporated into the 5th edition
currently being prepared.</div>
<div><br></div>
<div>You can find the text of that Technical Corrigenda at:</div>
<div><br></div>
<div><font face="Lucida Grande"
color="#000000"
>ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrig<span
></span>enda/ApprovedTechnicalCorrigendaToX.509/8|X.509-TC3(4th).pdf</font
></div>
<div><font face="Lucida Grande" color="#000000"><br></font></div>
<div><font face="Lucida Grande" color="#000000">Note that this
document is written as a set of editing instructions to integrate the
text into the 4th edition. If you prefer to wait, the 5th edition will
be published before the end of the year</font></div>
<div><font face="Lucida Grande" color="#000000"><br></font></div>
<div><font face="Lucida Grande" color="#000000">&nbsp;&nbsp;
hoyt</font></div>
</body>
</html>

Date: Thu, 12 May 2005 01:54:12 -0700
To: "X.509":;
From: Hoyt L Kesterson II <[email-masked]>
Subject: the certificate enhancement DAM
Sender: [email-masked]

<!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>the certificate enhancement
DAM</title></head><body>
<div>The directory group has completed work on a new amendment to the
standard. That amendment is currently being integrated, along with
approved TCs, into the 5th edition of the standard. That edition will
be published before the end of the year.</div>
<div><br></div>
<div>The amendment can be found at</div>
<div><br></div>
<div>&nbsp;<font face="Lucida Grande" size="-4" color="#000000">
ftp://ftp.bull.com/pub/OSIdirectory/Orlando2004Output/6N12793Certific<span
></span>ateEnhancementDAM.pdf</font></div>
<div><font face="Lucida Grande" size="-4"
color="#000000"><br></font></div>
<div><font face="Lucida Grande" size="-4"
color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
hoyt</font></div>
</body>
</html>

From: "Wen-Cheng Wang" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Date: Thu, 12 May 2005 13:33:10 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

Peter,

I think your clarification about the distinction between the
keyEncipherment bit and the dataEncipherment bit is good.
It would be better if RFC 3280 and X.509 could revise
the explanation of the dataEncipherment bit based on your
clarification.
However, I worried that the statement "This (dataEncipherment)
bit MUST NOT be set when the intention is to encipher
intermediate cryptographic keys rather than raw user data" might
mislead the reader to believe that the keyEncipherment bit and the
dataEncipherment bit are mutually exclusive. Therefore, I suggest
to revise the statement as "The dataEncipherment bit should not be
use to represent the intention of allowing enciphering intermediate
cryptographic keys. In that case, the keyEncipherment bit should
be set."

Wen-Cheng Wang

----- Original Message ----- 
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 11, 2005 5:39 PM
Subject: Re: key usage - key encipherment or data encipherment

>
> "Wen-Cheng Wang" <[email-masked]> writes:
>
>>It is better to clarify that it is legitimate to assert both the
>>keyEncipherment bit and the dataEncipherment bit in one certificate. In that
>>case, it means that the key (e.g., RSA key) may be used for enciphering
>>intermediate cryptographic keys or directly enciphering raw user data (e.g.,
>>user password).
>
> Saying you can use both bits won't help, it still leaves it ambiguous to users
> as to what dataEncipherment should be used for.  One interpretation I've heard
> of is keyEncipherment = exchange of session keys (SSL), dataEncipherment =
> data encryption (S/MIME).
>
> Peter.
> 

From: "Wen-Cheng Wang" <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Date: Thu, 12 May 2005 13:10:18 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

Russ,

Yes, RFC 3280 is quite clear for that. However, I worried
that the discussions of this thread might mislead the
participants into believing that the two bits are mutually
exclusive. Therefore, I simply want to remind the
participants of this thread the fact that the keyEncipherment
bit and dataEncipherment bit can work well togethor.

Wen-Cheng Wang

----- Original Message ----- 
From: "Russ Housley" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 11, 2005 11:40 PM
Subject: Re: key usage - key encipherment or data encipherment

>I believe that RFC 3280 is quite clear that more than one of these bits can 
> be set.  It says:
> 
>    This profile does not restrict the combinations of bits that may be
>    set in an instantiation of the keyUsage extension.  However,
>    appropriate values for keyUsage extensions for particular algorithms
>    are specified in [PKIXALGS].
> 
> Russ
> 
> At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote:
> 
> 
>>Peter Gutmann <[email-masked]> wrote:
>>>Andrew Sciberras <[email-masked]> writes:
>>>
>>>>     The keyEncipherment bit is asserted when the subject public key is
>>>>      used for key transport.  For example, when an RSA key is to be
>>>>      used for key management, then this bit shall asserted.
>>>>
>>>>      The dataEncipherment bit is asserted when the subject public key
>>>>      is used for enciphering user data, other than cryptographic keys.
>>>Quoting that won't help (I've seen this sort of thing before) because as far
>>>as the user is concerned what's being encrypted is data, so the valid bit to
>>>use is dataEncipherment (quite logical to them).  What might help is to make
>>>this more explicit in the text:
>>>  The dataEncipherment bit is asserted when the subject public key is 
>>> used for
>>>  directly enciphering raw user data without the use of an intermediate
>>>  symmetric cipher.  This bit MUST NOT be set when the intention is to
>>>  encipher intermediate cryptographic keys rather than raw user data.
>>It is better to clarify that it is legitimate to assert both the 
>>keyEncipherment bit
>>and the dataEncipherment bit in one certificate. In that case, it means 
>>that the
>>key (e.g., RSA key) may be used for enciphering intermediate cryptographic
>>keys or directly enciphering raw user data (e.g., user password).
>>
>>Wen-Cheng Wang
>>
>>
>

From: "Wen-Cheng Wang" <[email-masked]>
To: "Miguel A Rodriguez" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Date: Thu, 12 May 2005 12:56:42 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

FYI:  In the Asia PKI Interoperability Guideline (prepared by
Asia PKI Forum), we suggest CA vendors or operators to
assert both the keyEncipherment and dataEncipherment bits
in an encryption cert. The main reason is that we intend to allow
users to use the public key for directly enciphering raw user data.
We certainly know that the public key is usually used to encrypt
intermediate cryptographic keys. However, what if someday
users really want to use that public key for directly enciphering
raw user data (e.g., user password)? For the sake of supporting
both kinds of encipherment, it is better to assert both bits in the
beginning. I see no reason why a public key certified by an
"encryption" certificate should be prohibit from being used for
directly enciphering small-size user data. The second reason is
that we believe that asserting both bits is helpful to achieve
maximum Interoperability. By asserting both bits, no matter which
interpretation the application implementators adopt, the cert
should always work.
Anyway, I believe that it is not harmful if the dataEncipherment
bit is asserted in an encryption cert in addition to the
keyEncipherment bit.

Wen-Cheng Wang

----- Original Message ----- 
From: "Russ Housley" <[email-masked]>
To: "Miguel A Rodriguez" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 12, 2005 3:57 AM
Subject: RE: key usage - key encipherment or data encipherment

>
> As far as I know, SET was the only protocol that used data encipherment.  Of course, SET used the 
> same RSA public key for both data encipherment and key encipherment.
>
> Russ
>
> At 01:20 PM 5/11/2005, Miguel A Rodriguez wrote:
>
>>Does anyone use dataEncipherment?
>>
>>Miguel A Rodr�guez
>>SeguriData
>>Mexico
>>
>>At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote:
>>
>>
>> >Peter Gutmann <[email-masked]> wrote:
>> >>Andrew Sciberras <[email-masked]> writes:
>> >>
>> >>>     The keyEncipherment bit is asserted when the subject public key
>>is
>> >>>      used for key transport.  For example, when an RSA key is to be
>> >>>      used for key management, then this bit shall asserted.
>> >>>
>> >>>      The dataEncipherment bit is asserted when the subject public
>>key
>> >>>      is used for enciphering user data, other than cryptographic
>> >>> keys.
>> >>Quoting that won't help (I've seen this sort of thing before) because
>> >>as far as the user is concerned what's being encrypted is data, so the
>>
>> >>valid bit to use is dataEncipherment (quite logical to them).  What
>> >>might help is to make this more explicit in the text:
>> >>  The dataEncipherment bit is asserted when the subject public key is
>> >> used for
>> >>  directly enciphering raw user data without the use of an
>>intermediate
>> >>  symmetric cipher.  This bit MUST NOT be set when the intention is to
>> >>  encipher intermediate cryptographic keys rather than raw user data.
>> >It is better to clarify that it is legitimate to assert both the
>> >keyEncipherment bit
>> >and the dataEncipherment bit in one certificate. In that case, it means
>>
>> >that the
>> >key (e.g., RSA key) may be used for enciphering intermediate
>>cryptographic
>> >keys or directly enciphering raw user data (e.g., user password).
>> >
>> >Wen-Cheng Wang
>> >
>> >
> 

Date: Thu, 12 May 2005 12:14:40 +1000
From: "Simon McMahon" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

Russ,

They were calling an 'encrypt' function to encrypt XML data and they gave it an RSA key (the cert actually) to do it. Of course it internally made an AES key but they never saw it until the interoperability issue made them look. From what they saw at the level they were looking the interpretation was reasonable. When the transport key is well hidden and simply part of the protocol then it looks just like RSA is encrypting big slabs of data. If you know that RSA is bound by the modulus size then you know what is really happening but not all users of PKI know RSA so well. Why should they?

Couple this interpretation of key-usage with a dubious decision to reject encryption requests with certs that dont have key-usage='data encipherment' and you have an interoperability problem. I say "dubious" because it is a public key so you cannot enforce usage policy anyway. The CA could set both flags to fix it, which by the way was the vendors preferred solution, but its not my CA or their CA and the CA doesn't do that. Why should they?

This reference, in my opinion, allows the ambiguous interpretation:
>     The keyEncipherment bit is asserted when the subject public key is
>      used for key transport.  For example, when an RSA key is to be
>      used for key management, then this bit shall asserted.
>
>      The dataEncipherment bit is asserted when the subject public key
>      is used for enciphering user data, other than cryptographic keys.

In this case the public key is clearly "intended" to be used to encrypt the XML data but it just doesn't do it directly because it cant. The term "key management" also has associations with more basic and explicit key management operations like installing trusted root certs or secure installation of shared secret keys etc. In this case it is much less obvious that key management is happening because the key is bundled with the data. It looks just like the public key is encrypting the data.

In my opinion there are 3 cases presented as 2 in the RFC.
1. RSA encrypts data - hardly ever used.
2. RSA implicitly encrypts keys so it can really encrypt bulk data - common usage.
3. RSA explicitly encrypts keys for explicit key management functions - common usage.
The current bits separate 1 from 2/3 yet people make the interpretation that they split the more common 2 from 3 assuming 1 and 2 are the same thing. Knowledge of RSA is required to know that 1 and 2 are different.

Peter's comment "This bit MUST NOT be set when the intention is to encipher intermediate cryptographic keys rather than raw user data" is most relevant in my case. Does PKIX support this clarification?

In my opinion this problem will not entirely go away by clarifying the standard because most people dont read it before they implement something. The two bits are there and as long as they are both there then the mistake will be made by busy developers. Unenforceable key-usage policy, to "public" keys, will also continue to be implemented. People will come looking for clarification once they have an interoperability issue but by then it is often too late - the issue usually gets decided by who has the biggest corporate balls. In this case it wasn't too late so thanks for the assistance.

If I could recommend a change to the standard then I would suggest dropping one of the encryption bits and just have a single key-usage = "encryption". Give it the value the same as "key-encryption" since this is the common usage.

Thanks,

Simon McMahon.

Simon McMahon

Work: (07) 31311420
Mobile: (043) 2294180

>>> Russ Housley <[email-masked]> 05/12/05 01:06am >>>
Simon:

If they are encrypting the XML data directly with the RSA key (which is 
very unlikely), then they are correct.

The traditional way to handle this is to generate a random 
content-encryption key (CEK) and then encrypt the XML data with a symmetric algorithm using the CEK.  The CEK is encrypted with the RSA key from the certificate.  Thus, the RSA key is really being used to encrypt only 
symmetric keys.

Russ

  At 08:33 PM 5/10/2005, Simon McMahon wrote:

>Hi,
>
>I have had a recent interoperability issue with a application vendor that >didn't like the key-usage attributes in a cert from a CA vendor's 
>certificate. Signing certs work fine, it was an encryption cert that failed.
>
>CA sets key-usage = "key encipherment".
>Application wants to encrypt some XML data so looks for key-usage = "data 
>encipherment". Reason - because XML is data, not a key.
>
>I believe the application vendor is wrong and I explained that the RSA key >actually encrypts an AES key so it doesn't directly encrypt the data but >they want an official "pkix" ruling based on the standard so can someone >please refer me to a statement in the standard that clears this up.
>
>Thanks,
>
>Simon McMahon.
>
>
>
>Simon McMahon
>
>Work: (07) 31311420
>Mobile: (043) 2294180
>
>
>
>Simon McMahon
>
>Work: (07) 31311420
>Mobile: (043) 2294180
>
>
>
>
>***********************************************************************************
>This email, including any attachments sent with it, is confidential and 
>for the sole use of the intended recipient(s).  This confidentiality is 
>not waived or lost, if you receive it and you are not the intended 
>recipient(s), or if it is transmitted/received in error.
>
>Any unauthorised use, alteration, disclosure, distribution or review of 
>this email is prohibited.  It may be subject to a statutory duty of 
>confidentiality if it relates to health service matters.
>
>If you are not the intended recipient(s), or if you have received this 
>email in error, you are asked to immediately notify the sender by 
>telephone or by return email.  You should also delete this email and 
>destroy any hard copies produced.
>***********************************************************************************

***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************

Date: Wed, 11 May 2005 15:57:12 -0400
To: "Miguel A Rodriguez" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: key usage - key encipherment or data encipherment
Cc: [email-masked]
Sender: [email-masked]

As far as I know, SET was the only protocol that used data 
encipherment.  Of course, SET used the same RSA public key for both data 
encipherment and key encipherment.

Russ

At 01:20 PM 5/11/2005, Miguel A Rodriguez wrote:

>Does anyone use dataEncipherment?
>
>Miguel A Rodr�guez
>SeguriData
>Mexico
>
>At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote:
>
>
> >Peter Gutmann <[email-masked]> wrote:
> >>Andrew Sciberras <[email-masked]> writes:
> >>
> >>>     The keyEncipherment bit is asserted when the subject public key
>is
> >>>      used for key transport.  For example, when an RSA key is to be
> >>>      used for key management, then this bit shall asserted.
> >>>
> >>>      The dataEncipherment bit is asserted when the subject public
>key
> >>>      is used for enciphering user data, other than cryptographic
> >>> keys.
> >>Quoting that won't help (I've seen this sort of thing before) because
> >>as far as the user is concerned what's being encrypted is data, so the
>
> >>valid bit to use is dataEncipherment (quite logical to them).  What
> >>might help is to make this more explicit in the text:
> >>  The dataEncipherment bit is asserted when the subject public key is
> >> used for
> >>  directly enciphering raw user data without the use of an
>intermediate
> >>  symmetric cipher.  This bit MUST NOT be set when the intention is to
> >>  encipher intermediate cryptographic keys rather than raw user data.
> >It is better to clarify that it is legitimate to assert both the
> >keyEncipherment bit
> >and the dataEncipherment bit in one certificate. In that case, it means
>
> >that the
> >key (e.g., RSA key) may be used for enciphering intermediate
>cryptographic
> >keys or directly enciphering raw user data (e.g., user password).
> >
> >Wen-Cheng Wang
> >
> >

Date: Wed, 11 May 2005 14:02:30 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: Evaluating Rough Consensus for 3770bis
Sender: [email-masked]

After reviewing the traffic on the list, it appears to me that rough 
consensus has been achieved with the release of the latest draft of 
3770bis, "Certificate Extensions and Attributes Supporting Authentication 
in Point-to-Point Protocol (PPP) and Wireless Local Area Networks 
(WLAN)".  I intend to forward the document to Sam Hartman this Friday (May 
13) for progression unless I hear an outcry on the list.

The current draft is available at

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

Thanks,

Tim Polk

From: "Miguel A Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: RE: key usage - key encipherment or data encipherment
Date: Wed, 11 May 2005 12:20:46 -0500
Importance: Normal
Sender: [email-masked]

Does anyone use dataEncipherment?

Miguel A Rodr�guez
SeguriData
Mexico

At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote:

>Peter Gutmann <[email-masked]> wrote:
>>Andrew Sciberras <[email-masked]> writes:
>>
>>>     The keyEncipherment bit is asserted when the subject public key
is
>>>      used for key transport.  For example, when an RSA key is to be
>>>      used for key management, then this bit shall asserted.
>>>
>>>      The dataEncipherment bit is asserted when the subject public
key
>>>      is used for enciphering user data, other than cryptographic 
>>> keys.
>>Quoting that won't help (I've seen this sort of thing before) because 
>>as far as the user is concerned what's being encrypted is data, so the

>>valid bit to use is dataEncipherment (quite logical to them).  What 
>>might help is to make this more explicit in the text:
>>  The dataEncipherment bit is asserted when the subject public key is
>> used for
>>  directly enciphering raw user data without the use of an
intermediate
>>  symmetric cipher.  This bit MUST NOT be set when the intention is to
>>  encipher intermediate cryptographic keys rather than raw user data.
>It is better to clarify that it is legitimate to assert both the
>keyEncipherment bit
>and the dataEncipherment bit in one certificate. In that case, it means

>that the
>key (e.g., RSA key) may be used for enciphering intermediate
cryptographic
>keys or directly enciphering raw user data (e.g., user password).
>
>Wen-Cheng Wang
>
>

Date: Wed, 11 May 2005 11:40:16 -0400
To: "Wen-Cheng Wang" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Cc: <[email-masked]>
Sender: [email-masked]

I believe that RFC 3280 is quite clear that more than one of these bits can 
be set.  It says:

    This profile does not restrict the combinations of bits that may be
    set in an instantiation of the keyUsage extension.  However,
    appropriate values for keyUsage extensions for particular algorithms
    are specified in [PKIXALGS].

Russ

At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote:

>Peter Gutmann <[email-masked]> wrote:
>>Andrew Sciberras <[email-masked]> writes:
>>
>>>     The keyEncipherment bit is asserted when the subject public key is
>>>      used for key transport.  For example, when an RSA key is to be
>>>      used for key management, then this bit shall asserted.
>>>
>>>      The dataEncipherment bit is asserted when the subject public key
>>>      is used for enciphering user data, other than cryptographic keys.
>>Quoting that won't help (I've seen this sort of thing before) because as far
>>as the user is concerned what's being encrypted is data, so the valid bit to
>>use is dataEncipherment (quite logical to them).  What might help is to make
>>this more explicit in the text:
>>  The dataEncipherment bit is asserted when the subject public key is 
>> used for
>>  directly enciphering raw user data without the use of an intermediate
>>  symmetric cipher.  This bit MUST NOT be set when the intention is to
>>  encipher intermediate cryptographic keys rather than raw user data.
>It is better to clarify that it is legitimate to assert both the 
>keyEncipherment bit
>and the dataEncipherment bit in one certificate. In that case, it means 
>that the
>key (e.g., RSA key) may be used for enciphering intermediate cryptographic
>keys or directly enciphering raw user data (e.g., user password).
>
>Wen-Cheng Wang
>
>

Date: Wed, 11 May 2005 11:06:39 -0400
To: "Simon McMahon" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Cc: [email-masked]
Sender: [email-masked]

Simon:

If they are encrypting the XML data directly with the RSA key (which is 
very unlikely), then they are correct.

The traditional way to handle this is to generate a random 
content-encryption key (CEK) and then encrypt the XML data with a symmetric 
algorithm using the CEK.  The CEK is encrypted with the RSA key from the 
certificate.  Thus, the RSA key is really being used to encrypt only 
symmetric keys.

Russ

  At 08:33 PM 5/10/2005, Simon McMahon wrote:

>Hi,
>
>I have had a recent interoperability issue with a application vendor that 
>didn't like the key-usage attributes in a cert from a CA vendor's 
>certificate. Signing certs work fine, it was an encryption cert that failed.
>
>CA sets key-usage = "key encipherment".
>Application wants to encrypt some XML data so looks for key-usage = "data 
>encipherment". Reason - because XML is data, not a key.
>
>I believe the application vendor is wrong and I explained that the RSA key 
>actually encrypts an AES key so it doesn't directly encrypt the data but 
>they want an official "pkix" ruling based on the standard so can someone 
>please refer me to a statement in the standard that clears this up.
>
>Thanks,
>
>Simon McMahon.
>
>
>
>Simon McMahon
>
>Work: (07) 31311420
>Mobile: (043) 2294180
>
>
>
>Simon McMahon
>
>Work: (07) 31311420
>Mobile: (043) 2294180
>
>
>
>
>***********************************************************************************
>This email, including any attachments sent with it, is confidential and 
>for the sole use of the intended recipient(s).  This confidentiality is 
>not waived or lost, if you receive it and you are not the intended 
>recipient(s), or if it is transmitted/received in error.
>
>Any unauthorised use, alteration, disclosure, distribution or review of 
>this email is prohibited.  It may be subject to a statutory duty of 
>confidentiality if it relates to health service matters.
>
>If you are not the intended recipient(s), or if you have received this 
>email in error, you are asked to immediately notify the sender by 
>telephone or by return email.  You should also delete this email and 
>destroy any hard copies produced.
>***********************************************************************************

From: "Kazin, Joel" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Date: Wed, 11 May 2005 05:49:43 -0500
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.

------_=_NextPart_001_01C55616.EE7E8D2C
Content-Type: text/plain;
	charset="iso-8859-1"

Peters rewording makes it clearer.

At 12:34 AM 5/11/2005 -0500, [email-masked] wrote:

Andrew Sciberras <[email-masked]> writes: 

>     The keyEncipherment bit is asserted when the subject public key is 
>      used for key transport.  For example, when an RSA key is to be 
>      used for key management, then this bit shall asserted. 
> 
>      The dataEncipherment bit is asserted when the subject public key 
>      is used for enciphering user data, other than cryptographic keys. 

Quoting that won't help (I've seen this sort of thing before) because as far

as the user is concerned what's being encrypted is data, so the valid bit to

use is dataEncipherment (quite logical to them).  What might help is to make

this more explicit in the text: 

  The dataEncipherment bit is asserted when the subject public key is used
for 
  directly enciphering raw user data without the use of an intermediate 
  symmetric cipher.  This bit MUST NOT be set when the intention is to 
  encipher intermediate cryptographic keys rather than raw user data. 

Peter. 

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com <http://www.atosorigin.com/> 

------_=_NextPart_001_01C55616.EE7E8D2C
Content-Type: text/html;
	charset="iso-8859-1"

<html>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
Peters rewording makes it clearer.<br><br>
At 12:34 AM 5/11/2005 -0500, [email-masked] wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>Andrew Sciberras
&lt;[email-masked]&gt; writes:</font> <br><br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The keyEncipherment bit is
asserted when the subject public key is</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for key
transport.&nbsp; For example, when an RSA key is to be</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; used for key management,
then this bit shall asserted.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The dataEncipherment bit
is asserted when the subject public key</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is used for enciphering
user data, other than cryptographic keys.</font> <br><br>
<font size=2>Quoting that won't help (I've seen this sort of thing
before) because as far</font> <br>
<font size=2>as the user is concerned what's being encrypted is data, so
the valid bit to</font> <br>
<font size=2>use is dataEncipherment (quite logical to them).&nbsp; What
might help is to make</font> <br>
<font size=2>this more explicit in the text:</font> <br><br>
<font size=2>&nbsp; The dataEncipherment bit is asserted when the subject
public key is used for</font> <br>
<font size=2>&nbsp; directly enciphering raw user data without the use of
an intermediate</font> <br>
<font size=2>&nbsp; symmetric cipher.&nbsp; This bit MUST NOT be set when
the intention is to</font> <br>
<font size=2>&nbsp; encipher intermediate cryptographic keys rather than
raw user data.</font> <br><br>
<font size=2>Peter.</font> </blockquote>
<x-sigsep><p></x-sigsep>
<br>
Joel S. Kazin CPA, CISA, CISSP, CISM<br>
Senior Consultant<br>
Atos Origin<br>
40 Old Sleepy Hollow Road<br>
Pleasantville, New York 10570-3802<br>
USA<br>
Phone&nbsp; +1 914-769-8780<br>
Mobile&nbsp; +1 914-564-1484<br>
email<x-tab>&nbsp;&nbsp;&nbsp;</x-tab> [email-masked]<br>
<a href="http://www.atosorigin.com/" eudora="autourl">www.atosorigin.com<br>
</a></html>

------_=_NextPart_001_01C55616.EE7E8D2C--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Cc: [email-masked]
Date: Wed, 11 May 2005 21:39:04 +1200
Sender: [email-masked]

"Wen-Cheng Wang" <[email-masked]> writes:

>It is better to clarify that it is legitimate to assert both the
>keyEncipherment bit and the dataEncipherment bit in one certificate. In that
>case, it means that the key (e.g., RSA key) may be used for enciphering
>intermediate cryptographic keys or directly enciphering raw user data (e.g.,
>user password).

Saying you can use both bits won't help, it still leaves it ambiguous to users
as to what dataEncipherment should be used for.  One interpretation I've heard
of is keyEncipherment = exchange of session keys (SSL), dataEncipherment =
data encryption (S/MIME).

Peter.

Date: Wed, 11 May 2005 19:32:14 +1000
From: Andrew Sciberras <[email-masked]>
Organization: eB2Bcom
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Gutmann wrote:
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">Andrew Sciberras <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> writes:

  </pre>
  <blockquote type="cite">
    <pre wrap="">    The keyEncipherment bit is asserted when the subject public key is
     used for key transport.  For example, when an RSA key is to be
     used for key management, then this bit shall asserted.

     The dataEncipherment bit is asserted when the subject public key
     is used for enciphering user data, other than cryptographic keys.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Quoting that won't help (I've seen this sort of thing before) because as far
as the user is concerned what's being encrypted is data, so the valid bit to
use is dataEncipherment (quite logical to them).  What might help is to make
this more explicit in the text:

  The dataEncipherment bit is asserted when the subject public key is used for
  directly enciphering raw user data without the use of an intermediate
  symmetric cipher.  This bit MUST NOT be set when the intention is to
  encipher intermediate cryptographic keys rather than raw user data.

  </pre>
</blockquote>
Yeah, I see your point Peter.<br>
Simon seems to know what he's talking about and made the point that the
key is actually encrypting an AES key, he then wanted a standards based
opinion.<br>
I think RFC 2459 clearly states what each of the key usage bits are to
be used for. <br>
<br>
I don't think that the user's interpretation of what's being encrypted
is significant at all. Its more about the developers who are writing
decision making code understanding the various usages. At that point
the developer should be very aware of how the key associated with the
certificate is being used and therefore 2459's description should
suffice.<br>
<br>
<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">Peter.</pre>
</blockquote>
Andrew Sciberras.<br>
</body>
</html>

From: "Wen-Cheng Wang" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: key usage - key encipherment or data encipherment
Date: Wed, 11 May 2005 15:47:29 +0800
Organization: Chunghwa Telecom
Sender: [email-masked]

Peter Gutmann <[email-masked]> wrote:
> 
> Andrew Sciberras <[email-masked]> writes:
> 
>>     The keyEncipherment bit is asserted when the subject public key is
>>      used for key transport.  For example, when an RSA key is to be
>>      used for key management, then this bit shall asserted.
>>
>>      The dataEncipherment bit is asserted when the subject public key
>>      is used for enciphering user data, other than cryptographic keys.
> 
> Quoting that won't help (I've seen this sort of thing before) because as far
> as the user is concerned what's being encrypted is data, so the valid bit to
> use is dataEncipherment (quite logical to them).  What might help is to make
> this more explicit in the text:
> 
>  The dataEncipherment bit is asserted when the subject public key is used for
>  directly enciphering raw user data without the use of an intermediate
>  symmetric cipher.  This bit MUST NOT be set when the intention is to
>  encipher intermediate cryptographic keys rather than raw user data.
> 
It is better to clarify that it is legitimate to assert both the keyEncipherment bit
and the dataEncipherment bit in one certificate. In that case, it means that the
key (e.g., RSA key) may be used for enciphering intermediate cryptographic
keys or directly enciphering raw user data (e.g., user password).

Wen-Cheng Wang

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Cc: [email-masked]
Date: Wed, 11 May 2005 17:41:46 +1200
Sender: [email-masked]

[email-masked] writes:

>This is a recurring problem with applications.  

If this is a recurring problem then it's a strong indicator that the wording
of the spec needs to be changed to address it.

>If your vendor is cooperative, that will make your choice easier.

They almost never are.  The standard flow for this sort of thing is:

  1. Vendor does something silly.

  2. Vendor uses ambiguous wording of spec to justify their silliness
     because they don't want to fix their code.

  3. User has the option of breaking their code to match the vendor 
     silliness, or going somewhere else (learning to flip burgers, for
     example).

Peter (who just last week went through an argument with a vendor who claimed
       that some open-ended wording in the X.509v3 spec (before sundry
       corrections and bugfixes are applied, and not counting X.509v4 updates
       or any bugfixes to that) allowed them to do something silly, and they 
       weren't going to change their code, and anyone who didn't like it could
       bugger off).

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Cc: [email-masked]
Date: Wed, 11 May 2005 17:34:28 +1200
Sender: [email-masked]

Andrew Sciberras <[email-masked]> writes:

>     The keyEncipherment bit is asserted when the subject public key is
>      used for key transport.  For example, when an RSA key is to be
>      used for key management, then this bit shall asserted.
>
>      The dataEncipherment bit is asserted when the subject public key
>      is used for enciphering user data, other than cryptographic keys.

Quoting that won't help (I've seen this sort of thing before) because as far
as the user is concerned what's being encrypted is data, so the valid bit to
use is dataEncipherment (quite logical to them).  What might help is to make
this more explicit in the text:

  The dataEncipherment bit is asserted when the subject public key is used for
  directly enciphering raw user data without the use of an intermediate
  symmetric cipher.  This bit MUST NOT be set when the intention is to
  encipher intermediate cryptographic keys rather than raw user data.

Peter.

Date: Tue, 10 May 2005 23:05:46 -0400
From: [email-masked]
To: Simon McMahon <[email-masked]>
Cc: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

Simon,

Your interpretation matches the PKIX interpretation.  Since the RSA key is 
used to encrypt the AES key, it is key encipherment not data encipherment.  
The AES key enciphers the data.

This is a recurring problem with applications.  In general, policies used by 
most PKIs (including the U.S. government) forbid setting the data encipherment 
bit.  There are a number of security problems taht can arise if an application 
actuially uses the RSA key to encipher the datat directly.  It is almost 
always a better choice to encrypt data under a good symmetric algorithm and 
encipher the key using the RSA algorithm.  Unfortunatley, a number of 
applications have been implemnnted using your vendor's interpretations.

This presents you with an uncomfortable choice - set data encipherment to 
enable your apps, but open a security vulnerability, or make the security 
purist choice and break your app.  If your vendor is cooperative, that will 
make your choice easier.

Tim Polk

Quoting Simon McMahon <[email-masked]>:

> 
> Hi,
>  
> I have had a recent interoperability issue with a application vendor that
> didn't like the key-usage attributes in a cert from a CA vendor's
> certificate. Signing certs work fine, it was an encryption cert that failed.
>  
> CA sets key-usage = "key encipherment".
> Application wants to encrypt some XML data so looks for key-usage = "data
> encipherment". Reason - because XML is data, not a key.
> 
> I believe the application vendor is wrong and I explained that the RSA key
> actually encrypts an AES key so it doesn't directly encrypt the data but they
> want an official "pkix" ruling based on the standard so can someone please
> refer me to a statement in the standard that clears this up.
>  
> Thanks,
>  
> Simon McMahon.
>  
>  
> 
> Simon McMahon
>  
> Work: (07) 31311420
> Mobile: (043) 2294180
> 
> 
> 
> Simon McMahon
> 
> Work: (07) 31311420
> Mobile: (043) 2294180
> 
> 
> 
> 
> 
*******************************************************************************
****
> This email, including any attachments sent with it, is confidential and for
> the sole use of the intended recipient(s).  This confidentiality is not
> waived or lost, if you receive it and you are not the intended recipient(s),
> or if it is transmitted/received in error.
> 
> Any unauthorised use, alteration, disclosure, distribution or review of this
> email is prohibited.  It may be subject to a statutory duty of
> confidentiality if it relates to health service matters.
> 
> If you are not the intended recipient(s), or if you have received this email
> in error, you are asked to immediately notify the sender by telephone or by
> return email.  You should also delete this email and destroy any hard copies
> produced.
> 
*******************************************************************************
****

Date: Wed, 11 May 2005 11:53:28 +1000
From: Andrew Sciberras <[email-masked]>
Organization: eB2Bcom
To: Simon McMahon <[email-masked]>
CC: [email-masked]
Subject: Re: key usage - key encipherment or data encipherment
Sender: [email-masked]

Hi,

 From RFC2459:

>     The keyEncipherment bit is asserted when the subject public key is
>      used for key transport.  For example, when an RSA key is to be
>      used for key management, then this bit shall asserted.
>
>      The dataEncipherment bit is asserted when the subject public key
>      is used for enciphering user data, other than cryptographic keys.
>

Andrew Sciberras
eB2Bcom Australia.

Simon McMahon wrote:

>Hi,
> 
>I have had a recent interoperability issue with a application vendor that didn't like the key-usage attributes in a cert from a CA vendor's certificate. Signing certs work fine, it was an encryption cert that failed.
> 
>CA sets key-usage = "key encipherment".
>Application wants to encrypt some XML data so looks for key-usage = "data encipherment". Reason - because XML is data, not a key.
>
>I believe the application vendor is wrong and I explained that the RSA key actually encrypts an AES key so it doesn't directly encrypt the data but they want an official "pkix" ruling based on the standard so can someone please refer me to a statement in the standard that clears this up.
> 
>Thanks,
> 
>Simon McMahon.
> 
> 
>
>Simon McMahon
> 
>Work: (07) 31311420
>Mobile: (043) 2294180
>
>
>
>Simon McMahon
>
>Work: (07) 31311420
>Mobile: (043) 2294180
>
>
>
>
>***********************************************************************************
>This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.
>
>Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.
>
>If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
>***********************************************************************************
>
>
>
>
>  
>

Date: Wed, 11 May 2005 10:33:58 +1000
From: "Simon McMahon" <[email-masked]>
To: <[email-masked]>
Subject: key usage - key encipherment or data encipherment
Sender: [email-masked]

Hi,
 
I have had a recent interoperability issue with a application vendor that didn't like the key-usage attributes in a cert from a CA vendor's certificate. Signing certs work fine, it was an encryption cert that failed.
 
CA sets key-usage = "key encipherment".
Application wants to encrypt some XML data so looks for key-usage = "data encipherment". Reason - because XML is data, not a key.

I believe the application vendor is wrong and I explained that the RSA key actually encrypts an AES key so it doesn't directly encrypt the data but they want an official "pkix" ruling based on the standard so can someone please refer me to a statement in the standard that clears this up.
 
Thanks,
 
Simon McMahon.

Simon McMahon
 
Work: (07) 31311420
Mobile: (043) 2294180

Simon McMahon

Work: (07) 31311420
Mobile: (043) 2294180

***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************

Date: Tue, 10 May 2005 17:27:21 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: WG Last Call: AIA CRL extension
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

This message initiates working group Last Call for the specification 
"Internet X.509 Public Key Infrastructure: Authority Information Access CRL 
Extension".  While some issues raised in the working group are unresolved, 
the editors believe that rough consensus supports the current specification.

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

Last Call will run for (at least) two weeks. That is, Last Call will not 
close before May 24.

Thanks,

Tim Polk 

Date: Tue, 10 May 2005 15:26:38 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Cc: [email-masked]
Sender: [email-masked]

Denis:

>>Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated.
>>You say that it is not clear what validation policy needs to be used, but 
>>this is completely irrelevant to the discussion of the CRL AIA 
>>extension.  This extension aid in certification path construction, not 
>>the validation of the path once it is constructed.
>
>Not exactly, it could "help" finding a wrong path !

Not likely.  The signer of the CRL is providing a pointer to their own 
certificate.  Path construction to locate a parent of that certificate 
through a complex PKI might include paths that are acceptable and paths 
that are unacceptable, but the certificate that contains the public key 
needed to validate the signature on the CRL is clearly needed.

>>There are many factors which need to be considered in the validation of 
>>the CRL issue certificate.  The values of the key usage extension and the 
>>certificate policies extension are two that jump to mind.  There are 
>>probably more if I spend the time to consider each possible scenario.
>
>One simple rule would allow no security problem at all and I wonder why 
>you have so much resistance to mention it.

We have that rule:  The CA certificate and the CRL Issuer certificate must 
validate back to the same trust anchor.

>>In my opinion, this document is ready for WG Last Call.
>
>As an editor of the draft, I may understand your position; but it is up 
>the the PKIX chairs to decide whether or not the document is ready for WG 
>last call.

Correct.  I included this sentence for the WG chairs.  I hope they will 
agree with me, and that they will issue WG Last Call for this document.

>Once again the current Security Considerations section is not acceptable.

To you...  No one else is advocating this change.  I continue to believe 
that requiring the CA certificate and the CRL Issuer certificate to 
validate back to the same trust anchor resolves your concern.  I am willing 
to add a few words to the security considerations about name collisions (my 
co-author may disagree), but I am not willing to use "MUST" or "SHOULD" in 
those words.  There is absolutely nothing that a client can do to determine 
deal with name collisions that are subordinate to the same trust anchor.

Russ

Date: Tue, 10 May 2005 14:57:33 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Cc: pkix <[email-masked]>
Sender: [email-masked]

The document already says that the CA and the CRL issuer need to terminate 
at the same trust anchor.  This is the important point.  I disagree that 
there is anything else that ought to be said in the security considerations.

Russ

At 02:59 AM 5/10/2005, Denis Pinkas wrote:
>Russ,
>
>Your statement below is correct, but does not answer to any of my 
>questions/issues. In particular, the last one. I am still awaiting your 
>responses.
>
>Denis
>
>>Denis:
>>RFC 3280 does not tell an implementor how for locate certificates for any 
>>certification path construction.  There are several extensions that 
>>provide pointers that may help an implementation, but other approaches to 
>>obtaining the same certificates are always permitted.  I would fully 
>>expect an implementation to check any local cache before accessing a 
>>repository.
>>The CRL AIA extension fits this pattern.  A method for locating a 
>>certificate is provided, but any other mechanism for locating the same 
>>certificate is acceptable.
>>Russ
>>
>>>Stefan,
>>>
>>>I made the e-mail shorter. Your main arguments are the following:
>>>
>>>==========================================================================
>>>
>>>[Stefan] But it has to provide a warning to something that is introduced
>>>by the standard. This standard does not introduce the concept of CRL
>>>signature checking or CRL issuer certificate validation, so that is
>>>clearly out of scope. More about that below;
>>>
>>>[Denis] See below the last answer and also my arguments in the 
>>>soon-to-be-posted answer to Russ.
>>>
>>>==========================================================================
>>>
>>>
>>> > > RFC 3280 [PKIX1] specifies the validation of certification paths.
>>> > > One aspect involves the determination that a certificate has not been
>>> > > revoked, and one revocation checking mechanism is the Certificate
>>> > > Revocation List (CRL).  CRL validation is also specified in RFC 3280,
>>>
>>> > I would love this last sentence to be true but the reality is that:
>>> > "CRL validation is NOT specified in RFC 3280". :-(
>>>
>>>[Stefan] In fact it is.
>>>
>>>RFC 3280, Section 6.3.3 CRL processing - on page 85:
>>>
>>>    (f)  Obtain and validate the certification path for the complete CRL
>>>    issuer.  If a key usage extension is present in the CRL issuer's
>>>    certificate, verify that the cRLSign bit is set.
>>>
>>>    (g)  Validate the signature on the complete CRL using the public key
>>>    validated in step (f).
>>>
>>>[Denis] The text does not say how to obtain and validate the 
>>>certification path for the complete (???) CRL issuer. The text is not 
>>>clear enough so that two implementors only looking at this sentence will 
>>>provide interoperable implementations.
>>>
>>>==========================================================================
>>>
>>>[Stefan] It is my hope that the provided responses here can help
>>>convince you to change your mind about that. If it doesn't I still argue
>>>that the place to specify requirements and security considerations for
>>>CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft.
>>>
>>>[Denis] I can agree with your last sentence, ... which means that it 
>>>should not be in the main body of the document. In the security 
>>>considerations section, text is free and we shall at the very minimum 
>>>warn implementers and we should provide some guidance. When the same 
>>>certification path (i.e. the path used to validate the target 
>>>certificate) is used, then there is no security issue: this should be 
>>>said. For all other cases, there MAY be problems: this should also be 
>>>said. It is as simple as that.
>>>
>>>Denis
>
>

Content-class: urn:content-classes:message
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Tue, 10 May 2005 07:49:03 -0700
From: "David Cross" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Denis:

I have to disagree on removal of the text. I have not seen any
objections from the list or working group to this inclusion.  I have to
disagree with your assertion that removing the text is a more secure
recommendation.  The below text (slightly edited to my taste) is an
excellent recommendation from an implementation standoint and a security
consideration.  I would personally concede that using MUST *may* be
incorrect here and a SHOULD *may* be more appropriate.

      As a means of mitigating implementation challenges and security
issues 
	related to issuer name collisions, CA names SHOULD be formed in
such a
	way that reduce the likelihood of name collisions.
Implementations
	validating CRLs SHOULD ensure that the certification path of the
target
	certificate and the CRL issuer certification path used to
validate the target
      certificate, terminate at a common trust anchor.  

David B. Cross 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Tuesday, May 10, 2005 12:01 AM
To: Russ Housley
Cc: [email-masked]
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>

Russ,

> Denis:
> 
> Yes, it is OBVIOUS that the CRL issuer certificate needs to be
validated.
> 
> You say that it is not clear what validation policy needs to be used, 
> but this is completely irrelevant to the discussion of the CRL AIA 
> extension.  This extension aid in certification path construction, not

> the validation of the path once it is constructed.

Not exactly, it could "help" finding a wrong path !

> There are many factors which need to be considered in the validation 
> of the CRL issue certificate.  The values of the key usage extension 
> and the certificate policies extension are two that jump to mind.  
> There are probably more if I spend the time to consider each possible
scenario.

One simple rule would allow no security problem at all and I wonder why
you have so much resistance to mention it.

> In my opinion, this document is ready for WG Last Call.

As an editor of the draft, I may understand your position; but it is up
the the PKIX chairs to decide whether or not the document is ready for
WG last call.

Once again the current Security Considerations section is not
acceptable.
In particular it contains a "MUST" statement that cannot be placed in
such a section and which is in addition fully wrong.

Hereabove is the last one from draft 01:

3  Security Considerations

      Implementers should take into account the possible existence of
      multiple unrelated CAs and CRL issuers with the same name.  As
      means of reducing problems and security issues related to issuer
      name collisions, CA names SHOULD be formed in a way that reduce
the
      likelihood of name collisions.  Implementations validating CRLs
      MUST ensure that the certification path of the target certificate
      and the CRL issuer certification path used to validate the target
      certificate, terminate at the same trust anchor.

      Implementers should be aware of risks involved if the Authority
      Information Access extensions of corrupted CRLs contain links to
      malicious code.  Implementers should always take the steps of
      validating the retrieved data to ensure that the data is properly
      formed.

Hereafter is a "minimalist" rewriting of this section, if we take the
choice to mention the issue, but not to provide any secure solution
(mentioning insecure or insufficient solutions is not appropriate). Two
sentences have thus been deleted.

3  Security Considerations

      Implementers should take into account the possible existence of
      multiple unrelated CAs and CRL issuers with the same name.

      Implementers should be aware of risks involved if the Authority
      Information Access extensions of corrupted CRLs contain links to
      malicious code.  Implementers should always take the steps of
      validating the retrieved data to ensure that the data is properly
      formed.

Denis

> Russ
> 
> 
> At 09:07 AM 5/9/2005, Denis Pinkas wrote:
> 
>> Russ,
>>
>> > Here is a quote from RFC 3280.  To me, it is clear that a CRL 
>> > issuer
>> has
>> > a certificate.
>>
>> True, a CRL issuer (that is different from the CA that has issued the

>> target
>> certificate) has a certificate. So we both strongly agree on this 
>> this. :-)
>>
>> > Obviously, all certificates need to be validated, which includes 
>> > certification path construction and certification path
>> validation.
>>
>> When a sentence starts with "Obviously", it means that it is not so 
>> obvious.
>> :-|
>>
>> The real question is whether the CRL issuer certificate has to be 
>> verified using rules (i.e. a validation policy) which are independent

>> from the certification path construction of the target certificate. 
>> RFC 3280 does not provide a crystal clear answer to that question.
>>
>> If the rules are different, then you MAY end up with a security issue

>> (see my previous explanations). The current "recommendations" that 
>> are in the security considerations section do NOT solve this issue in

>> the general case.
>>
>> If the rules are the same, i.e. the path used to validate the 
>> certification path from the certificate are also used, then there is 
>> no security issue.
>>
>> I do not think it would be good to hide this issue in the proposed
draft.
>> Anyway, the current "recommendations" do NOT solve the issue and are 
>> thus not acceptable and so this section cannot stand as it is.
>>
>> Denis
>>
>> > 5.1.1.3  signatureValue
>> >
>> >    The signatureValue field contains a digital signature computed
upon
>> >    the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded
>> tbsCertList
>> >    is used as the input to the signature function.  This signature
>> value
>> >    is encoded as a BIT STRING and included in the CRL
signatureValue
>> >    field.  The details of this process are specified for each of
the
>> >    supported algorithms in [PKIXALGS].
>> >
>> >    CAs that are also CRL issuers MAY use one private key to
digitally
>> >    sign certificates and CRLs, or MAY use separate private keys to
>> >    digitally sign certificates and CRLs.  When separate private 
>> > keys
>> are
>> >    employed, each of the public keys associated with these private
keys
>> >    is placed in a separate certificate, one with the keyCertSign 
>> > bit
>> set
>> >    in the key usage extension, and one with the cRLSign bit set in
the
>> >    key usage extension (section 4.2.1.3).  When separate private
keys
>> >    are employed, certificates issued by the CA contain one 
>> > authority
>> key
>> >    identifier, and the corresponding CRLs contain a different
authority
>> >    key identifier.  The use of separate CA certificates for
validation
>> >    of certificate signatures and CRL signatures can offer improved
>> >    security characteristics; however, it imposes a burden on
>> >    applications, and it might limit interoperability.  Many
>> applications
>> >    construct a certification path, and then validate the
certification
>> >    path (section 6).  CRL checking in turn requires a separate
>> >    certification path to be constructed and validated for the CA's
CRL
>> >    signature validation certificate.  Applications that perform CRL
>> >    checking MUST support certification path validation when
>> certificates
>> >    and CRLs are digitally signed with the same CA private key.
These
>> >    applications SHOULD support certification path validation when
>> >    certificates and CRLs are digitally signed with different CA
private
>> >    keys.
>> >
>> > Russ
>> >
>> > At 01:12 PM 4/28/2005, Denis Pinkas wrote:
>> >
>> >> Stefan and Russ,
>> >>
>> >>> Denis,
>> >>
>> >>
>> >>> Russ and I have taken a thorough look at your text proposal and 
>> >>> we
>> have
>> >>> edited a counter proposal where we try to meet your needs as much

>> >>> as possible without compromising what we think is the core 
>> >>> purpose of
>> the
>> >>> draft (to enable certificate discovery bottom-up).
>> >>
>> >>
>> >>> The conclusion is that we suggest changes to the introduction 
>> >>> section but we keep the old security considerations intact.
>> >>
>> >>
>> >> I would suggest that a merge would need to be done between the
"old"
>> >> security considerations section and the "new" one.
>> >>
>> >> The "old" security considerations section is mentionning a 
>> >> solution which does NOT suppress the problem, but minimize the 
>> >> risk only in case the CAs are really "honest".
>> >>
>> >> The old" security considerations section does not provide a 
>> >> solution in case the name collsion between two CRL issuer name is 
>> >> deliberate, whereas the "new" security considerations section 
>> >> provides a secure solution in one case and clearly mentions that 
>> >> all other cases are dependant about "zillions" of *local* trust 
>> >> conditions which cannot all be standardized.
>> >>
>> >> The main purpose of a security considerations section is to 
>> >> provide the adequate warnings and solutions when they exist and 
>> >> not to hide the problems.
>> >>
>> >>> That is not because
>> >>> we necessarily disagree with all of the statements in your
>> proposal, but
>> >>> in the cases we don't, we still think it is out of scope for this
>> work.
>> >>
>> >>
>> >> This is clearly within the scope of a security considerations
section.
>> >>
>> >>> The new introduction proposal based on your input is:
>> >>> --------------------------------------------------------------
>> >>> RFC 3280 [PKIX1] specifies the validation of certification paths.

>> One
>> >>> aspect involves the determination that a certificate has not been

>> >>> revoked, and one revocation checking mechanism is the Certificate

>> >>> Revocation List (CRL).  CRL validation is also specified in RFC 
>> >>> 3280,
>> >>
>> >>
>> >> I would love this last sentence to be true but the reality is
that:
>> >> "CRL validation is NOT specified in RFC 3280". :-(
>> >>
>> >>> which involves the constructions of a valid certification path 
>> >>> for
>> the
>> >>> CRL issuer.
>> >>
>> >>
>> >> There is no such a statement in RFC 3280.
>> >>
>> >>> Building a CRL issuer certification path from the signer of
>> >>
>> >>
>> >> There is no notion of "CRL issuer certification path" in RFC 3280.
>> >> The primary requirement is to make sure that the CRL issuer 
>> >> designated by the CA is indeed the right one. In some (but not 
>> >> all) cases, I mean among the zillion of cases, there MAY be a need

>> >> to construct a CRL issuer certification path.
>> >>
>> >>> the CRL to a trust anchor is straightforward when the certificate
>> of the
>> >>> CRL issuer is present in the certification path associated with 
>> >>> the target certificate, but it can be complex in other
situations.
>> >>
>> >>
>> >> From the comments above, you can see that I cannot agree with the 
>> >> above revised text. The remaining of the text is acceptable in 
>> >> general, but could possibly be slightly revised to be more in 
>> >> continuation with the changes there are needed above (i.e. it is 
>> >> not cast in concrete).
>> >>
>> >> Denis
>> >>
>> >>> There are several legitimate scenarios where the certificate of
>> the CRL
>> >>> issuer is not present, or easily discovered, from the target 
>> >>> certification path.  This can be the case when indirect CRLs are
>> used,
>> >>> when the certification Authority (CA) that issued the target
>> certificate
>> >>> changes its certificate signing key, or when the CA employs 
>> >>> separate keys for certificate signing and CRL signing.
>> >>> Methods of finding the certificate of the CRL issuer are 
>> >>> currently available, such as though an accessible directory 
>> >>> location or through use of the Subject Information Access 
>> >>> extension in intermediary CA certificates.
>> >>> Directory lookup requires existence and access to a directory 
>> >>> that
>> has
>> >>> been populated with all of the necessary certificates.  The 
>> >>> Subject Information Access extension, which supports building the

>> >>> CRL issuer certification path top-down (in the direction from the

>> >>> trust
>> anchor to
>> >>> the CRL issuer), requires that some certificates in the CRL 
>> >>> issuer certification path includes an appropriate Subject 
>> >>> Information Access extension.
>> >>> RFC 3280 [PKIX1] provides for bottom-up discovery of 
>> >>> certification
>> paths
>> >>> through the Authority Information Access extension, where the 
>> >>> id-ad-caIssuers access method may specify one or more 
>> >>> accessLocation fields that reference CA certificates associated 
>> >>> with the certificate containing this extension.
>> >>> This document enables the use of the Authority Information Access

>> >>> extension in CRLs, enabling a CRL checking application to use the
>> access
>> >>> method (id-ad-caIssuers) to locate certificates that may be 
>> >>> useful in the construction of a valid CRL issuer certification 
>> >>> path to an appropriate trust anchor.
>> >>>
>> >>> Stefan Santesson
>> >>> Program Manager, Standards Liaison Windows Security
>> >>>
>> >>>
>> >>>> From: Denis Pinkas [mailto:[email-masked]]
>> >>>> Sent: den 18 april 2005 13:41
>> >>>> To: Stefan Santesson
>> >>>> Cc: Russ Housley; pkix
>> >>>> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
>> >>>>
>> >>>> Stefan,
>> >>>>
>> >>>>
>> >>>>> Denis,
>> >>>>
>> >>>>
>> >>>>> I will come back and comment on your text proposals, but before
>> >>>>
>> >>> that,
>> >>>
>> >>>> > a few questions/comments:
>> >>>>
>> >>>>
>> >>>>> <snip>
>> >>>>
>> >>>>
>> >>>>>>> You point out some well known issues related to the lack of
>> >>>>>>
>> >>> absolute
>> >>>
>> >>>>>>> cryptographic binding between CRL and certificates where the
>> >>>>>>> certificate and CRL is not signed by the same key.
>> >>>>>>
>> >>>>>>
>> >>>>>> Not really. It is indeed possible to have an absolute 
>> cryptographic
>> >>>>>> binding between CRL and certificates where the certificate and
CRL
>> >>>>>
>> >>> is
>> >>>
>> >>>> not
>> >>>>
>> >>>>>> signed by the same key, but the key point is that proposed
>> >>>>>
>> >>> extension
>> >>>
>> >>>> >> is *not* the means to provide such a binding (and you agree
with
>> >>>
>> >>> this
>> >>>
>> >>>> >> further down in this e-mail).
>> >>>>
>> >>>>
>> >>>>> We agree that this extension does not add to the concept of
>> >>>>> cryptographic binding. But how do you mean it can be done?
>> >>>>
>> >>>>
>> >>>> Would this mean that you believed this could not be done ? :-)
>> >>>>
>> >>>> I already provided the information, but since at that time you
were
>> >>>> focussing on another issue, you probably missed the point.
>> >>>>
>> >>>> I would encourage you to read again that thread, but I will 
>> provide a
>> >>>> short
>> >>>> reply here to your question.
>> >>>>
>> >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer
contains
>> >>>
>> >>> the
>> >>>
>> >>>> DN
>> >>>> of the CRL Issuer and we all know that CAs are free to assign
the 
>> DNs
>> >>>
>> >>> they
>> >>>
>> >>>> wish. The next point is for a verifier to make sure that the DN 
>> which
>> >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that
was
>> >>>
>> >>> meant
>> >>>
>> >>>> by the CA. The CRL must be issued by a CRL Issuer that has the
same
>> >>>
>> >>> DN.
>> >>>
>> >>>> The
>> >>>> CRL Issuer will have a certificate issued by a CA.
>> >>>>
>> >>>> Case a): the CA that has issued that certificate is the same as 
>> the CA
>> >>>> that
>> >>>> has issued the target certificate (which contains the hereabove
>> >>>
>> >>> mentionned
>> >>>
>> >>>> CRL DP). This is easy to check for a verifier since the verifier

>> must
>> >>>> first
>> >>>> build the certification path and then test the revocation status
of
>> >>>
>> >>> every
>> >>>
>> >>>> element of the path. So the verifier knows the validated
sequence of
>> >>>
>> >>> DNs
>> >>>
>> >>>> starting from a self-signed certificate. It must then use the
same
>> >>>> sequence
>> >>>> of DNs to validate the CRL Issuer certificate.
>> >>>>
>> >>>> This is a general rule which does not require any extra local
trust
>> >>>> information.
>> >>>>
>> >>>> Case b) : the CA that has issued that certificate is NOT the
same as
>> >>>
>> >>> the
>> >>>
>> >>>> CA
>> >>>> that has issued the target certificate. This case requires extra
>> >>>
>> >>> *0local*
>> >>>
>> >>>> trust information. There are many such trust conditions possible
and
>> >>>
>> >>> thus
>> >>>
>> >>>> this cannot be defined in general. Cases a) and b) are thus not
>> >>>
>> >>> equivalent
>> >>>
>> >>>> and have to be distinguished.
>> >>>>
>> >>>>
>> >>>>> <snip>
>> >>>>
>> >>>>
>> >>>>>>> This draft only introduces a new way to locate certificates
>> >>>>>>> that can be helpful in building this path.
>> >>>>>>
>> >>>>>>
>> >>>>>> At least one sentence of which we both agree !
>> >>>>>> It should be copied and pasted in the abstract.
>> >>>>>
>> >>>>>
>> >>>>> Good, then I suggest that we leave unrelated topics out of this
>> >>>>
>> >>> draft
>> >>>
>> >>>>> and focus on the issues that are related to this limited scope.
>> >>>>
>> >>>>
>> >>>> This is what I did in my proposal, except that we need to have a
>> >>>
>> >>> security
>> >>>
>> >>>> considerations section and the goal of that section is not to
hide
>> >>>> problems
>> >>>> but to correctly warn users. Thus why an informatiove annex on
the
>> >>>
>> >>> topics
>> >>>
>> >>>> mentionned in the security considerations section would be quite
>> >>>
>> >>> useful.
>> >>>
>> >>>> In fact, its content would be along the lines of the
explanations
>> >>>
>> >>> which
>> >>>
>> >>>> are
>> >>>> just above.
>> >>>>
>> >>>> I hope this e-mail will help us to progress.
>> >>>>
>> >>>> Denis
>> >>>>
>> >>>>
>> >>>>> Stefan Santesson
>> >>>>> Program Manager - Standards Liaison
>> >>>>> Windows Security
>> >>>>
>> >>
>> >>
>> >
>> >
>>
>>
>>
> 
> 

Date: Tue, 10 May 2005 09:00:55 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Russ,

> Denis:
> 
> Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated.
> 
> You say that it is not clear what validation policy needs to be used, 
> but this is completely irrelevant to the discussion of the CRL AIA 
> extension.  This extension aid in certification path construction, not 
> the validation of the path once it is constructed.

Not exactly, it could "help" finding a wrong path !

> There are many factors which need to be considered in the validation of 
> the CRL issue certificate.  The values of the key usage extension and 
> the certificate policies extension are two that jump to mind.  There are 
> probably more if I spend the time to consider each possible scenario.

One simple rule would allow no security problem at all and I wonder why you 
have so much resistance to mention it.

> In my opinion, this document is ready for WG Last Call.

As an editor of the draft, I may understand your position; but it is up the 
the PKIX chairs to decide whether or not the document is ready for WG last call.

Once again the current Security Considerations section is not acceptable.
In particular it contains a "MUST" statement that cannot be placed in such a 
section and which is in addition fully wrong.

Hereabove is the last one from draft 01:

3  Security Considerations

      Implementers should take into account the possible existence of
      multiple unrelated CAs and CRL issuers with the same name.  As
      means of reducing problems and security issues related to issuer
      name collisions, CA names SHOULD be formed in a way that reduce the
      likelihood of name collisions.  Implementations validating CRLs
      MUST ensure that the certification path of the target certificate
      and the CRL issuer certification path used to validate the target
      certificate, terminate at the same trust anchor.

      Implementers should be aware of risks involved if the Authority
      Information Access extensions of corrupted CRLs contain links to
      malicious code.  Implementers should always take the steps of
      validating the retrieved data to ensure that the data is properly
      formed.

Hereafter is a "minimalist" rewriting of this section, if we take the choice 
to mention the issue, but not to provide any secure solution (mentioning 
insecure or insufficient solutions is not appropriate). Two sentences have 
thus been deleted.

3  Security Considerations

      Implementers should take into account the possible existence of
      multiple unrelated CAs and CRL issuers with the same name.

      Implementers should be aware of risks involved if the Authority
      Information Access extensions of corrupted CRLs contain links to
      malicious code.  Implementers should always take the steps of
      validating the retrieved data to ensure that the data is properly
      formed.

Denis

> Russ
> 
> 
> At 09:07 AM 5/9/2005, Denis Pinkas wrote:
> 
>> Russ,
>>
>> > Here is a quote from RFC 3280.  To me, it is clear that a CRL issuer 
>> has
>> > a certificate.
>>
>> True, a CRL issuer (that is different from the CA that has issued the 
>> target
>> certificate) has a certificate. So we both strongly agree on this 
>> this. :-)
>>
>> > Obviously, all certificates need to be validated, which
>> > includes certification path construction and certification path 
>> validation.
>>
>> When a sentence starts with "Obviously", it means that it is not so 
>> obvious.
>> :-|
>>
>> The real question is whether the CRL issuer certificate has to be 
>> verified
>> using rules (i.e. a validation policy) which are independent from the
>> certification path construction of the target certificate. RFC 3280 
>> does not
>> provide a crystal clear answer to that question.
>>
>> If the rules are different, then you MAY end up with a security issue 
>> (see
>> my previous explanations). The current "recommendations" that are in the
>> security considerations section do NOT solve this issue in the general 
>> case.
>>
>> If the rules are the same, i.e. the path used to validate the 
>> certification
>> path from the certificate are also used, then there is no security issue.
>>
>> I do not think it would be good to hide this issue in the proposed draft.
>> Anyway, the current "recommendations" do NOT solve the issue and are 
>> thus not acceptable and so this section cannot stand as it is.
>>
>> Denis
>>
>> > 5.1.1.3  signatureValue
>> >
>> >    The signatureValue field contains a digital signature computed upon
>> >    the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded 
>> tbsCertList
>> >    is used as the input to the signature function.  This signature 
>> value
>> >    is encoded as a BIT STRING and included in the CRL signatureValue
>> >    field.  The details of this process are specified for each of the
>> >    supported algorithms in [PKIXALGS].
>> >
>> >    CAs that are also CRL issuers MAY use one private key to digitally
>> >    sign certificates and CRLs, or MAY use separate private keys to
>> >    digitally sign certificates and CRLs.  When separate private keys 
>> are
>> >    employed, each of the public keys associated with these private keys
>> >    is placed in a separate certificate, one with the keyCertSign bit 
>> set
>> >    in the key usage extension, and one with the cRLSign bit set in the
>> >    key usage extension (section 4.2.1.3).  When separate private keys
>> >    are employed, certificates issued by the CA contain one authority 
>> key
>> >    identifier, and the corresponding CRLs contain a different authority
>> >    key identifier.  The use of separate CA certificates for validation
>> >    of certificate signatures and CRL signatures can offer improved
>> >    security characteristics; however, it imposes a burden on
>> >    applications, and it might limit interoperability.  Many 
>> applications
>> >    construct a certification path, and then validate the certification
>> >    path (section 6).  CRL checking in turn requires a separate
>> >    certification path to be constructed and validated for the CA's CRL
>> >    signature validation certificate.  Applications that perform CRL
>> >    checking MUST support certification path validation when 
>> certificates
>> >    and CRLs are digitally signed with the same CA private key.  These
>> >    applications SHOULD support certification path validation when
>> >    certificates and CRLs are digitally signed with different CA private
>> >    keys.
>> >
>> > Russ
>> >
>> > At 01:12 PM 4/28/2005, Denis Pinkas wrote:
>> >
>> >> Stefan and Russ,
>> >>
>> >>> Denis,
>> >>
>> >>
>> >>> Russ and I have taken a thorough look at your text proposal and we 
>> have
>> >>> edited a counter proposal where we try to meet your needs as much as
>> >>> possible without compromising what we think is the core purpose of 
>> the
>> >>> draft (to enable certificate discovery bottom-up).
>> >>
>> >>
>> >>> The conclusion is that we suggest changes to the introduction section
>> >>> but we keep the old security considerations intact.
>> >>
>> >>
>> >> I would suggest that a merge would need to be done between the "old"
>> >> security considerations section and the "new" one.
>> >>
>> >> The "old" security considerations section is mentionning a solution
>> >> which does NOT suppress the problem, but minimize the risk only in
>> >> case the CAs are really "honest".
>> >>
>> >> The old" security considerations section does not provide a solution
>> >> in case the name collsion between two CRL issuer name is deliberate,
>> >> whereas the "new" security considerations section provides a secure
>> >> solution in one case and clearly mentions that all other cases are
>> >> dependant about "zillions" of *local* trust conditions which cannot
>> >> all be standardized.
>> >>
>> >> The main purpose of a security considerations section is to provide
>> >> the adequate warnings and solutions when they exist and not to hide
>> >> the problems.
>> >>
>> >>> That is not because
>> >>> we necessarily disagree with all of the statements in your 
>> proposal, but
>> >>> in the cases we don't, we still think it is out of scope for this 
>> work.
>> >>
>> >>
>> >> This is clearly within the scope of a security considerations section.
>> >>
>> >>> The new introduction proposal based on your input is:
>> >>> --------------------------------------------------------------
>> >>> RFC 3280 [PKIX1] specifies the validation of certification paths.  
>> One
>> >>> aspect involves the determination that a certificate has not been
>> >>> revoked, and one revocation checking mechanism is the Certificate
>> >>> Revocation List (CRL).  CRL validation is also specified in RFC 3280,
>> >>
>> >>
>> >> I would love this last sentence to be true but the reality is that:
>> >> "CRL validation is NOT specified in RFC 3280". :-(
>> >>
>> >>> which involves the constructions of a valid certification path for 
>> the
>> >>> CRL issuer.
>> >>
>> >>
>> >> There is no such a statement in RFC 3280.
>> >>
>> >>> Building a CRL issuer certification path from the signer of
>> >>
>> >>
>> >> There is no notion of "CRL issuer certification path" in RFC 3280.
>> >> The primary requirement is to make sure that the CRL issuer designated
>> >> by the CA is indeed the right one. In some (but not all) cases, I mean
>> >> among the zillion of cases, there MAY be a need to construct a CRL
>> >> issuer certification path.
>> >>
>> >>> the CRL to a trust anchor is straightforward when the certificate 
>> of the
>> >>> CRL issuer is present in the certification path associated with the
>> >>> target certificate, but it can be complex in other situations.
>> >>
>> >>
>> >> From the comments above, you can see that I cannot agree with the
>> >> above revised text. The remaining of the text is acceptable in
>> >> general, but could possibly be slightly revised to be more in
>> >> continuation with the changes there are needed above (i.e. it is not
>> >> cast in concrete).
>> >>
>> >> Denis
>> >>
>> >>> There are several legitimate scenarios where the certificate of 
>> the CRL
>> >>> issuer is not present, or easily discovered, from the target
>> >>> certification path.  This can be the case when indirect CRLs are 
>> used,
>> >>> when the certification Authority (CA) that issued the target 
>> certificate
>> >>> changes its certificate signing key, or when the CA employs separate
>> >>> keys for certificate signing and CRL signing.
>> >>> Methods of finding the certificate of the CRL issuer are currently
>> >>> available, such as though an accessible directory location or through
>> >>> use of the Subject Information Access extension in intermediary CA
>> >>> certificates.
>> >>> Directory lookup requires existence and access to a directory that 
>> has
>> >>> been populated with all of the necessary certificates.  The Subject
>> >>> Information Access extension, which supports building the CRL issuer
>> >>> certification path top-down (in the direction from the trust 
>> anchor to
>> >>> the CRL issuer), requires that some certificates in the CRL issuer
>> >>> certification path includes an appropriate Subject Information Access
>> >>> extension.
>> >>> RFC 3280 [PKIX1] provides for bottom-up discovery of certification 
>> paths
>> >>> through the Authority Information Access extension, where the
>> >>> id-ad-caIssuers access method may specify one or more accessLocation
>> >>> fields that reference CA certificates associated with the certificate
>> >>> containing this extension.
>> >>> This document enables the use of the Authority Information Access
>> >>> extension in CRLs, enabling a CRL checking application to use the 
>> access
>> >>> method (id-ad-caIssuers) to locate certificates that may be useful in
>> >>> the construction of a valid CRL issuer certification path to an
>> >>> appropriate trust anchor.
>> >>>
>> >>> Stefan Santesson
>> >>> Program Manager, Standards Liaison
>> >>> Windows Security
>> >>>
>> >>>
>> >>>> From: Denis Pinkas [mailto:[email-masked]]
>> >>>> Sent: den 18 april 2005 13:41
>> >>>> To: Stefan Santesson
>> >>>> Cc: Russ Housley; pkix
>> >>>> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
>> >>>>
>> >>>> Stefan,
>> >>>>
>> >>>>
>> >>>>> Denis,
>> >>>>
>> >>>>
>> >>>>> I will come back and comment on your text proposals, but before
>> >>>>
>> >>> that,
>> >>>
>> >>>> > a few questions/comments:
>> >>>>
>> >>>>
>> >>>>> <snip>
>> >>>>
>> >>>>
>> >>>>>>> You point out some well known issues related to the lack of
>> >>>>>>
>> >>> absolute
>> >>>
>> >>>>>>> cryptographic binding between CRL and certificates where the
>> >>>>>>> certificate and CRL is not signed by the same key.
>> >>>>>>
>> >>>>>>
>> >>>>>> Not really. It is indeed possible to have an absolute 
>> cryptographic
>> >>>>>> binding between CRL and certificates where the certificate and CRL
>> >>>>>
>> >>> is
>> >>>
>> >>>> not
>> >>>>
>> >>>>>> signed by the same key, but the key point is that proposed
>> >>>>>
>> >>> extension
>> >>>
>> >>>> >> is *not* the means to provide such a binding (and you agree with
>> >>>
>> >>> this
>> >>>
>> >>>> >> further down in this e-mail).
>> >>>>
>> >>>>
>> >>>>> We agree that this extension does not add to the concept of
>> >>>>> cryptographic binding. But how do you mean it can be done?
>> >>>>
>> >>>>
>> >>>> Would this mean that you believed this could not be done ? :-)
>> >>>>
>> >>>> I already provided the information, but since at that time you were
>> >>>> focussing on another issue, you probably missed the point.
>> >>>>
>> >>>> I would encourage you to read again that thread, but I will 
>> provide a
>> >>>> short
>> >>>> reply here to your question.
>> >>>>
>> >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains
>> >>>
>> >>> the
>> >>>
>> >>>> DN
>> >>>> of the CRL Issuer and we all know that CAs are free to assign the 
>> DNs
>> >>>
>> >>> they
>> >>>
>> >>>> wish. The next point is for a verifier to make sure that the DN 
>> which
>> >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that was
>> >>>
>> >>> meant
>> >>>
>> >>>> by the CA. The CRL must be issued by a CRL Issuer that has the same
>> >>>
>> >>> DN.
>> >>>
>> >>>> The
>> >>>> CRL Issuer will have a certificate issued by a CA.
>> >>>>
>> >>>> Case a): the CA that has issued that certificate is the same as 
>> the CA
>> >>>> that
>> >>>> has issued the target certificate (which contains the hereabove
>> >>>
>> >>> mentionned
>> >>>
>> >>>> CRL DP). This is easy to check for a verifier since the verifier 
>> must
>> >>>> first
>> >>>> build the certification path and then test the revocation status of
>> >>>
>> >>> every
>> >>>
>> >>>> element of the path. So the verifier knows the validated sequence of
>> >>>
>> >>> DNs
>> >>>
>> >>>> starting from a self-signed certificate. It must then use the same
>> >>>> sequence
>> >>>> of DNs to validate the CRL Issuer certificate.
>> >>>>
>> >>>> This is a general rule which does not require any extra local trust
>> >>>> information.
>> >>>>
>> >>>> Case b) : the CA that has issued that certificate is NOT the same as
>> >>>
>> >>> the
>> >>>
>> >>>> CA
>> >>>> that has issued the target certificate. This case requires extra
>> >>>
>> >>> *0local*
>> >>>
>> >>>> trust information. There are many such trust conditions possible and
>> >>>
>> >>> thus
>> >>>
>> >>>> this cannot be defined in general. Cases a) and b) are thus not
>> >>>
>> >>> equivalent
>> >>>
>> >>>> and have to be distinguished.
>> >>>>
>> >>>>
>> >>>>> <snip>
>> >>>>
>> >>>>
>> >>>>>>> This draft only introduces a new way to locate certificates
>> >>>>>>> that can be helpful in building this path.
>> >>>>>>
>> >>>>>>
>> >>>>>> At least one sentence of which we both agree !
>> >>>>>> It should be copied and pasted in the abstract.
>> >>>>>
>> >>>>>
>> >>>>> Good, then I suggest that we leave unrelated topics out of this
>> >>>>
>> >>> draft
>> >>>
>> >>>>> and focus on the issues that are related to this limited scope.
>> >>>>
>> >>>>
>> >>>> This is what I did in my proposal, except that we need to have a
>> >>>
>> >>> security
>> >>>
>> >>>> considerations section and the goal of that section is not to hide
>> >>>> problems
>> >>>> but to correctly warn users. Thus why an informatiove annex on the
>> >>>
>> >>> topics
>> >>>
>> >>>> mentionned in the security considerations section would be quite
>> >>>
>> >>> useful.
>> >>>
>> >>>> In fact, its content would be along the lines of the explanations
>> >>>
>> >>> which
>> >>>
>> >>>> are
>> >>>> just above.
>> >>>>
>> >>>> I hope this e-mail will help us to progress.
>> >>>>
>> >>>> Denis
>> >>>>
>> >>>>
>> >>>>> Stefan Santesson
>> >>>>> Program Manager - Standards Liaison
>> >>>>> Windows Security
>> >>>>
>> >>
>> >>
>> >
>> >
>>
>>
>>
> 
> 

Date: Tue, 10 May 2005 09:00:29 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>
CC: Russ Housley <[email-masked]>, pkix <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Stefan,

> Denis,

> I think all arguments have been spoken about this by now.

  ... but not all replied.

> The bottom line is not whether your arguments are right or wrong. It is
> that your discussion is out of scope for this draft.

> In the end of the day that is the reason why we are reluctant to add
> your proposed text in this document. 

More important, I am requesting the *deletion* of two sentences in the 
security considerations section. See my response posted to Russ.

Denis

> Unless you can find others to
> support you, you are in clear minority and as such I will not agree to
> do any changes.
> 
> I second WG last call for this draft.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
>  
> 
> 
>>From: Denis Pinkas [mailto:[email-masked]]
>>Sent: den 9 maj 2005 15:05
>>To: Stefan Santesson
>>Cc: Russ Housley; pkix
>>Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
>>
>>Stefan,
>>
>>I made the e-mail shorter. Your main arguments are the following:
>>
>>
> 
> ========================================================================
> ==
> 
>>[Stefan] But it has to provide a warning to something that is
> 
> introduced
> 
>>by the standard. This standard does not introduce the concept of CRL
>>signature checking or CRL issuer certificate validation, so that is
>>clearly out of scope. More about that below;
>>
>>[Denis] See below the last answer and also my arguments in the
>>soon-to-be-posted answer to Russ.
>>
>>
> 
> ========================================================================
> ==
> 
>>
>> > > RFC 3280 [PKIX1] specifies the validation of certification paths.
>> > > One aspect involves the determination that a certificate has not
> 
> been
> 
>> > > revoked, and one revocation checking mechanism is the Certificate
>> > > Revocation List (CRL).  CRL validation is also specified in RFC
> 
> 3280,
> 
>> > I would love this last sentence to be true but the reality is that:
>> > "CRL validation is NOT specified in RFC 3280". :-(
>>
>>[Stefan] In fact it is.
>>
>>RFC 3280, Section 6.3.3 CRL processing - on page 85:
>>
>>    (f)  Obtain and validate the certification path for the complete
> 
> CRL
> 
>>    issuer.  If a key usage extension is present in the CRL issuer's
>>    certificate, verify that the cRLSign bit is set.
>>
>>    (g)  Validate the signature on the complete CRL using the public
> 
> key
> 
>>    validated in step (f).
>>
>>[Denis] The text does not say how to obtain and validate the
> 
> certification
> 
>>path for the complete (???) CRL issuer. The text is not clear enough
> 
> so
> 
>>that
>>two implementors only looking at this sentence will provide
> 
> interoperable
> 
>>implementations.
>>
>>
> 
> ========================================================================
> ==
> 
>>[Stefan] It is my hope that the provided responses here can help
>>convince you to change your mind about that. If it doesn't I still
> 
> argue
> 
>>that the place to specify requirements and security considerations for
>>CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft.
>>
>>[Denis] I can agree with your last sentence, ... which means that it
>>should
>>not be in the main body of the document. In the security
> 
> considerations
> 
>>section, text is free and we shall at the very minimum warn
> 
> implementers
> 
>>and
>>we should provide some guidance. When the same certification path
> 
> (i.e.
> 
>>the
>>path used to validate the target certificate) is used, then there is
> 
> no
> 
>>security issue: this should be said. For all other cases, there MAY be
>>problems: this should also be said. It is as simple as that.
>>
>>Denis
> 
> 
> 

Date: Tue, 10 May 2005 08:59:36 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Russ,

Your statement below is correct, but does not answer to any of my 
questions/issues. In particular, the last one. I am still awaiting your 
responses.

Denis

> Denis:
> 
> RFC 3280 does not tell an implementor how for locate certificates for 
> any certification path construction.  There are several extensions that 
> provide pointers that may help an implementation, but other approaches 
> to obtaining the same certificates are always permitted.  I would fully 
> expect an implementation to check any local cache before accessing a 
> repository.
> 
> The CRL AIA extension fits this pattern.  A method for locating a 
> certificate is provided, but any other mechanism for locating the same 
> certificate is acceptable.
> 
> Russ
> 
>> Stefan,
>>
>> I made the e-mail shorter. Your main arguments are the following:
>>
>> ========================================================================== 
>>
>>
>> [Stefan] But it has to provide a warning to something that is introduced
>> by the standard. This standard does not introduce the concept of CRL
>> signature checking or CRL issuer certificate validation, so that is
>> clearly out of scope. More about that below;
>>
>> [Denis] See below the last answer and also my arguments in the 
>> soon-to-be-posted answer to Russ.
>>
>> ========================================================================== 
>>
>>
>>
>> > > RFC 3280 [PKIX1] specifies the validation of certification paths.
>> > > One aspect involves the determination that a certificate has not been
>> > > revoked, and one revocation checking mechanism is the Certificate
>> > > Revocation List (CRL).  CRL validation is also specified in RFC 3280,
>>
>> > I would love this last sentence to be true but the reality is that:
>> > "CRL validation is NOT specified in RFC 3280". :-(
>>
>> [Stefan] In fact it is.
>>
>> RFC 3280, Section 6.3.3 CRL processing - on page 85:
>>
>>    (f)  Obtain and validate the certification path for the complete CRL
>>    issuer.  If a key usage extension is present in the CRL issuer's
>>    certificate, verify that the cRLSign bit is set.
>>
>>    (g)  Validate the signature on the complete CRL using the public key
>>    validated in step (f).
>>
>> [Denis] The text does not say how to obtain and validate the 
>> certification path for the complete (???) CRL issuer. The text is not 
>> clear enough so that two implementors only looking at this sentence 
>> will provide interoperable implementations.
>>
>> ========================================================================== 
>>
>>
>> [Stefan] It is my hope that the provided responses here can help
>> convince you to change your mind about that. If it doesn't I still argue
>> that the place to specify requirements and security considerations for
>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft.
>>
>> [Denis] I can agree with your last sentence, ... which means that it 
>> should not be in the main body of the document. In the security 
>> considerations section, text is free and we shall at the very minimum 
>> warn implementers and we should provide some guidance. When the same 
>> certification path (i.e. the path used to validate the target 
>> certificate) is used, then there is no security issue: this should be 
>> said. For all other cases, there MAY be problems: this should also be 
>> said. It is as simple as that.
>>
>> Denis
>>
> 
> 

Content-class: urn:content-classes:message
Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Date: Tue, 10 May 2005 00:24:34 +0100
From: "Stefan Santesson" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

Denis,

I think all arguments have been spoken about this by now.

The bottom line is not whether your arguments are right or wrong. It is
that your discussion is out of scope for this draft.

In the end of the day that is the reason why we are reluctant to add
your proposed text in this document. Unless you can find others to
support you, you are in clear minority and as such I will not agree to
do any changes.

I second WG last call for this draft.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 9 maj 2005 15:05
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> Stefan,
> 
> I made the e-mail shorter. Your main arguments are the following:
> 
>
========================================================================
==
> 
> [Stefan] But it has to provide a warning to something that is
introduced
> by the standard. This standard does not introduce the concept of CRL
> signature checking or CRL issuer certificate validation, so that is
> clearly out of scope. More about that below;
> 
> [Denis] See below the last answer and also my arguments in the
> soon-to-be-posted answer to Russ.
> 
>
========================================================================
==
> 
> 
>  > > RFC 3280 [PKIX1] specifies the validation of certification paths.
>  > > One aspect involves the determination that a certificate has not
been
>  > > revoked, and one revocation checking mechanism is the Certificate
>  > > Revocation List (CRL).  CRL validation is also specified in RFC
3280,
> 
>  > I would love this last sentence to be true but the reality is that:
>  > "CRL validation is NOT specified in RFC 3280". :-(
> 
> [Stefan] In fact it is.
> 
> RFC 3280, Section 6.3.3 CRL processing - on page 85:
> 
>     (f)  Obtain and validate the certification path for the complete
CRL
>     issuer.  If a key usage extension is present in the CRL issuer's
>     certificate, verify that the cRLSign bit is set.
> 
>     (g)  Validate the signature on the complete CRL using the public
key
>     validated in step (f).
> 
> [Denis] The text does not say how to obtain and validate the
certification
> path for the complete (???) CRL issuer. The text is not clear enough
so
> that
> two implementors only looking at this sentence will provide
interoperable
> implementations.
========================================================================
==
> 
> [Stefan] It is my hope that the provided responses here can help
> convince you to change your mind about that. If it doesn't I still
argue
> that the place to specify requirements and security considerations for
> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft.
> 
> [Denis] I can agree with your last sentence, ... which means that it
> should
> not be in the main body of the document. In the security
considerations
> section, text is free and we shall at the very minimum warn
implementers
> and
> we should provide some guidance. When the same certification path
(i.e.
> the
> path used to validate the target certificate) is used, then there is
no
> security issue: this should be said. For all other cases, there MAY be
> problems: this should also be said. It is as simple as that.
> 
> Denis

Date: Mon, 09 May 2005 11:30:44 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Cc: [email-masked]
Sender: [email-masked]

Denis:

Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated.

You say that it is not clear what validation policy needs to be used, but 
this is completely irrelevant to the discussion of the CRL AIA 
extension.  This extension aid in certification path construction, not the 
validation of the path once it is constructed.

There are many factors which need to be considered in the validation of the 
CRL issue certificate.  The values of the key usage extension and the 
certificate policies extension are two that jump to mind.  There are 
probably more if I spend the time to consider each possible scenario.

In my opinion, this document is ready for WG Last Call.

Russ

At 09:07 AM 5/9/2005, Denis Pinkas wrote:
>Russ,
>
> > Here is a quote from RFC 3280.  To me, it is clear that a CRL issuer has
> > a certificate.
>
>True, a CRL issuer (that is different from the CA that has issued the target
>certificate) has a certificate. So we both strongly agree on this this. :-)
>
> > Obviously, all certificates need to be validated, which
> > includes certification path construction and certification path validation.
>
>When a sentence starts with "Obviously", it means that it is not so obvious.
>:-|
>
>The real question is whether the CRL issuer certificate has to be verified
>using rules (i.e. a validation policy) which are independent from the
>certification path construction of the target certificate. RFC 3280 does not
>provide a crystal clear answer to that question.
>
>If the rules are different, then you MAY end up with a security issue (see
>my previous explanations). The current "recommendations" that are in the
>security considerations section do NOT solve this issue in the general case.
>
>If the rules are the same, i.e. the path used to validate the certification
>path from the certificate are also used, then there is no security issue.
>
>I do not think it would be good to hide this issue in the proposed draft.
>Anyway, the current "recommendations" do NOT solve the issue and are thus 
>not acceptable and so this section cannot stand as it is.
>
>Denis
>
> > 5.1.1.3  signatureValue
> >
> >    The signatureValue field contains a digital signature computed upon
> >    the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded tbsCertList
> >    is used as the input to the signature function.  This signature value
> >    is encoded as a BIT STRING and included in the CRL signatureValue
> >    field.  The details of this process are specified for each of the
> >    supported algorithms in [PKIXALGS].
> >
> >    CAs that are also CRL issuers MAY use one private key to digitally
> >    sign certificates and CRLs, or MAY use separate private keys to
> >    digitally sign certificates and CRLs.  When separate private keys are
> >    employed, each of the public keys associated with these private keys
> >    is placed in a separate certificate, one with the keyCertSign bit set
> >    in the key usage extension, and one with the cRLSign bit set in the
> >    key usage extension (section 4.2.1.3).  When separate private keys
> >    are employed, certificates issued by the CA contain one authority key
> >    identifier, and the corresponding CRLs contain a different authority
> >    key identifier.  The use of separate CA certificates for validation
> >    of certificate signatures and CRL signatures can offer improved
> >    security characteristics; however, it imposes a burden on
> >    applications, and it might limit interoperability.  Many applications
> >    construct a certification path, and then validate the certification
> >    path (section 6).  CRL checking in turn requires a separate
> >    certification path to be constructed and validated for the CA's CRL
> >    signature validation certificate.  Applications that perform CRL
> >    checking MUST support certification path validation when certificates
> >    and CRLs are digitally signed with the same CA private key.  These
> >    applications SHOULD support certification path validation when
> >    certificates and CRLs are digitally signed with different CA private
> >    keys.
> >
> > Russ
> >
> > At 01:12 PM 4/28/2005, Denis Pinkas wrote:
> >
> >> Stefan and Russ,
> >>
> >>> Denis,
> >>
> >>
> >>> Russ and I have taken a thorough look at your text proposal and we have
> >>> edited a counter proposal where we try to meet your needs as much as
> >>> possible without compromising what we think is the core purpose of the
> >>> draft (to enable certificate discovery bottom-up).
> >>
> >>
> >>> The conclusion is that we suggest changes to the introduction section
> >>> but we keep the old security considerations intact.
> >>
> >>
> >> I would suggest that a merge would need to be done between the "old"
> >> security considerations section and the "new" one.
> >>
> >> The "old" security considerations section is mentionning a solution
> >> which does NOT suppress the problem, but minimize the risk only in
> >> case the CAs are really "honest".
> >>
> >> The old" security considerations section does not provide a solution
> >> in case the name collsion between two CRL issuer name is deliberate,
> >> whereas the "new" security considerations section provides a secure
> >> solution in one case and clearly mentions that all other cases are
> >> dependant about "zillions" of *local* trust conditions which cannot
> >> all be standardized.
> >>
> >> The main purpose of a security considerations section is to provide
> >> the adequate warnings and solutions when they exist and not to hide
> >> the problems.
> >>
> >>> That is not because
> >>> we necessarily disagree with all of the statements in your proposal, but
> >>> in the cases we don't, we still think it is out of scope for this work.
> >>
> >>
> >> This is clearly within the scope of a security considerations section.
> >>
> >>> The new introduction proposal based on your input is:
> >>> --------------------------------------------------------------
> >>> RFC 3280 [PKIX1] specifies the validation of certification paths.  One
> >>> aspect involves the determination that a certificate has not been
> >>> revoked, and one revocation checking mechanism is the Certificate
> >>> Revocation List (CRL).  CRL validation is also specified in RFC 3280,
> >>
> >>
> >> I would love this last sentence to be true but the reality is that:
> >> "CRL validation is NOT specified in RFC 3280". :-(
> >>
> >>> which involves the constructions of a valid certification path for the
> >>> CRL issuer.
> >>
> >>
> >> There is no such a statement in RFC 3280.
> >>
> >>> Building a CRL issuer certification path from the signer of
> >>
> >>
> >> There is no notion of "CRL issuer certification path" in RFC 3280.
> >> The primary requirement is to make sure that the CRL issuer designated
> >> by the CA is indeed the right one. In some (but not all) cases, I mean
> >> among the zillion of cases, there MAY be a need to construct a CRL
> >> issuer certification path.
> >>
> >>> the CRL to a trust anchor is straightforward when the certificate of the
> >>> CRL issuer is present in the certification path associated with the
> >>> target certificate, but it can be complex in other situations.
> >>
> >>
> >> From the comments above, you can see that I cannot agree with the
> >> above revised text. The remaining of the text is acceptable in
> >> general, but could possibly be slightly revised to be more in
> >> continuation with the changes there are needed above (i.e. it is not
> >> cast in concrete).
> >>
> >> Denis
> >>
> >>> There are several legitimate scenarios where the certificate of the CRL
> >>> issuer is not present, or easily discovered, from the target
> >>> certification path.  This can be the case when indirect CRLs are used,
> >>> when the certification Authority (CA) that issued the target certificate
> >>> changes its certificate signing key, or when the CA employs separate
> >>> keys for certificate signing and CRL signing.
> >>> Methods of finding the certificate of the CRL issuer are currently
> >>> available, such as though an accessible directory location or through
> >>> use of the Subject Information Access extension in intermediary CA
> >>> certificates.
> >>> Directory lookup requires existence and access to a directory that has
> >>> been populated with all of the necessary certificates.  The Subject
> >>> Information Access extension, which supports building the CRL issuer
> >>> certification path top-down (in the direction from the trust anchor to
> >>> the CRL issuer), requires that some certificates in the CRL issuer
> >>> certification path includes an appropriate Subject Information Access
> >>> extension.
> >>> RFC 3280 [PKIX1] provides for bottom-up discovery of certification paths
> >>> through the Authority Information Access extension, where the
> >>> id-ad-caIssuers access method may specify one or more accessLocation
> >>> fields that reference CA certificates associated with the certificate
> >>> containing this extension.
> >>> This document enables the use of the Authority Information Access
> >>> extension in CRLs, enabling a CRL checking application to use the access
> >>> method (id-ad-caIssuers) to locate certificates that may be useful in
> >>> the construction of a valid CRL issuer certification path to an
> >>> appropriate trust anchor.
> >>>
> >>> Stefan Santesson
> >>> Program Manager, Standards Liaison
> >>> Windows Security
> >>>
> >>>
> >>>> From: Denis Pinkas [mailto:[email-masked]]
> >>>> Sent: den 18 april 2005 13:41
> >>>> To: Stefan Santesson
> >>>> Cc: Russ Housley; pkix
> >>>> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
> >>>>
> >>>> Stefan,
> >>>>
> >>>>
> >>>>> Denis,
> >>>>
> >>>>
> >>>>> I will come back and comment on your text proposals, but before
> >>>>
> >>> that,
> >>>
> >>>> > a few questions/comments:
> >>>>
> >>>>
> >>>>> <snip>
> >>>>
> >>>>
> >>>>>>> You point out some well known issues related to the lack of
> >>>>>>
> >>> absolute
> >>>
> >>>>>>> cryptographic binding between CRL and certificates where the
> >>>>>>> certificate and CRL is not signed by the same key.
> >>>>>>
> >>>>>>
> >>>>>> Not really. It is indeed possible to have an absolute cryptographic
> >>>>>> binding between CRL and certificates where the certificate and CRL
> >>>>>
> >>> is
> >>>
> >>>> not
> >>>>
> >>>>>> signed by the same key, but the key point is that proposed
> >>>>>
> >>> extension
> >>>
> >>>> >> is *not* the means to provide such a binding (and you agree with
> >>>
> >>> this
> >>>
> >>>> >> further down in this e-mail).
> >>>>
> >>>>
> >>>>> We agree that this extension does not add to the concept of
> >>>>> cryptographic binding. But how do you mean it can be done?
> >>>>
> >>>>
> >>>> Would this mean that you believed this could not be done ? :-)
> >>>>
> >>>> I already provided the information, but since at that time you were
> >>>> focussing on another issue, you probably missed the point.
> >>>>
> >>>> I would encourage you to read again that thread, but I will provide a
> >>>> short
> >>>> reply here to your question.
> >>>>
> >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains
> >>>
> >>> the
> >>>
> >>>> DN
> >>>> of the CRL Issuer and we all know that CAs are free to assign the DNs
> >>>
> >>> they
> >>>
> >>>> wish. The next point is for a verifier to make sure that the DN which
> >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that was
> >>>
> >>> meant
> >>>
> >>>> by the CA. The CRL must be issued by a CRL Issuer that has the same
> >>>
> >>> DN.
> >>>
> >>>> The
> >>>> CRL Issuer will have a certificate issued by a CA.
> >>>>
> >>>> Case a): the CA that has issued that certificate is the same as the CA
> >>>> that
> >>>> has issued the target certificate (which contains the hereabove
> >>>
> >>> mentionned
> >>>
> >>>> CRL DP). This is easy to check for a verifier since the verifier must
> >>>> first
> >>>> build the certification path and then test the revocation status of
> >>>
> >>> every
> >>>
> >>>> element of the path. So the verifier knows the validated sequence of
> >>>
> >>> DNs
> >>>
> >>>> starting from a self-signed certificate. It must then use the same
> >>>> sequence
> >>>> of DNs to validate the CRL Issuer certificate.
> >>>>
> >>>> This is a general rule which does not require any extra local trust
> >>>> information.
> >>>>
> >>>> Case b) : the CA that has issued that certificate is NOT the same as
> >>>
> >>> the
> >>>
> >>>> CA
> >>>> that has issued the target certificate. This case requires extra
> >>>
> >>> *0local*
> >>>
> >>>> trust information. There are many such trust conditions possible and
> >>>
> >>> thus
> >>>
> >>>> this cannot be defined in general. Cases a) and b) are thus not
> >>>
> >>> equivalent
> >>>
> >>>> and have to be distinguished.
> >>>>
> >>>>
> >>>>> <snip>
> >>>>
> >>>>
> >>>>>>> This draft only introduces a new way to locate certificates
> >>>>>>> that can be helpful in building this path.
> >>>>>>
> >>>>>>
> >>>>>> At least one sentence of which we both agree !
> >>>>>> It should be copied and pasted in the abstract.
> >>>>>
> >>>>>
> >>>>> Good, then I suggest that we leave unrelated topics out of this
> >>>>
> >>> draft
> >>>
> >>>>> and focus on the issues that are related to this limited scope.
> >>>>
> >>>>
> >>>> This is what I did in my proposal, except that we need to have a
> >>>
> >>> security
> >>>
> >>>> considerations section and the goal of that section is not to hide
> >>>> problems
> >>>> but to correctly warn users. Thus why an informatiove annex on the
> >>>
> >>> topics
> >>>
> >>>> mentionned in the security considerations section would be quite
> >>>
> >>> useful.
> >>>
> >>>> In fact, its content would be along the lines of the explanations
> >>>
> >>> which
> >>>
> >>>> are
> >>>> just above.
> >>>>
> >>>> I hope this e-mail will help us to progress.
> >>>>
> >>>> Denis
> >>>>
> >>>>
> >>>>> Stefan Santesson
> >>>>> Program Manager - Standards Liaison
> >>>>> Windows Security
> >>>>
> >>
> >>
> >
> >
>
>
>

Date: Mon, 09 May 2005 11:24:15 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Cc: pkix <[email-masked]>
Sender: [email-masked]

Denis:

RFC 3280 does not tell an implementor how for locate certificates for any 
certification path construction.  There are several extensions that provide 
pointers that may help an implementation, but other approaches to obtaining 
the same certificates are always permitted.  I would fully expect an 
implementation to check any local cache before accessing a repository.

The CRL AIA extension fits this pattern.  A method for locating a 
certificate is provided, but any other mechanism for locating the same 
certificate is acceptable.

Russ

>Stefan,
>
>I made the e-mail shorter. Your main arguments are the following:
>
>==========================================================================
>
>[Stefan] But it has to provide a warning to something that is introduced
>by the standard. This standard does not introduce the concept of CRL
>signature checking or CRL issuer certificate validation, so that is
>clearly out of scope. More about that below;
>
>[Denis] See below the last answer and also my arguments in the 
>soon-to-be-posted answer to Russ.
>
>==========================================================================
>
>
> > > RFC 3280 [PKIX1] specifies the validation of certification paths.
> > > One aspect involves the determination that a certificate has not been
> > > revoked, and one revocation checking mechanism is the Certificate
> > > Revocation List (CRL).  CRL validation is also specified in RFC 3280,
>
> > I would love this last sentence to be true but the reality is that:
> > "CRL validation is NOT specified in RFC 3280". :-(
>
>[Stefan] In fact it is.
>
>RFC 3280, Section 6.3.3 CRL processing - on page 85:
>
>    (f)  Obtain and validate the certification path for the complete CRL
>    issuer.  If a key usage extension is present in the CRL issuer's
>    certificate, verify that the cRLSign bit is set.
>
>    (g)  Validate the signature on the complete CRL using the public key
>    validated in step (f).
>
>[Denis] The text does not say how to obtain and validate the certification 
>path for the complete (???) CRL issuer. The text is not clear enough so 
>that two implementors only looking at this sentence will provide 
>interoperable implementations.
>
>==========================================================================
>
>[Stefan] It is my hope that the provided responses here can help
>convince you to change your mind about that. If it doesn't I still argue
>that the place to specify requirements and security considerations for
>CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft.
>
>[Denis] I can agree with your last sentence, ... which means that it 
>should not be in the main body of the document. In the security 
>considerations section, text is free and we shall at the very minimum warn 
>implementers and we should provide some guidance. When the same 
>certification path (i.e. the path used to validate the target certificate) 
>is used, then there is no security issue: this should be said. For all 
>other cases, there MAY be problems: this should also be said. It is as 
>simple as that.
>
>Denis
>

Date: Mon, 09 May 2005 15:07:42 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: Stefan Santesson <[email-masked]>, pkix <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Russ,

 > Here is a quote from RFC 3280.  To me, it is clear that a CRL issuer has
 > a certificate.

True, a CRL issuer (that is different from the CA that has issued the target
certificate) has a certificate. So we both strongly agree on this this. :-)

 > Obviously, all certificates need to be validated, which
 > includes certification path construction and certification path validation.

When a sentence starts with "Obviously", it means that it is not so obvious.
:-|

The real question is whether the CRL issuer certificate has to be verified
using rules (i.e. a validation policy) which are independent from the
certification path construction of the target certificate. RFC 3280 does not
provide a crystal clear answer to that question.

If the rules are different, then you MAY end up with a security issue (see
my previous explanations). The current "recommendations" that are in the
security considerations section do NOT solve this issue in the general case.

If the rules are the same, i.e. the path used to validate the certification
path from the certificate are also used, then there is no security issue.

I do not think it would be good to hide this issue in the proposed draft.
Anyway, the current "recommendations" do NOT solve the issue and are thus 
not acceptable and so this section cannot stand as it is.

Denis

 > 5.1.1.3  signatureValue
 >
 >    The signatureValue field contains a digital signature computed upon
 >    the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded tbsCertList
 >    is used as the input to the signature function.  This signature value
 >    is encoded as a BIT STRING and included in the CRL signatureValue
 >    field.  The details of this process are specified for each of the
 >    supported algorithms in [PKIXALGS].
 >
 >    CAs that are also CRL issuers MAY use one private key to digitally
 >    sign certificates and CRLs, or MAY use separate private keys to
 >    digitally sign certificates and CRLs.  When separate private keys are
 >    employed, each of the public keys associated with these private keys
 >    is placed in a separate certificate, one with the keyCertSign bit set
 >    in the key usage extension, and one with the cRLSign bit set in the
 >    key usage extension (section 4.2.1.3).  When separate private keys
 >    are employed, certificates issued by the CA contain one authority key
 >    identifier, and the corresponding CRLs contain a different authority
 >    key identifier.  The use of separate CA certificates for validation
 >    of certificate signatures and CRL signatures can offer improved
 >    security characteristics; however, it imposes a burden on
 >    applications, and it might limit interoperability.  Many applications
 >    construct a certification path, and then validate the certification
 >    path (section 6).  CRL checking in turn requires a separate
 >    certification path to be constructed and validated for the CA's CRL
 >    signature validation certificate.  Applications that perform CRL
 >    checking MUST support certification path validation when certificates
 >    and CRLs are digitally signed with the same CA private key.  These
 >    applications SHOULD support certification path validation when
 >    certificates and CRLs are digitally signed with different CA private
 >    keys.
 >
 > Russ
 >
 > At 01:12 PM 4/28/2005, Denis Pinkas wrote:
 >
 >> Stefan and Russ,
 >>
 >>> Denis,
 >>
 >>
 >>> Russ and I have taken a thorough look at your text proposal and we have
 >>> edited a counter proposal where we try to meet your needs as much as
 >>> possible without compromising what we think is the core purpose of the
 >>> draft (to enable certificate discovery bottom-up).
 >>
 >>
 >>> The conclusion is that we suggest changes to the introduction section
 >>> but we keep the old security considerations intact.
 >>
 >>
 >> I would suggest that a merge would need to be done between the "old"
 >> security considerations section and the "new" one.
 >>
 >> The "old" security considerations section is mentionning a solution
 >> which does NOT suppress the problem, but minimize the risk only in
 >> case the CAs are really "honest".
 >>
 >> The old" security considerations section does not provide a solution
 >> in case the name collsion between two CRL issuer name is deliberate,
 >> whereas the "new" security considerations section provides a secure
 >> solution in one case and clearly mentions that all other cases are
 >> dependant about "zillions" of *local* trust conditions which cannot
 >> all be standardized.
 >>
 >> The main purpose of a security considerations section is to provide
 >> the adequate warnings and solutions when they exist and not to hide
 >> the problems.
 >>
 >>> That is not because
 >>> we necessarily disagree with all of the statements in your proposal, but
 >>> in the cases we don't, we still think it is out of scope for this work.
 >>
 >>
 >> This is clearly within the scope of a security considerations section.
 >>
 >>> The new introduction proposal based on your input is:
 >>> --------------------------------------------------------------
 >>> RFC 3280 [PKIX1] specifies the validation of certification paths.  One
 >>> aspect involves the determination that a certificate has not been
 >>> revoked, and one revocation checking mechanism is the Certificate
 >>> Revocation List (CRL).  CRL validation is also specified in RFC 3280,
 >>
 >>
 >> I would love this last sentence to be true but the reality is that:
 >> "CRL validation is NOT specified in RFC 3280". :-(
 >>
 >>> which involves the constructions of a valid certification path for the
 >>> CRL issuer.
 >>
 >>
 >> There is no such a statement in RFC 3280.
 >>
 >>> Building a CRL issuer certification path from the signer of
 >>
 >>
 >> There is no notion of "CRL issuer certification path" in RFC 3280.
 >> The primary requirement is to make sure that the CRL issuer designated
 >> by the CA is indeed the right one. In some (but not all) cases, I mean
 >> among the zillion of cases, there MAY be a need to construct a CRL
 >> issuer certification path.
 >>
 >>> the CRL to a trust anchor is straightforward when the certificate of the
 >>> CRL issuer is present in the certification path associated with the
 >>> target certificate, but it can be complex in other situations.
 >>
 >>
 >> From the comments above, you can see that I cannot agree with the
 >> above revised text. The remaining of the text is acceptable in
 >> general, but could possibly be slightly revised to be more in
 >> continuation with the changes there are needed above (i.e. it is not
 >> cast in concrete).
 >>
 >> Denis
 >>
 >>> There are several legitimate scenarios where the certificate of the CRL
 >>> issuer is not present, or easily discovered, from the target
 >>> certification path.  This can be the case when indirect CRLs are used,
 >>> when the certification Authority (CA) that issued the target certificate
 >>> changes its certificate signing key, or when the CA employs separate
 >>> keys for certificate signing and CRL signing.
 >>> Methods of finding the certificate of the CRL issuer are currently
 >>> available, such as though an accessible directory location or through
 >>> use of the Subject Information Access extension in intermediary CA
 >>> certificates.
 >>> Directory lookup requires existence and access to a directory that has
 >>> been populated with all of the necessary certificates.  The Subject
 >>> Information Access extension, which supports building the CRL issuer
 >>> certification path top-down (in the direction from the trust anchor to
 >>> the CRL issuer), requires that some certificates in the CRL issuer
 >>> certification path includes an appropriate Subject Information Access
 >>> extension.
 >>> RFC 3280 [PKIX1] provides for bottom-up discovery of certification paths
 >>> through the Authority Information Access extension, where the
 >>> id-ad-caIssuers access method may specify one or more accessLocation
 >>> fields that reference CA certificates associated with the certificate
 >>> containing this extension.
 >>> This document enables the use of the Authority Information Access
 >>> extension in CRLs, enabling a CRL checking application to use the access
 >>> method (id-ad-caIssuers) to locate certificates that may be useful in
 >>> the construction of a valid CRL issuer certification path to an
 >>> appropriate trust anchor.
 >>>
 >>> Stefan Santesson
 >>> Program Manager, Standards Liaison
 >>> Windows Security
 >>>
 >>>
 >>>> From: Denis Pinkas [mailto:[email-masked]]
 >>>> Sent: den 18 april 2005 13:41
 >>>> To: Stefan Santesson
 >>>> Cc: Russ Housley; pkix
 >>>> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
 >>>>
 >>>> Stefan,
 >>>>
 >>>>
 >>>>> Denis,
 >>>>
 >>>>
 >>>>> I will come back and comment on your text proposals, but before
 >>>>
 >>> that,
 >>>
 >>>> > a few questions/comments:
 >>>>
 >>>>
 >>>>> <snip>
 >>>>
 >>>>
 >>>>>>> You point out some well known issues related to the lack of
 >>>>>>
 >>> absolute
 >>>
 >>>>>>> cryptographic binding between CRL and certificates where the
 >>>>>>> certificate and CRL is not signed by the same key.
 >>>>>>
 >>>>>>
 >>>>>> Not really. It is indeed possible to have an absolute cryptographic
 >>>>>> binding between CRL and certificates where the certificate and CRL
 >>>>>
 >>> is
 >>>
 >>>> not
 >>>>
 >>>>>> signed by the same key, but the key point is that proposed
 >>>>>
 >>> extension
 >>>
 >>>> >> is *not* the means to provide such a binding (and you agree with
 >>>
 >>> this
 >>>
 >>>> >> further down in this e-mail).
 >>>>
 >>>>
 >>>>> We agree that this extension does not add to the concept of
 >>>>> cryptographic binding. But how do you mean it can be done?
 >>>>
 >>>>
 >>>> Would this mean that you believed this could not be done ? :-)
 >>>>
 >>>> I already provided the information, but since at that time you were
 >>>> focussing on another issue, you probably missed the point.
 >>>>
 >>>> I would encourage you to read again that thread, but I will provide a
 >>>> short
 >>>> reply here to your question.
 >>>>
 >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains
 >>>
 >>> the
 >>>
 >>>> DN
 >>>> of the CRL Issuer and we all know that CAs are free to assign the DNs
 >>>
 >>> they
 >>>
 >>>> wish. The next point is for a verifier to make sure that the DN which
 >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that was
 >>>
 >>> meant
 >>>
 >>>> by the CA. The CRL must be issued by a CRL Issuer that has the same
 >>>
 >>> DN.
 >>>
 >>>> The
 >>>> CRL Issuer will have a certificate issued by a CA.
 >>>>
 >>>> Case a): the CA that has issued that certificate is the same as the CA
 >>>> that
 >>>> has issued the target certificate (which contains the hereabove
 >>>
 >>> mentionned
 >>>
 >>>> CRL DP). This is easy to check for a verifier since the verifier must
 >>>> first
 >>>> build the certification path and then test the revocation status of
 >>>
 >>> every
 >>>
 >>>> element of the path. So the verifier knows the validated sequence of
 >>>
 >>> DNs
 >>>
 >>>> starting from a self-signed certificate. It must then use the same
 >>>> sequence
 >>>> of DNs to validate the CRL Issuer certificate.
 >>>>
 >>>> This is a general rule which does not require any extra local trust
 >>>> information.
 >>>>
 >>>> Case b) : the CA that has issued that certificate is NOT the same as
 >>>
 >>> the
 >>>
 >>>> CA
 >>>> that has issued the target certificate. This case requires extra
 >>>
 >>> *0local*
 >>>
 >>>> trust information. There are many such trust conditions possible and
 >>>
 >>> thus
 >>>
 >>>> this cannot be defined in general. Cases a) and b) are thus not
 >>>
 >>> equivalent
 >>>
 >>>> and have to be distinguished.
 >>>>
 >>>>
 >>>>> <snip>
 >>>>
 >>>>
 >>>>>>> This draft only introduces a new way to locate certificates
 >>>>>>> that can be helpful in building this path.
 >>>>>>
 >>>>>>
 >>>>>> At least one sentence of which we both agree !
 >>>>>> It should be copied and pasted in the abstract.
 >>>>>
 >>>>>
 >>>>> Good, then I suggest that we leave unrelated topics out of this
 >>>>
 >>> draft
 >>>
 >>>>> and focus on the issues that are related to this limited scope.
 >>>>
 >>>>
 >>>> This is what I did in my proposal, except that we need to have a
 >>>
 >>> security
 >>>
 >>>> considerations section and the goal of that section is not to hide
 >>>> problems
 >>>> but to correctly warn users. Thus why an informatiove annex on the
 >>>
 >>> topics
 >>>
 >>>> mentionned in the security considerations section would be quite
 >>>
 >>> useful.
 >>>
 >>>> In fact, its content would be along the lines of the explanations
 >>>
 >>> which
 >>>
 >>>> are
 >>>> just above.
 >>>>
 >>>> I hope this e-mail will help us to progress.
 >>>>
 >>>> Denis
 >>>>
 >>>>
 >>>>> Stefan Santesson
 >>>>> Program Manager - Standards Liaison
 >>>>> Windows Security
 >>>>
 >>
 >>
 >
 >

Date: Mon, 09 May 2005 15:05:24 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stefan Santesson <[email-masked]>
CC: Russ Housley <[email-masked]>, pkix <[email-masked]>
Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
Sender: [email-masked]

Stefan,

I made the e-mail shorter. Your main arguments are the following:

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

[Stefan] But it has to provide a warning to something that is introduced
by the standard. This standard does not introduce the concept of CRL
signature checking or CRL issuer certificate validation, so that is
clearly out of scope. More about that below;

[Denis] See below the last answer and also my arguments in the 
soon-to-be-posted answer to Russ.

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

 > > RFC 3280 [PKIX1] specifies the validation of certification paths.
 > > One aspect involves the determination that a certificate has not been
 > > revoked, and one revocation checking mechanism is the Certificate
 > > Revocation List (CRL).  CRL validation is also specified in RFC 3280,

 > I would love this last sentence to be true but the reality is that:
 > "CRL validation is NOT specified in RFC 3280". :-(

[Stefan] In fact it is.

RFC 3280, Section 6.3.3 CRL processing - on page 85:

    (f)  Obtain and validate the certification path for the complete CRL
    issuer.  If a key usage extension is present in the CRL issuer's
    certificate, verify that the cRLSign bit is set.

    (g)  Validate the signature on the complete CRL using the public key
    validated in step (f).

[Denis] The text does not say how to obtain and validate the certification 
path for the complete (???) CRL issuer. The text is not clear enough so that 
two implementors only looking at this sentence will provide interoperable 
implementations.

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

[Stefan] It is my hope that the provided responses here can help
convince you to change your mind about that. If it doesn't I still argue
that the place to specify requirements and security considerations for
CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft.

[Denis] I can agree with your last sentence, ... which means that it should 
not be in the main body of the document. In the security considerations 
section, text is free and we shall at the very minimum warn implementers and 
we should provide some guidance. When the same certification path (i.e. the 
path used to validate the target certificate) is used, then there is no 
security issue: this should be said. For all other cases, there MAY be 
problems: this should also be said. It is as simple as that.

Denis

To: [email-masked]
Subject: RFC 4059 on Internet X.509 Public Key Infrastructure Warranty Certificate Extension
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Fri, 06 May 2005 17:18:42 -0700
Sender: [email-masked]

--NextPart

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

        RFC 4059

        Title:      Internet X.509 Public Key Infrastructure
                    Warranty Certificate Extension
        Author(s):  D. Linsenbardt, S. Pontius, A. Sturgeon
        Status:     Informational
        Date:       May 2005
        Mailbox:    [email-masked], [email-masked],
                    [email-masked]
        Pages:      9
        Characters: 17904
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-warranty-extn-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4059.txt

This document describes a certificate extension to explicitly state
the warranty offered by a Certificate Authority (CA) for the
certificate containing the extension.

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

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

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.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

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

RETRIEVE: rfc
DOC-ID: rfc4059

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc4059.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--

Content-class: urn:content-classes:message
Subject: RE: RFC3280bis: policy processing.
Date: Fri, 6 May 2005 16:01:41 +0100
From: "Stefan Santesson" <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

Thanks David, you are absolutely right.

This property just slipped my mind for a moment.

Stefan Santesson 
Program Manager, Standards Liaison 
Windows Security 
� 
________________________________________
From: David A. Cooper [mailto:[email-masked]] 
Sent: den 6 maj 2005 14:53
To: Stefan Santesson
Cc: pkix
Subject: Re: RFC3280bis: policy processing.

Stefan Santesson wrote: 
David,

Another aspect of this strikes me.

That is what happens when a policy mapping extension maps from one
issuer domain policy to several subject domain policies.

The text in X.509 has noticed the need to duplicate the row (node in RFC
3280) for the issuer domain policy to accommodate both mappings.

Reading this corresponding text from RFC 3280 it seems that the
corresponding creation of a new node is not specified in RFC 3280 which
would result in the same node being overwritten twice with a new subject
domain policy, resulting in a loss of the first mapping.

Unless I misread this, this seems to be a bug that we do need to fix.

Stefan,

In RFC 3280, this is addressed by maintaining, within a single node, the set of policies that appear as subject domain policies for a given issuerDomainPolicy (the expected_policy_set):
6.1.4� Preparation for Certificate i+1

�� To prepare for processing of certificate i+1, perform the following
�� steps for certificate i:

����� (b)� If a policy mappings extension is present, then for each
����� issuerDomainPolicy ID-P in the policy mappings extension:

�������� (1)� If the policy_mapping variable is greater than 0, for each
�������� node in the valid_policy_tree of depth i where ID-P is the
�������� valid_policy, set expected_policy_set to the set of
�������� subjectDomainPolicy values that are specified as equivalent to
�������� ID-P by the policy mappings extension.
Take, for example figure 6 from RFC 3280:
������������������� � ��� +-----------------+
������������������������� |����� Red������� |
������������������������� +-----------------+
������������������������� |������ {}������� |
������������������������� +-----------------+ node of depth i-1
������������������������� |� {Gold, Silver} |
������������������������� +-----------------+
���������������������������� /���������� \
��������������������������� /������������ \
�������������������������� /�������������� \
������������������������� /���������������� \
����������� +-----------------+��������� +-----------------+
����������� |����� Gold������ |��������� |���� Silver����� |
����������� +-----------------+��������� +-----------------+
����������� |������ {}������� |��������� |������ {}������� |
����������� +-----------------+ nodes of +-----------------+
����������� |���� {Gold}����� | depth i� |��� {Silver}���� |
����������� +-----------------+��������� +-----------------+

�������� Figure 6.� Processing unmatched policies when the certificate
�������� policies extension specifies anyPolicy
This subtree would be created as a result of:

certificate i-1:
certificatePolicies:� Red
policyMappings:
��� issuerDomainPolicy: Red
��� subjectDomainPolicy: Gold

��� issuerDomainPolicy: Red
��� subjectDomainPolicy: Silver

certificate i:
certificatePolicies: Gold, Silver

Dave

Date: Fri, 06 May 2005 13:56:05 +0100
From: Dr Stephen Henson <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
Subject: Re: RFC3280bis: policy processing.
Sender: [email-masked]

Stefan Santesson wrote:

> David,
> 
> Another aspect of this strikes me.
> 
> That is what happens when a policy mapping extension maps from one
> issuer domain policy to several subject domain policies.
> 
> The text in X.509 has noticed the need to duplicate the row (node in RFC
> 3280) for the issuer domain policy to accommodate both mappings.
> 
> Reading this corresponding text from RFC 3280 it seems that the
> corresponding creation of a new node is not specified in RFC 3280 which
> would result in the same node being overwritten twice with a new subject
> domain policy, resulting in a loss of the first mapping.
> 
> Unless I misread this, this seems to be a bug that we do need to fix.
> 

I believe this is the same issue (albeit from a different direction) I
queried before in this thread on 22 November last year.

Steve.

Date: Fri, 06 May 2005 08:52:56 -0400
From: "David A. Cooper" <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: RFC3280bis: policy processing.
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030500040500090801030508
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stefan Santesson wrote:

>David,
>
>Another aspect of this strikes me.
>
>That is what happens when a policy mapping extension maps from one
>issuer domain policy to several subject domain policies.
>
>The text in X.509 has noticed the need to duplicate the row (node in RFC
>3280) for the issuer domain policy to accommodate both mappings.
>
>Reading this corresponding text from RFC 3280 it seems that the
>corresponding creation of a new node is not specified in RFC 3280 which
>would result in the same node being overwritten twice with a new subject
>domain policy, resulting in a loss of the first mapping.
>
>Unless I misread this, this seems to be a bug that we do need to fix.
>  
>

Stefan,

In RFC 3280, this is addressed by maintaining, within a single node, the 
set of policies that appear as subject domain policies for a given 
issuerDomainPolicy (the expected_policy_set):

    6.1.4  Preparation for Certificate i+1

       To prepare for processing of certificate i+1, perform the following
       steps for certificate i:

          (b)  If a policy mappings extension is present, then for each
          issuerDomainPolicy ID-P in the policy mappings extension:

             (1)  If the policy_mapping variable is greater than 0, for each
             node in the valid_policy_tree of depth i where ID-P is the
             valid_policy, set expected_policy_set to the set of
             subjectDomainPolicy values that are specified as equivalent to
             ID-P by the policy mappings extension.

Take, for example figure 6 from RFC 3280:

                              +-----------------+
                              |      Red        |
                              +-----------------+
                              |       {}        |
                              +-----------------+ node of depth i-1
                              |  {Gold, Silver} |
                              +-----------------+
                                 /           \
                                /             \
                               /               \
                              /                 \
                +-----------------+          +-----------------+
                |      Gold       |          |     Silver      |
                +-----------------+          +-----------------+
                |       {}        |          |       {}        |
                +-----------------+ nodes of +-----------------+
                |     {Gold}      | depth i  |    {Silver}     |
                +-----------------+          +-----------------+

             Figure 6.  Processing unmatched policies when the certificate
             policies extension specifies anyPolicy

This subtree would be created as a result of:

_certificate i-1_:
certificatePolicies:  Red
policyMappings:
    issuerDomainPolicy: Red
    subjectDomainPolicy: Gold

    issuerDomainPolicy: Red
    subjectDomainPolicy: Silver
_
certificate i_:
certificatePolicies: Gold, Silver

Dave

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Stefan Santesson wrote:
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">David,

Another aspect of this strikes me.

That is what happens when a policy mapping extension maps from one
issuer domain policy to several subject domain policies.

The text in X.509 has noticed the need to duplicate the row (node in RFC
3280) for the issuer domain policy to accommodate both mappings.

Reading this corresponding text from RFC 3280 it seems that the
corresponding creation of a new node is not specified in RFC 3280 which
would result in the same node being overwritten twice with a new subject
domain policy, resulting in a loss of the first mapping.

Unless I misread this, this seems to be a bug that we do need to fix.
  </pre>
</blockquote>
<br>
Stefan,<br>
<br>
In RFC 3280, this is addressed by maintaining, within a single node,
the set of policies that appear as subject domain policies for a given
issuerDomainPolicy (the expected_policy_set):<br>
<blockquote><tt>6.1.4&nbsp; Preparation for Certificate i+1</tt><br>
  <br>
  <tt>&nbsp;&nbsp; To prepare for processing of certificate i+1, perform the
following</tt><br>
  <tt>&nbsp;&nbsp; steps for certificate i:</tt><br>
  <br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b)&nbsp; If a policy mappings extension is present, then for
each</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; issuerDomainPolicy ID-P in the policy mappings extension:</tt><br>
  <br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (1)&nbsp; If the policy_mapping variable is greater than 0,
for each</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; node in the valid_policy_tree of depth i where ID-P is
the</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; valid_policy, set expected_policy_set to the set of</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; subjectDomainPolicy values that are specified as
equivalent to</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ID-P by the policy mappings extension.</tt><br>
</blockquote>
Take, for example figure 6 from RFC 3280:<br>
<blockquote><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; +-----------------+</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Red&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+ node of depth i-1</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; {Gold, Silver} |</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gold&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Silver&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+ nodes of +-----------------+</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; {Gold}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | depth i&nbsp; |&nbsp;&nbsp;&nbsp; {Silver}&nbsp;&nbsp;&nbsp;&nbsp; |</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+</tt><br>
  <br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 6.&nbsp; Processing unmatched policies when the
certificate</tt><br>
  <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; policies extension specifies anyPolicy</tt><br>
</blockquote>
This subtree would be created as a result of:<br>
<br>
<u>certificate i-1</u>:<br>
<tt>certificatePolicies:&nbsp; Red<br>
policyMappings:<br>
&nbsp;&nbsp;&nbsp; issuerDomainPolicy: Red<br>
&nbsp;&nbsp;&nbsp; subjectDomainPolicy: Gold<br>
<br>
&nbsp;&nbsp;&nbsp; issuerDomainPolicy: Red<br>
&nbsp;&nbsp;&nbsp; subjectDomainPolicy: Silver</tt><br>
<u><br>
certificate i</u>:<br>
<tt>certificatePolicies: Gold, Silver</tt><br>
<br>
<br>
<br>
Dave<br>
</body>
</html>

--------------030500040500090801030508--

Content-class: urn:content-classes:message
Subject: RE: RFC3280bis: policy processing.
Date: Fri, 6 May 2005 09:38:06 +0100
From: "Stefan Santesson" <[email-masked]>
To: "David A. Cooper" <[email-masked]>, "Stephen Henson" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

David,

Another aspect of this strikes me.

That is what happens when a policy mapping extension maps from one
issuer domain policy to several subject domain policies.

The text in X.509 has noticed the need to duplicate the row (node in RFC
3280) for the issuer domain policy to accommodate both mappings.

Reading this corresponding text from RFC 3280 it seems that the
corresponding creation of a new node is not specified in RFC 3280 which
would result in the same node being overwritten twice with a new subject
domain policy, resulting in a loss of the first mapping.

Unless I misread this, this seems to be a bug that we do need to fix.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> On Behalf Of David A. Cooper
> Sent: den 4 maj 2005 21:20
> To: Stephen Henson
> Cc: pkix
> Subject: Re: RFC3280bis: policy processing.
> 
> Steve,
> 
> A few of the members of the design team spent some time reviewing the
> issue that you brought up below.  We agree that X.509 and RFC 3280
> differ as you describe and that in some circumstances the outputs of
the
> algorithms could differ.  However, we do not believe that the
> differences in the two algorithms will result in different outcomes in
> any realistic scenarios and so we do not believe that it is necessary
to
> change 3280bis to align with X.509.
> 
> An example of where X.509 and RFC 3280 could produce different results
> is shown in "X509vsRFC3280_policyMappings.pdf" (attached).  Pages 1
and
> 2 describe Certification Path 1 and the steps that would result from
> processing this certification path under X.509.  Under X.509 the
output
> consists of a authorities-constrained-policy-set of {1, 2} whereas
under
> RFC 3280 the authorities-constrained-policy-set would be {1}.  Note
> however, that the first certificate in the path include a
policyMappings
> extension that maps from policy 1 to policy 2.  So, the outcome of
path
> validation would effectively be the same in either case unless the
> user-initial-policy-set included the subjectDomainPolicy from the
policy
> mapping (2), but not the issuerDomainPolicy (1).  This seem unlikely.
> On page 3, Certification Path 2 demonstrates that RFC 3280 would get
the
> same result as X.509 if the first certificate in the certification
path
> explicitly asserted policy 2 in addition to asserting policy 1.
> 
> As shown in "MorePolicyMappingOddities.pdf", it turns out that a
number
> of unusual things can happen when the policyMappings extension is
> included in a certificate that also asserts anyPolicy.  These oddities
> occur in both X.509 and RFC 3280.  But, as before, they would only
> result in a different outcome for path validation if the
> user-initial-policy-set asserted a policy that appeared as a
> subjectDomainPolicy in the policyMappings extension but did not assert
> the corresponding issuerDomainPolicy.  So, while the results are
> unusual, it does not seem that it is necessary to make any changes to
> the algorithm.
> 
> Dave
> 
> Stephen Henson wrote:
> 
> > While I was checking the X509 policy processing against the RFC3280
> > version I've noticed what I believe to be a discrepancy between the
two.
> >
> > In RFC3280 the policy mapping processing is described in 6.1.4 b(1)
as:
> >
> >> (1)  If the policy_mapping variable is greater than 0, for each
node
> >> in the valid_policy_tree of depth i where ID-P is the valid_policy,
> >> set expected_policy_set to the set of subjectDomainPolicy values
that
> >> are specified as equivalent to ID-P by the policy mapping
extension.
> >>
> >> If no node of depth i in the valid_policy_tree has a valid_policy
of
> >> ID-P but there is a node of depth i with a valid_policy of
anyPolicy,
> >> then generate a child node of the node of depth i-1 that has a
> >> valid_policy of anyPolicy as follows:
> >
> > Whereas the corresponding text in X509 is in 10.5.2 d):
> >
> >> process any policy mappings extension by, for each mapping
identified
> >> in the extension, locate all rows in the
> >> authorities-constrained-policy-set table whose [path-depth] column
> >> entry is equal to the issuer domain policy value in the extension,
> >> and write the subject domain policy value from the extension in the
> >> [path-depth+1] column entry of the same row. If the extension maps
an
> >> issuer domain policy to more than one subject domain policy, then
the
> >> affected row must be copied and the new entry added to each row. If
> >> the value in authoritiesconstrained- policy-set[0, path-depth] is
> >> any-policy, then write each issuer domain policy identifier from
the
> >> policy mappings extension in the [path-depth] column, making
> >> duplicate rows as necessary and retaining qualifiers if they are
> >> present, and write the subject domain policy value from the
extension
> >> in the [pathdepth+ 1] column entry of the same row.
> >
> >
> > Translating this into RFC3280 terms it appears the processing of
> > anyPolicy is different.
> >
> > In RFC3280 a new node is added only if a node of depth i doesn't
exist
> > with a valid policy of ID-P.
> >
> > In X509 it appears to be saying a new node is added unconditionally.
> >
> > I believe this difference could result in different outputs from the
> > algorithm. In particular the X509 processing will (significantly)
> > result in nodes whose parent is anyPolicy which will not appear in
the
> > RFC3280 version.
> > Steve.

Date: Thu, 5 May 2005 00:10:26 -0700
To: "X.509":;
From: "Hoyt L. Kesterson II" <[email-masked]>
Subject: Defect reports against X.509
Sender: [email-masked]

<!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>Defect reports against X.509</title></head><body>
<div>Hello</div>
<div><br></div>
<div>I have posted two defect reports on the server</div>
<div><br></div>
<div>DR 310 -<font face="Geneva" color="#000000"> Unrecognized CRL and
CRL entry extensions</font></div>
<div>DR 311 -<font face="Geneva" color="#000000"> Differences between
crl and crl entry extensions</font></div>
<div><br></div>
<div>The DRs can be found at</div>
<div><br></div>
<div
>ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X<span
></span>.509andRelated/DR_310.pdf</div>
<div><br></div>
<div
>ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X<span
></span>.509andRelated/DR_311.pdf</div>
<div><br></div>
<div>I plan to submit these solutions in DTCs, within the next four
weeks, for formal voting in ISO. If there are any concerns about the
proposed solutions, please let me know as soon as possible so any
necessary modifications can be made before submitting for
ballot.</div>
<div><br></div>
<div>&nbsp;&nbsp; hoyt</div>
<div><br></div>
</body>
</html>

Reply-To: "Corrine Holley" <[email-masked]>
From: "Corrine Holley" <[email-masked]>
To: <[email-masked]>
Subject: In the site you can get cheep mads charon
Date: Wed, 04 May 2005 21:48:51 -0100

----PEMFH87531007MMVB
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit

Our site is all about high quallity cheep-pr1ce errection meddicatioons.
If you want it, we can give it to you. Bast and cheepest mads available
in our online site. 
you won't stop screewing after you use it, for sure :)

Come to see by yourself:
http://longue.felsjkdbm.com/?GLcZcbGiqKhuSaGmanuel

society for historical archaeology website contains links to contents of monographs papers and the journal australasian journal of historical archaeology and complete issues of the.
from nick greene your guide to space and astronomy a new e-mail course on developing science fair projects great science fair pr ojects.
the main new feature is the ability to add delete and edit multiple templates in manila using only your web browser and your brain.
this is very interesting there are more and more manila sites created by net developers here s.
information and up-to-date programs of the frankfurt opera frankfurt ballet and tat theater am turm.
in today s fast-paced world the south pacific hotel has everything for the discerning traveler located right next to wide variety of shopping dining and entertainment in popular causeway bay.
and so we began discussing the compound bow s wheels and cams and it was very clear we have very diffrent opinions on the subject.
information on mail order sources of palms and information on the hardy palm international a publication of the pacific northwest palm and exotic plant society.
let the car guys offer up their knowledge on collectibles news and information car care and more.
ever since we ve had more than one site i ve always wanted to have a structure that all our sites are linked into.
manchild - eels the warmth - incubus no woman no cry - spunge learning how to smile - everclear or american dream - dustfly.
battlefield archaeology is a relatively american phenomenon but there are some pretty interesting battlefield sites to visit around the world here is a short selection.
brings you products that will enhance your lifestyle with exercise weight loss and whiter teeth.

----PEMFH87531007MMVB--

Date: Wed, 04 May 2005 16:56:52 -0400
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: name constraints on uniformResourceIdentifiers in 3280bis
Sender: [email-masked]

All,

The new text in section 4.2.1.10 (Name Constraints) of 3280bis for 
imposing name constraints on URIs was added based on comments from some 
of the members of the design team.  After further consideration, most of 
the members of the design team decided that the additional flexibility 
provided by the proposed new rules were not absolutely necessary and 
that adding this additional flexibility could cause problems for 
existing clients.

So, unless there are objections from the working group, the -01 draft of 
3280bis will revert to the RFC 3280 rules for name constraints on URIs.  
(The -01 draft will still require that internationalized domain names be 
compared as specified in section 7 of 3280bis).

Dave

David A. Cooper wrote:

> 3280bis disposition of comments:
>
> 21) There is a need to be able to specify name constraints for URIs 
> that limit schemes that may be specified.
>
>   3280bis includes an extended set of rules for specifying name
>   constraints on URIs.

Date: Wed, 04 May 2005 15:20:17 -0400
From: "David A. Cooper" <[email-masked]>
To: Stephen Henson <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: RFC3280bis: policy processing.
Sender: [email-masked]

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

Steve,

A few of the members of the design team spent some time reviewing the 
issue that you brought up below.  We agree that X.509 and RFC 3280 
differ as you describe and that in some circumstances the outputs of the 
algorithms could differ.  However, we do not believe that the 
differences in the two algorithms will result in different outcomes in 
any realistic scenarios and so we do not believe that it is necessary to 
change 3280bis to align with X.509.

An example of where X.509 and RFC 3280 could produce different results 
is shown in "X509vsRFC3280_policyMappings.pdf" (attached).  Pages 1 and 
2 describe Certification Path 1 and the steps that would result from 
processing this certification path under X.509.  Under X.509 the output 
consists of a authorities-constrained-policy-set of {1, 2} whereas under 
RFC 3280 the authorities-constrained-policy-set would be {1}.  Note 
however, that the first certificate in the path include a policyMappings 
extension that maps from policy 1 to policy 2.  So, the outcome of path 
validation would effectively be the same in either case unless the 
user-initial-policy-set included the subjectDomainPolicy from the policy 
mapping (2), but not the issuerDomainPolicy (1).  This seem unlikely.  
On page 3, Certification Path 2 demonstrates that RFC 3280 would get the 
same result as X.509 if the first certificate in the certification path 
explicitly asserted policy 2 in addition to asserting policy 1.

As shown in "MorePolicyMappingOddities.pdf", it turns out that a number 
of unusual things can happen when the policyMappings extension is 
included in a certificate that also asserts anyPolicy.  These oddities 
occur in both X.509 and RFC 3280.  But, as before, they would only 
result in a different outcome for path validation if the 
user-initial-policy-set asserted a policy that appeared as a 
subjectDomainPolicy in the policyMappings extension but did not assert 
the corresponding issuerDomainPolicy.  So, while the results are 
unusual, it does not seem that it is necessary to make any changes to 
the algorithm.

Dave

Stephen Henson wrote:

> While I was checking the X509 policy processing against the RFC3280
> version I've noticed what I believe to be a discrepancy between the two.
>
> In RFC3280 the policy mapping processing is described in 6.1.4 b(1) as:
>
>> (1)  If the policy_mapping variable is greater than 0, for each node
>> in the valid_policy_tree of depth i where ID-P is the valid_policy,
>> set expected_policy_set to the set of subjectDomainPolicy values that
>> are specified as equivalent to ID-P by the policy mapping extension.
>>
>> If no node of depth i in the valid_policy_tree has a valid_policy of
>> ID-P but there is a node of depth i with a valid_policy of anyPolicy,
>> then generate a child node of the node of depth i-1 that has a
>> valid_policy of anyPolicy as follows:
>
> Whereas the corresponding text in X509 is in 10.5.2 d):
>
>> process any policy mappings extension by, for each mapping identified
>> in the extension, locate all rows in the 
>> authorities-constrained-policy-set table whose [path-depth] column
>> entry is equal to the issuer domain policy value in the extension,
>> and write the subject domain policy value from the extension in the
>> [path-depth+1] column entry of the same row. If the extension maps an
>> issuer domain policy to more than one subject domain policy, then the
>> affected row must be copied and the new entry added to each row. If
>> the value in authoritiesconstrained- policy-set[0, path-depth] is
>> any-policy, then write each issuer domain policy identifier from the 
>> policy mappings extension in the [path-depth] column, making
>> duplicate rows as necessary and retaining qualifiers if they are
>> present, and write the subject domain policy value from the extension
>> in the [pathdepth+ 1] column entry of the same row.
>
>
> Translating this into RFC3280 terms it appears the processing of 
> anyPolicy is different.
>
> In RFC3280 a new node is added only if a node of depth i doesn't exist 
> with a valid policy of ID-P.
>
> In X509 it appears to be saying a new node is added unconditionally.
>
> I believe this difference could result in different outputs from the 
> algorithm. In particular the X509 processing will (significantly) 
> result in nodes whose parent is anyPolicy which will not appear in the 
> RFC3280 version.
>
> Steve.

--------------010400010004030801000000
Content-Type: application/pdf;
 name="X509vsRFC3280_policyMappings.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="X509vsRFC3280_policyMappings.pdf"

--------------010400010004030801000000
Content-Type: application/pdf;
 name="MorePolicyMappingOddities.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="MorePolicyMappingOddities.pdf"

--------------010400010004030801000000--

Date: Wed, 04 May 2005 10:48:26 -0400
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Disposition of Comments for 3280bis
Sender: [email-masked]

All,

Here is the disposition of comments for 3280bis 
(http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-00.txt).  
There is a Diff file on the NIST Web site at 
http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html 
that highlights the differences between RFC 3280 and draft -00 of 3280bis.

If you submitted a comment and do not believe that it was addressed in 
the disposition of comments below, please let me know and I will look 
into it.  Please note, however, that draft -00 of 3280bis was originally 
submitted on February 13 and that the disposition of comments is based 
on comments that were submitted in late 2004 (or earlier).  A few 
comments have been sent to the PKIX list about 3280bis since 
mid-February.  These comments are not addressed in 3280bis-00 or in the 
notes below, but will be considered before draft -01 of 3280bis is 
submitted.

Thanks,

Dave

-----------------------------------------------------------------------------------------------------
3280bis disposition of comments:

1) There is confusion about the use of the term "CRL issuer" in RFC 3280.

   In section 3, the explanation of the "CRL issuer" component of Figure 1
   has been modified as has the description of "CRL issuer" in section 5.
   Both note that the CRL issuer is either the CA or an entity that has
   been delegated the responsibility for issuing CRLs by the CA.

2) There is confusion about whether a CA is identified by its name alone 
or by a combination of name and key pair.  The confusion mainly focused 
on the scope of CRLs.

   Section 5 of 3280bis includes the following:

   A full and complete CRL lists all unexpired certificates issued by a CA
   that have been revoked for any reason.  (Note that since CAs and CRL
   issuers are identified by name, the scope of a CRL is not affected by
   the key used to sign the CRL or the key(s) used to sign certificates.)

3) RFC 3280 states that all certificates issued after December 31, 2003 
MUST use the UTF8String encoding of DirectoryString, with some exceptions.

   3280bis states that either the PrintableString or UTF8String encoding
   of DirectoryString MUST be used, except for previously established
   names that use a different encoding.

4) 3280bis should incorporate the rules for encoding and comparing 
internationalized name forms.

   A new section 7 has been added which covers comparing directoryNames
   using the rules from LDAP StringPrep.  Section 7 also covers the
   encoding and comparison of internationalized domain names and
   Internationalized Resource Identifiers.

5) There are problems with text in RFC 3280 regarding "name rollover" 
certificates to support an orderly migration to UTF8String

   The text about "name rollover" certificates has been deleted.

6) For validity dates, RFC 3280 imposes generation requirements for CAs 
but does not include requirements for relying parties

   3280bis says: "Conforming applications MUST be able to process validity
   dates that are encoded in either UTCTime or GeneralizedTime."  This
   applies to the thisUpdate and nextUpdate fields of CRLs as well.

7) RFC 3280 states that applications should be capable of processing 
unique identifiers, but it is not clear what, if any, processing 
requirements there are.

   3280bis explicitly states that there are no processing requirements
   associated with unique identifiers.

8) The meaning of critical vs. non-critical certificate extension should 
be clarified.

   3280 bis states:  "A certificate using system MUST reject the
   certificate if it encounters a critical extension it does not
   recognize or a critical extension that contains information that it
   can not process.  A non-critical extension MAY be ignored if it is not
   recognized, but MUST be processed if it is recognized."

9) RFC 3280 states that conforming applications must be able to process 
the name constraints extension, but does not specify which name forms 
must be supported.

   3280bis states that conforming applications MUST be able to process
   name constraints for directoryName and SHOULD be able to process name
   constraints for rfc822Name, uniformResourceIdentifier, dNSName, and
   iPAddress.  3280bis further states that conforming CAs MUST NOT impose
   name constraints on the x400Address, ediPartyName, or registeredID
   name forms.

10) RFC 3280 states that conforming applications SHOULD support the 
policyMappings extension and MUST support the policyConstraints 
extension.  It seems inappropriate to require support for the 
inhibitPolicyMapping field of policyConstraints without requiring 
support for the policyMappings extension.

   3280bis states that conforming applications MUST support the
   requireExplicitPolicy field of policyConstraints and SHOULD support
   the inhibitPolicyMapping field of policyConstraints.  3280bis further
   states that applications that support the inhibitPolicyMapping field
   of policyConstraints MUST also support the policyMappings field.
   3280bis also requires CAs to mark this policyConstraints as critical.

11) 3280bis should clearly explain that there is no requirement as part 
of path validation that authorityKeyIdentifiers and 
subjectKeyIdentifiers match.

   Section 4.2.1.2 (Subject Key Identifier) now says: "Applications are
   not required to verify that key identifiers match when performing
   certification path validation."  The requirement for issuing CAs to
   place matching key identifiers in the certificates that they issue is
   still present.

12) RFC 3280 states that one common method for generating key 
identifiers is a monotonically increasing sequence number. Shouldn't key 
identifiers be globally unique (or at least shouldn't one try to avoid 
collisions).

   The phrase "One common method for generating unique values is a
   monotonically increasing sequence of integers." has be replaced with
   "Other methods of generating unique numbers are also acceptable."

13) The descriptions of the meanings of the digitalSignature and 
nonRepudiation bits of keyUsage may need to be adjusted based on the 
work in X.509

   The new text in X.509 aligns with the text in RFC 3280.  No changes
   are required to 3280bis.  A comment has been added to the ASN.1 for
   KeyUsage stating that "recent editions of X.509 have renamed
   [the nonRepudiation] bit to contentCommitment"

14) 3280bis should note that there may be security issues associated 
with setting both the digitalSignature and nonRepudiation bits in a 
certificate.

   A sentence was added to section 4.2.1.3 (Key Usage) stating:
   "Combining the nonRepudiation bit in the keyUsage certificate
   extension with other keyUsage bits may have security implications
   depending on the context in which the certificate is to be used."

15) RFC 3280 states that the privateKeyUsagePeriod extension "SHOULD NOT 
be used within the Internet PKI."  3280bis should to changed to state 
that this may MAY be used.

   The contents of the section describing the privateKeyUsagePeriod
   extension were not changed but were moved to appendix D, a new
   appendix for listing extensions that are outside the scope of the
   profile.

16) 3280bis should state that a certificate policy OID may appear at 
most once in a certificatePolicies extension.

   A sentence was added to the first paragraph of section 4.2.1.4
   (Certificate Policies) stating this.

17) RFC 3280 states "The application software SHOULD display all user 
notices in all certificates of the certification path used, except that 
if a notice is duplicated only one copy need be displayed."  This is 
inconsistent with section 6, which specifies that only those user 
notices associated with policies that appear in every certificate in the 
path (either directly or through mapping) are returned to the 
application for display.

   Section 4.2.1.4 (Certificate Policies) states that only those user
   notices that are returned as a result of path validation are intended
   for display to the user.  It is also noted that this applies to any
   other policy qualifiers.

18) The user notice qualifier makes use of DisplayText, which is a 
CHOICE of four different string encoding options.  Unlike with 
DirectoryString in the issuer and subject fields, RFC 3280 provides no 
guidance on which encodings to use.

   3280bis states: "Conforming CAs SHOULD use the UTF8String encoding for
   explicitText, but MAY use IA5String.  Conforming CAs MUST NOT encode
   explicitText as VisibleString or BMPString."

19) For the policyMappings extension, RFC 3280 states that policies 
SHOULD NOT be mapped to or from anyPolicy, but section 6 states that 
relying parties MUST reject any certificate that includes a 
policyMappings extension that maps to or from anyPolicy.

   Section 4.2.1.5 (Policy Mappings) of 3280bis states that policies MUST
   not be mapped to or from anyPolicy.

20) RFC 3280 states that the policyMappings extension MUST be marked 
non-critical, however given the processing semantics for this extension 
it may be appropriate to mark the extension critical.  X.509 allows for 
the extension to be marked either critical or non-critical.

   3280bis states that the policyMappings extensions SHOULD be marked
   critical.

21) There is a need to be able to specify name constraints for URIs that 
limit schemes that may be specified.

   3280bis includes an extended set of rules for specifying name
   constraints on URIs.

22) The rules for specifying name constraints on DNS names are unclear. 
Does "myexample.com" satisfy a constraint of "example.com"?

   3280bis states that "DNS name restrictions are expressed as
   host.example.com.  Any DNS name that can be constructed by simply
   adding subdomains to the left hand side of the name satisfies the
   name constraint."

23) 3280bis should clearly state the rules for processing a name 
constraints extension that specifies constraints on name forms that an 
application is unable to process.

   3280bis states that if a critical name constraints extension specifies
   a constraint for a name form and a name of that name form appears in a
   subsequent certificate, then the application must either process the
   constraint or reject the certificate.

24) 3280bis needs to provide more information about the use of URIs in 
the cRLDistributionPoints extension.

   3280bis provides information about HTTP and LDAP URIs.  It indicates
   that an HTTP URI MUST point to a file containing a DER encoded CRL.
   It also provides rules for the format of an LDAP URI.

25)  RFC 3280 states that when a distribution point name in a 
cRLDistributionPoints extension is specified as a URI, the URI MUST 
include a fully qualified domain name or IP address as the host.  
3280bis should allow for the use of LDAP URIs that do not specify a host 
name.

   3280bis removes this requirement by no longer specifying that the
   encoding rules specified for URIs in the subjectAltName extension
   apply to the cRLDistributionPoints extension.  3280bis also explicitly
   states that the host name is optional in LDAP URIs in the
   cRLDistributionPoints extension.

26) RFC 3280 states that if the cRLIssuer field is present in 
cRLDistributionPoints, it MUST contain at least one X.500 DN.  3280bis 
should state that this DN must be the DN from the issuer field of the 
referenced CRL.

   3280bis states that the cRLIssuer field MUST only contain the DN from
   the issuer field of the referenced CRL and that the DN MUST be encoded
   identically in both places.

27) 3280bis should deprecate segmented CRLs by reason code.

   3280bis RECOMMENDS against segmenting CRLs by reason code and
   requires that certificates that include a cRLDistributionPoints
   extension MUST include at least one distribution point that points
   to a CRL that covers the certificate for all reasons.

28) RFC 3280 states that for the id-ad-caIssuers assess method of 
authorityInfoAccess and the id-ad-caRepository access method of 
subjectInfoAccess when the accessLocation is a directoryName the 
information is to be obtained using DAP.  This is inconsistent with the 
cRLDistributionPoints extension where the protocol used to obtain the 
information is not defined by the standard but is instead considered to 
be a local matter.

   3280bis states that for the authorityInfoAccess and subjectInfoAccess
   extensions that when accessLocation is a directoryName the protocol
   used to obtain the information from the directory is a local matter.

29) RFC 3280 states that for the id-ad-caIssuers assess method of 
authorityInfoAccess and the id-ad-caRepository access method of 
subjectInfoAccess the access location may be an http, ftp, or ldap URI 
or an rfc822Name but no information is provided on the format of the 
URIs or the format of the data that will be retrieved using these access 
methods.

   3280bis specifies the format for LDAP URIs and specifies that FTP and
   HTTP URIs must point to files that contain either certificates or
   certs-only CMS messages.  The use of rfc822Name as in accessLocation
   is not mentioned.

30) For the cRLDistributionPoints extension, RFC 3280 clearly states 
that if a single distribution point contains multiple distribution point 
names that each distribution point name describes a different mechanism 
for obtaining the same CRL, whereas distribution point names that appear 
in different distribution points may point to different CRLs.  What is 
the rule for the authorityInfoAccess and subjectInfoAccess extensions?  
If an AIA extension includes more than one instance of the 
id-ad-caIssuers access method, does each instance provide a different 
mechanism for obtaining the same information or could different 
instances of the access method point to different information.

   3280bis states that different instances of the access method may
   specify different methods for accessing the same information or may
   point to different information.

31) RFC 3280 states:  "Although the [issuingDistributionPoint] extension 
is critical, conforming implementations are not required to support this 
extension."  Some people have interpreted this to mean that 
implementations that are unable to process the extension may ignore it 
even though it is marked critical.

   The following sentence has bee added to 3280bis:  "However,
   implementations that do not support this extension MUST either treat
   the status of any certificate not listed on this CRL as unknown or
   locate another CRL that does not contain any unrecognized critical
   extensions."

32) In X.509, there is a proposal to revert to the original version of 
the issuingDistributionPoint extension, which did not include the 
onlyContainsAttributeCerts field, and a new extension has been proposed 
for attribute certificates. [Note: The design team was unable to verify 
whether this proposal has been approved in X.509]

   The design team decided to continue to use the ASN.1 from RFC 3280 for
   the issuingDistributionPoint extension.  However, the text now
   explicitly states that the onlyContainsAttributeCerts field MUST be
   set to FALSE, since 3280bis only covers public key certificates.
   When onlyContainsAttributeCerts is set to FALSE, the DER encoding
   and semantics of the issuingDistributionPoint extension are the same
   as if the onlyContainsAttributeCerts were not present.

33) The certificateIssuer CRL entry extension contains a GeneralNames.  
While RFC 3280 does not state this, there seems to be general agreement 
that the certificateIssuer extension should only contain the DN from the 
issuer field of the certificate being revoked.

   3280bis states: "Conforming CRL issuers MUST include in [the
   certificateIssuer] extension the distinguished name (DN) from the
   issuer field of the certificate that corresponds to this CRL entry.
   The encoding of the DN MUST be identical to the encoding used in the
   certificate."

34) X.509 states that a certificate may not appear in a certification 
path more than once.  3280bis should impose the same restriction.

   Section 6.1 of 3280bis states that a certificate MUST NOT appear more
   than once in a prospective certification path.

35) The path validation algorithm should indicate how to perform 
validations for times other than the current time.

   Adding information about how to perform validations for some time
   other than the current time was considered to be outside the scope
   of changes that could be made in 3280bis.

36) The criticality_indicator variable in the nodes of the 
valid_policy_tree seems to have no application in the algorithm and so 
it should be removed.

   The criticality_indicator variable has been removed from the nodes of
   the valid_policy_tree.

37) Section 6.1.2 of RFC 3280 specifies the initial values for the state 
variables.  Can these variables be set to different initial values in 
order to impose additional constraints?

   Section 6.2 of RFC 3280 already states that this is permitted.
   Section 6.2 of 3280bis includes additional text referring to the
   possibility of using certificate extensions from self-signed
   certificates to set these initial values.

38) Section 6.1.4 of RFC 3280 states that one must verify that 
intermediate certificates are CA certificates using either the contents 
of the basicConstraints extension or out-of-band means.  X.509 states 
that a version 3 certificate that does not include a basicConstraints 
extension must not be considered a CA certificate.

   3280bis states that for a version 3 intermediate certificate the
   basicConstraints extension must be present with cA set to TRUE.
   Conforming applications may either reject all version 1 and version 2
   intermediate certificates or may use out-of-band means to verify that
   they are CA certificates.

39)  In section 6.1.5, RFC 3280 states that the explicit_policy variable 
is only decremented if the final certificate in the certification path 
is not self-issued.  In X.509, the final certificate in a certification 
path is treated the same way whether it is self-issued or not.

   In order to make 3280bis consistent with X.509, 3280bis has been
   changed to state that the explicit_policy variable is always
   decremented as part of the wrap-up step, whether the final
   certificate is self-issued or not.

40) Section 6.3 of RFC 3280 states: "Conforming implementations that 
support CRLs are not required to implement this algorithm, but they MUST 
be functionally equivalent to the external behavior resulting from this 
procedure."  This should be clarified.  For example, the CRL validation 
algorithm in RFC 3280 will only validate a delta-CRL if it was signed 
using the same key as the corresponding complete CRL.  While RFC 3280 
requires CRL issuers to sign delta-CRLs using the same key as the key 
used to sign the corresponding base CRL, this is not an X.509 
requirement.  Conforming implementations should be permitted to accept 
delta-CRLs that were signed using a different key even though they are 
not required to be able to do so.

   3280bis has replaced the referenced sentence with: "Conforming
   implementations that support CRLs are not required to implement this
   algorithm, but they MUST be functionally equivalent to the external
   behavior resulting from this procedure when processing CRLs that are
   issued in conformance with this profile."

41) Section 6.3.1 of RFC 3280 states: "Note that implementations 
supporting legacy PKIs, such as RFC 1422 and X.509 version 1, will need 
an additional input indicating whether the supplied certificate is 
associated with a CA or an end entity."  What is the reason for this 
statement?  The only reason that one might need to know whether a 
certificate is a CA certificate or end entity certificate when 
validating a CRL is if the CRL includes an issuingDistributionPoint 
extension with onlyContainsUserCerts or onlyContainsCACerts set to 
TRUE.  But, when one of these is set, the algorithm in section 6.3.3 
relies on the basicConstraints extension to determine the type of 
certificate.

   The sentence quoted above has been deleted.  Section 5.2.5 (Issuing
   Distribution Point) of 3280bis now states: "If either
   onlyContainsUserCerts or onlyContainsCACerts is set to TRUE then the
   scope of the CRL MUST NOT include any version 1 or version 2
   certificates."

42) There seems to be two problems with the algorithm in section 6.3.3 
when CRLs are segmented by reason code.  The algorithm defines a value 
all-reasons that is the set of reason codes from the CRLReason type.  
The algorithm continues until CRLs are located that cover all of the 
reasons in all-reasons.  If a CRL cannot be located that covers one or 
more of the reasons in all-reasons, then the algorithm fails.  But, the 
set of reasons covered by a CRL is specified using the ReasonFlags bit 
string.  In ReasonFlags, however, "unspecified" is replaced by 
"unused".  So, the algorithm will never complete successfully when CRLs 
are segmented by reason since no CRL can specify that it covers the 
"unspecified" reason code.  It is also not clear on which CRL to include 
certificates that have been revoked with a reason code of unspecified.

   In 3280bis, "unspecified" has been removed from all-reasons.  In
   addition, section 5.2.5 (Issuing Distribution Point) of 3280bis
   states that if a CRL includes an issuingDistributionPoint extension
   with onlySomeReasons present then every certificate in the scope of
   that CRL that is revoked must be assigned a revocation reason other
   than unspecified.

43) It should be noted in 3280bis that there is a risk that two 
different CAs (or a CA and a CRL issuer) may issue certificates and CRLs 
under the same name and that if this happens there is a risk that a 
relying party will validate a certificate issued by one of these 
entities using a CRL issued by the other.

   The security considerations section of 3280bis states that CAs and CRL
   issuers should be formed in a way that reduces the likelihood of name
   collisions.  It also states that implementations validating CRLs MUST
   ensure that the certification path of the target certificate and the
   CRL issuer certification path used to validate the target certificate
   terminate at the same trust anchor.

44) The text from RFC 2510 on root key update should be included in 3280bis.

   The security considerations section of 3280bis includes a pointer to
   RFC 2510.

From: "Shirley Marin" <[email-masked]>
To: <Owner-ietf-fax>
Subject: FW: impressive carttier repliccas esp. for you cosmetic
Date: Tue, 03 May 2005 04:57:19 -0700

----bpcywcmx93210mcgiyeldz
Content-Type: text/plain;
Content-Transfer-Encoding: 7Bit

Now presenting:
You know you've allways wanted it - watchees: elegent, fancy, impressive repliccas!
You can impress you're lady/man with:
roleex (including vip roleex), carttier, braitling, bulgari and much much more...
The bast brand s in the world! 
Just naame it - We got it :)

hmmmmm i just can't wait :)
http://couldn't.hiltiimfj.com/?6oE88HDKSadeBCCalder

would like to build one heck of a sleeper to shut up some car owners who think that theirs is unbeatable!
might make a good manager for it that club is almost certainly arizona for which melvin had been bench coach under bob brenly who was fired as manager earlier this season.
artists and record labels from all over the world can now sell their music directly in digital format.
do you have an awesome poster of the tipi s available? for those of us who a re still tryin to make it to crow.
you really are multi-faceted dan your comic is well drawn and intriguing so you re my first link! keep it going.
nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp all the girls i know.
which lists a cool or inventive or new robots of interest for you with easy links one for every week go check it out!
son mike ford leicester city devices town - non-league cardiff city oxford united cardiff city oxford united - player manager thame utd - non didcot town brackley town - player coach.
half truths at best but most absolute lies is what the state of texas depended on to convict me and sentence me to death by lethal injection.
very interesting site its so stimulating to view different sites and their content and designs.
well youre more than wecome like i said u do good work here i enjoy dropping in to see whats going on its like takinga trip but never really leaving ya know? congrats again!
what can i say? you ve probably heard enough praise already? although your site really is very good keep up the good work!
old stories and sorta-local and state stories it will also bring up amazon s bestseller list for that zipcode for the area i grew up in which used to vote republican.
for information on antioxidant levels in fruits and vegetables see the u s department of agriculture.
on returning from the debauched break last week and immediately found themselves in hot water with the mother-superior.

----bpcywcmx93210mcgiyeldz--

From: "Kazin, Joel" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: SP 800 57 Part II
Date: Mon, 2 May 2005 13:27:44 -0500 
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.

------_=_NextPart_001_01C54F44.6CDCAB7E
Content-Type: text/plain;
	charset="iso-8859-1"

The draft document beginning in section 3.2.1.1 makes several references to 
the RFC 2527 framework. While I agree with the general approach in the 
draft, RFC 2527 is obsolete having been superceded by RFC 3647 in November 
of 2003.  While the content of the framework of RFC 2527 was not greatly 
changed by RFC 3647, the organization was. There is a useful set of 
cross-references between the two frameworks at the back of RFC 3647.

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com

------_=_NextPart_001_01C54F44.6CDCAB7E
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2611.0">
<TITLE>SP 800 57 Part II</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>The draft document beginning in section 3.2.1.1 makes several references to </FONT>
<BR><FONT SIZE=2>the RFC 2527 framework. While I agree with the general approach in the </FONT>
<BR><FONT SIZE=2>draft, RFC 2527 is obsolete having been superceded by RFC 3647 in November </FONT>
<BR><FONT SIZE=2>of 2003.&nbsp; While the content of the framework of RFC 2527 was not greatly </FONT>
<BR><FONT SIZE=2>changed by RFC 3647, the organization was. There is a useful set of </FONT>
<BR><FONT SIZE=2>cross-references between the two frameworks at the back of RFC 3647.</FONT>
</P>
<BR>

<P><FONT SIZE=2>Joel S. Kazin CPA, CISA, CISSP, CISM</FONT>
<BR><FONT SIZE=2>Senior Consultant</FONT>
<BR><FONT SIZE=2>Atos Origin</FONT>
<BR><FONT SIZE=2>40 Old Sleepy Hollow Road</FONT>
<BR><FONT SIZE=2>Pleasantville, New York 10570-3802</FONT>
<BR><FONT SIZE=2>USA</FONT>
<BR><FONT SIZE=2>Phone&nbsp; +1 914-769-8780</FONT>
<BR><FONT SIZE=2>Mobile&nbsp; +1 914-564-1484</FONT>
<BR><FONT SIZE=2>email&nbsp;&nbsp;&nbsp; [email-masked]</FONT>
<BR><FONT SIZE=2>www.atosorigin.com</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C54F44.6CDCAB7E--