Subject: Browser trust models & Smart cards

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 3 Sep 2006 15:51:56 +0200

Dear list;

Regarding the trust model for client-based PKI operations, I am a bit puzzled concerning how this should work in browsers.

Mozilla Firefox requires that an EE certificate CA is known and marked as "trusted" in order to perform private key operations.  IMHO, this requirement is unnecessary, particularly for TLS-client-authentication and on-line signatures (signText), because in these use-cases there are no trust issues on the client-side except for TLS server-certificates.  This requirement also limits mobility for smart card users.  There are to my knowledge few if any smart card standards requiring complete certificate-paths to be stored in the card.

As a comparison you could take credit-cards; it is important that end-users recognize the brand (and possibly some user-related data as well), but there is no need to carry around any card issuer documents, because card verification is only performed by relying parties (merchants, banks etc.).

I would be interested to know how this is handled by other PKI-enabled clients.  AFAIK, such [small but vital] details are not only outside of standards like TLS, but you can hardly get your hands on any vendor documentation either, because the running code seems currently to be the actual specification :-(

Comments?

Anders Rundgren

---

From: "Santoni Adriano" <[email-masked]>
Date: Mon, 11 Sep 2006 09:45:15 +0200

I fully agree with Anders.
 
Btw, Mozilla and its descendants do a number of weird things with
certificates, not only the one described below.
 
For instance, it rejects digital signature certificates as they were
unknown beasts. I mean, certificates with a critical KeyUsage extension
with the "nonRepudiation" bit raised. If you want to use the signText()
function with a qualified certificate, in Mozilla/Firefox, you're out of
luck. Why so? Nobody seems to know or care.
 
Adriano

________________________________

Da: [email-masked] [mailto:[email-masked]]
Per conto di Anders Rundgren
Inviato: domenica 3 settembre 2006 15.52
A: [email-masked]
Oggetto: Browser trust models & Smart cards

Dear list;
 
Regarding the trust model for client-based PKI operations, I am a bit
puzzled concerning how this should work in browsers.

Mozilla Firefox requires that an EE certificate CA is known and marked
as "trusted" in order to perform private key operations.  IMHO, this
requirement is unnecessary, particularly for TLS-client-authentication
and on-line signatures (signText), because in these use-cases there are
no trust issues on the client-side except for TLS server-certificates.
This requirement also limits mobility for smart card users.  There are
to my knowledge few if any smart card standards requiring complete
certificate-paths to be stored in the card.

As a comparison you could take credit-cards; it is important that
end-users recognize the brand (and possibly some user-related data as
well), but there is no need to carry around any card issuer documents,
because card verification is only performed by relying parties
(merchants, banks etc.).

I would be interested to know how this is handled by other PKI-enabled
clients.  AFAIK, such [small but vital] details are not only outside of
standards like TLS, but you can hardly get your hands on any vendor
documentation either, because the running code seems currently to be the
actual specification :-(

Comments?

Anders Rundgren

*******************Internet Email Confidentiality Footer*******************

Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei suoi allegati e 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.

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 12 Sep 2006 18:11:53 +0200

Adriano,

I believe that the best answer to your highly valid question is that IETF standards like TLS-client-authentication and S/MIME leave quite a bit to implementers to decide.  To not get completely wrong, implementers typically test their software with a few [what they perceive as] "normative" PKIs.  Since we (the PKI community), have not decided if a specific issuance should use one, two, or three certificates including associated KeyUsage specifiers, KeyUsage has become a source of rather tricky interoperability issues.   "The cult of the NR bit" has in turn brought considerable confusion to the table as well.  Since nobody is likely to ever convince the world including vendors that these things should be in a certain way, a "wannabe" standard for web-form-signing coined WASP (Web Activated Signature Protocol), makes certificate selection a thing for the relying party to have an opinion about, rather than the client software.  This is natural in on-line schemes.  What the default KeyUsage should be I guess will still be an implementers choice :-(   But this has little importance since the relying party has a pretty decent range of optional certificate selection parameters at his/her disposal if the default(s) does not work:

<xs:element name="CertificateFilter" minOccurs="0">
<xs:complexType>
At least one of the following attributes MUST be specified.

"Global" (cert-path-wide) signer certificate selection attributes.
<xs:attribute name="Sha1" type="wasp:sha1Hash" use="optional"/>
<xs:attribute name="Issuer" type="wasp:distinguishedNameExpr" use="optional"/>
"Local" selection attributes that only apply to signature (EE) certificates.
<xs:attribute name="Subject" type="wasp:distinguishedNameExpr" use="optional"/>
<xs:attribute name="Serial" type="xs:integer" use="optional"/>
<xs:attribute name="Policy" type="wasp:oidURI" use="optional"/>
<xs:attribute name="Containers" type="wasp:containerList" use="optional"/>
<xs:attribute name="KeyUsage" type="wasp:keyUsageBits" use="optional"/>
<xs:attribute name="ExtKeyUsage" type="wasp:oidURI" use="optional"/>

</xs:complexType>
</xs:element>

It appears that the combination of KeyUsage and Policy should be a nice fit for many PKIs rather than using TLS-like issuer filtering since the latter requires knowledge of participating "scheme" sub-CAs that the relying party may not have (jn advance).

If a relying party accepts multiple independent issuers and trust networks, a set of certificate filter objects can [presumably] still cope with the lack of standardization in this space.

Regarding the trust model however, it is clear that there should be no requirements for anything but EE certificates, although the relying party may request that signature packets should contain as much of the certificate path that is locally known.

regards
Anders

----- Original Message ----- 
From: Santoni Adriano 
To: [email-masked] 
Sent: Monday, September 11, 2006 09:45
Subject: R: Browser trust models & Smart cards

Btw, Mozilla and its descendants do a number of weird things with certificates, not only the one described below.

For instance, it rejects digital signature certificates as they were unknown beasts. I mean, certificates with a critical KeyUsage extension with the "nonRepudiation" bit raised. If you want to use the signText() function with a qualified certificate, in Mozilla/Firefox, you're out of luck. Why so? Nobody seems to know or care.

Adriano

--------------------------------------------------------------------------------
Da: [email-masked] [mailto:[email-masked]] Per conto di Anders Rundgren
Inviato: domenica 3 settembre 2006 15.52
A: [email-masked]
Oggetto: Browser trust models & Smart cards

Dear list;

Comments?

Anders Rundgren

Qualsiasi utilizzo non autorizzato del presente messaggio nonche dei suoi allegati e 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.

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 15 Sep 2006 09:43:59 +0200

> I fully agree with Anders.
[...]
> luck. Why so? Nobody seems to know or care.

This is usually the case when *BAD* CA practice force the presence of
critical extensions on very specific profiles. This is sometimes the case
of some CAs that follow national signature laws... anyway have you submitted
the bug/feature request to the Mozilla developers (bugzilla) ? If so, can you
send (me) the number of the bug #ID ?

-- 

Best Regards,

	Massimiliano Pala

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

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 062                        Work Phone: +1 (603) 646-9226
--o------------------------------------------------------------------------

---

From: "Santoni Adriano" <[email-masked]>
Date: Fri, 22 Sep 2006 09:23:39 +0200

It is not a "bad CA practice" question, in my opinion. Certificate extensions can be flagged critical for good reasons and according to standards.

Qualified certificates (especially those issued to natural persons vs. software applications) are recommended to have just the NR bit set in KeyUsage, and this latter flagged critical.

ETSI TS 102 280 reads: "In cases where a certificate is intended to be used to validate commitment to signed content, such as electronic signatures on agreements and/or transactions, then the key usage combination SHALL be limited to type A or B. This means that the non-repudiation bit (bit 1) SHALL be set. Of these alternatives it is RECOMMENDED to use the type A setting only (see the security note below)."

De facto, this recommendation has been followed by many CAs operating in compliance with national laws.

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Massimiliano Pala
Inviato: venerdì 15 settembre 2006 9.44
A: pkix
Oggetto: Re: R: Browser trust models & Smart cards

[...]
> unknown beasts. I mean, certificates with a critical KeyUsage 
> extension with the "nonRepudiation" bit raised. If you want to use the 
> signText() function with a qualified certificate, in Mozilla/Firefox, 
> you're out of luck. Why so? Nobody seems to know or care.

This is usually the case when *BAD* CA practice force the presence of critical extensions on very specific profiles. This is sometimes the case of some CAs that follow national signature laws... anyway have you submitted the bug/feature request to the Mozilla developers (bugzilla) ? If so, can you send (me) the number of the bug #ID ?

-- 

Best Regards,

	Massimiliano Pala

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.